couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Karpinski <>
Subject Re: User Auth
Date Sat, 21 Feb 2009 06:38:30 GMT
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

In most respects, the ideal authentication scheme for almost all web
applications would be the Secure Remote Password protocol (SRP),
developed at Stanford (, 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
<> 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
> (
> 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...

View raw message