couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <>
Subject Re: Baking Cookie-Based Authentication into CouchDB
Date Wed, 27 May 2009 13:04:20 GMT
Hi Adam,

Thanks for that!

1) You're right, _design/_auth isn't protected against unauthorised  
reads at the moment.  The "users" view would also need to be  
restricted, I guess restricting reads of _design/_auth to the "_admin"  
role or similar will have the side effect of also restricting access  
to any views it contains.  Is there anything else I need to do here?   
Once we have reader lists, perhaps we could do away with having a  
special auth design doc and allow the name "_auth" to be configured in  

2) Ah yes, I forgot to mention that part!  For simplicity roles are  
indeed also assigned from the same "users" view i.e. it should return  
{password_sha: ..., salt: ..., roles: [...]}.  It would be simple to  
use a separate "roles" view and I can see that having a separate view  
would probably be better in terms of separating concerns.

In the future I think it might be worth going a step further and  
making the authorisation part completely pluggable, so that  
"authorization_handler" can be specified in local.ini to specify a  
function that takes a username and returns a list of roles so that  
e.g. an LDAP handler could be used without needing to touch the cookie  
or any other authentication handlers.

Jason Davies

On 27 May 2009, at 13:29, Adam Kocoloski wrote:

> Hi Jason, I've been following these updates with interest.  Nice  
> work!  A few quick questions:
> 1) Is the _design/_auth document protected against unauthorized  
> reads?  I didn't see anything to that effect.
> 2) You didn't mention anything about authorization (e.g. the roles  
> list) in your blog post, but it looks like the code is still  
> assigning user roles based on the output of the users view.  What  
> are your thoughts on this?  Some people might say that it would be  
> better to assign the roles in a separate document or view.
> In a future optimization we might want to model this authentication  
> handler as a process so that it doesn't have to open the userdb and  
> _auth doc on every request.  Cheers,
> Adam
> On May 27, 2009, at 7:05 AM, Jason Davies wrote:
>> Hi again,
>> On 4 May 2009, at 23:31, Jason Davies wrote:
>>> On 29 Apr 2009, at 17:29, Jason Davies wrote:
>>>> I'm in the finishing stages of writing a cookie-based  
>>>> authentication handler for CouchDB in Erlang.  This is primarily  
>>>> going to be useful for CouchApps (apps running purely in  
>>>> CouchDB), but this also touches on a generic way to authenticate  
>>>> users via a CouchDB database, which could be adopted by the  
>>>> current default HTTP Basic auth handler.
>>>> I've put the code up here:
>>> [snip]
>>>> Still to do:
>>>> - Use some kind of challenge/response mechanism for logging in  
>>>> via AJAX.  At the moment the login handler just takes a plaintext  
>>>> username/password combination sent via POST.  I was thinking of  
>>>> using SRP ( 
>>>> ), however I believe this would require state to be stored on the  
>>>> server, and maybe isn't appropriate for this.
>>> I've now implemented SRP auth and it is working merrily.  I'm in  
>>> discussions with SRP's inventor, Tom Wu, about a potentially  
>>> simpler protocol as SRP implemented in JavaScript is probably  
>>> overkill for unencrypted HTTP (it is vulnerable to MITM injection  
>>> attacks of the JavaScript code itself, whereas SRP would otherwise  
>>> protect against active attacks).  It might be worth supporting a  
>>> simpler protocol sent over SSL too e.g. plaintext credentials.
>>> Any suggestions for a more appropriate authentication protocol  
>>> would be much appreciated.
>> I've now ripped out the SRP code as it was a) too slow for modular  
>> exponentiation for n with greater than 256 bits and b) overkill due  
>> to the client code itself being sent over the wire thus losing  
>> SRP's resistance against active attacks.  A potential higher- 
>> performing replacement auth protocol is SCRAM but for now I've just  
>> implemented simple plain-text form-based auth, which works even for  
>> non-JavaScript clients.  For extra security simply add SSL.
>> I've now put the code into its own branch here:
>> A brief write-up here:

>>  along with some thoughts on SRP (which is truly awesome and I hope  
>> browsers all support TLS-SRP someday!).
>> A code review would be appreciated and then hopefully we can get  
>> this into trunk so that CouchApps can use cookie-based auth out-of- 
>> the-box.
>> Thanks,
>> --
>> Jason Davies

View raw message