Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jason@jasondavies.com
 designates 89.145.97.179 as permitted sender)
Message-Id: <4EA19F24-6C9C-41A8-A433-464375B48F34@jasondavies.com>
From: Jason Davies <jason@jasondavies.com>
To: dev@couchdb.apache.org
In-Reply-To: <34FA3001-954A-4DD0-9E62-226F49C950CF@jasondavies.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 4 May 2009 23:31:17 +0100
References: <34FA3001-954A-4DD0-9E62-226F49C950CF@jasondavies.com>
Subject: Re: Baking Cookie-Based Authentication into CouchDB

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: http://github.com/jasondavies/couchdb/tree/master

[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 (http://en.wikipedia.org/wiki/Secure_remote_password_protocol 
> ), 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.

> - Store hashes of passwords in the database.  We can already do  
> this, but we might want to send something like hash(password 
> +password_salt) to the server, which would involve retrieving the  
> appropriate password_salt for a given user first.

Done.  In SRP, a special non-plaintext-equivalent "verifier" is stored  
in the database along with a salt.

> - At the moment the cookie is set for Path=/ - this probably needs  
> to be set to Path=/current_database by default, and be configurable  
> so that it can be used by a proxy.
> - I need to work on making my tests more exhaustive, they're pretty  
> minimal for the moment.

These still need working on.

> - All this auth stuff should probably go into its own module,  
> couch_httpd_auth or similar.

Also done.

--
Jason Davies

www.jasondavies.com