Richard Wackerbarth writes: > On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull <step...@xemacs.org> wrote: > > Richard Wackerbarth writes:
> >> Since we consider the user manager to be a part of the MM complex, > >> what have we gained by hiding the underlying credential from the > >> web interface? > > > > Security. See the OAuth 2.0 spec (RFC 6749) which recommends (at > > SHOULD level) this practice. > > RFC 6749 addresses the implementation of an OAuth authorization > system. > > In this context, SHOULD refers to the implementation of this RFC. > > It does not imply that other authorization schemes also need to > meet those same criteria. True, but logically irrelevant: it does not mean that the recommendations of the RFC are irrelevant in the design of authorization schemes. OAuth has reasons for recommending that you avoid passing user- supplied credentials around. These include (among others I haven't the imagination to supply here, I'm sure) (1) privacy of the user (the component the user wants access to may have no need to know who the user is) (2) security of the user credentials (leaking the auth token does not allow an attacker to access all resources the user is authorized for) (3) the accessed component doesn't know the importance of the user credentials (the user may have used the same password in several systems, or the user may have very high privileges in other parts of this system), increasing the risk involved in (2). I see no reason to suppose Mailman is not subject to these considerations. (3) is certainly relevant, as I know that I am simultaneously a site owner, a list owner, a moderator, and a subscriber for some lists. There is a plausible workflow in which a user (who happens to be a list owner) who is browsing the archives is given a subscriber-level token, and when they decide to access a list admin page, they need to re-authenticate to upgrade their authorization to list owner. If they then access a non-admin page, or they time out before accessing another admin page, the owner-level token is downgraded to a subscriber token. (This is like sudo on POSIX systems.) I'm not arguing that Mailman should default to such a workflow, but I think we should be able to support it. Passing around user credentials makes it harder to audit such a workflow. > As for security, exposing the authorization server to direct > Internet access is, in itself, a security weak point. I wouldn't say necessarily "weak", but it certainly expands the attack surface that needs to be defended. That's why I don't want to include an auth server implemented by security amateurs (us!) _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9