I apologize in advance that I'm going to digress a bit here on the shittiness of standard authentication mechanisms...
[ begin rant ] Ultimately, support for better authentication than HTTP basic/digest auth would be nice. Basic auth is terribly insecure. Like ridiculously so. Digest auth is better, but still pretty darned insecure. SSL + digest auth goes a long way towards fixing the situation, but SSL is a deployment nightmare, costs money, hogs resources, and makes any sort of transparent proxying impossible. There's a billion cookie-based solutions that are almost all nearly as insecure as Digest auth or worse. In most respects, the ideal authentication scheme for almost all web applications would be the Secure Remote Password protocol (SRP), developed at Stanford (http://srp.stanford.edu/whatisit.html, http://en.wikipedia.org/wiki/Secure_remote_password_protocol). I was going to explain, but their website says it much better: "[SRP] solves the problem of authenticating clients to servers securely, in cases where the user of the client software must memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier for each user, which allows it to authenticate the client but which, if compromised, would not allow the attacker to impersonate the client. In addition, SRP exchanges a cryptographically-strong secret as a byproduct of successful authentication, which enables the two parties to communicate securely." [ end rant ] So, yeah. Allowing pluggable authentication mechanisms would be sweet. Since the primary target is RIA's where the security protocols can be implemented in JavaScript or ActionScript, it should be entirely possible to allow for alternate authentication without browers having to change. On Fri, Feb 20, 2009 at 3:48 PM, Stefan Karpinski <stefan.karpin...@gmail.com> wrote: > Thoughts (just brainstorming here): > > I think it makes sense to separate authentication and permissions. > Pure authentication is just about verifying that the user is who they > claim to be. Permissions are about deciding which users are allowed to > see or do what. Cleanly separating is good: ideally you should be able > to completely swap out your authentication mechanism, switching from, > say basic auth to SSL + digest auth, and keep the application logic > about who gets access to what completely unchanged. For example, > Apache accomplishes this by doing whatever authentication it's doing > and then passing the REMOTE_USER environment variable > (http://httpd.apache.org/docs/1.3/misc/FAQ-F.html#remote-user-var) > with the authenticated user name. Whatever CGI or variant thereof > (FCGI, etc.) then just does whatever it sees fit to do with that user > name. > > Also, authentication is typically slow: even hashing a user/pass combo > takes some CPU — this is not something that you want to have done on > every request. That's why the notion of user sessions exists (at least > from the security perspective; there are other notions of session). > That argues for having the CouchDB server process manage > authentication and letting the application developer define custom > functions for deciding whether (user,resource) pairs are acceptable or > not. I.e. the CouchDB process somehow validates that the request is > coming from someone who has provided adequate proof that they are who > they claim to be, via HTTP basic/digest auth or whatever. Then the > application can just decide whether the pre-authenticated user is > allowed to access a particular resource. > > More thoughts coming...
