couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Initial couchdb accounts feedback
Date Thu, 14 Jan 2010 17:23:35 GMT
On Thu, Jan 14, 2010 at 9:08 AM, Brian Candler <> wrote:
> [Carried over from user@; thoughts on requiring users to validate their
> E-mail address as a username]
> On Thu, Jan 14, 2010 at 09:38:34AM +0000, Brian Candler wrote:
>> I think what's needed is something *like* a cookie, which can be generated
>> by an external process and validated by couchdb.  Perhaps even the existing
>> cookie auth mechanism could be overloaded/abused.  Put simply:
>> validate_doc_update won't let you create user "" unless it
>> sees that you are already logged in as "". That's trivial to
>> implement.
> I've had a go at implementing this, and the attached patch includes tests
> for this way of working. (*)

I'd be interested in seeing what Jason Davies thinks. My first guess
is that the salt is in the cookie to add entropy and make guessing the
server secret harder.

> The good news:
> * because validate_doc_update is stackable, it's very easy to add your own
> policies for valid usernames, just by adding another design doc with its own
> validate_doc_update.
> * if you send someone an auth cookie via E-mail, not only does that validate
> their E-mail address, but it solves the "forgotten password" problem too
> (just ask the system to E-mail you another cookie, login, and change your
> password).
> There are a couple of issues though.
> (1) I found that the cookie_authentication_handler would not let you login,
> even if your cookie was valid, if you did not already have an entry in the
> users database. It turns out this is because it looks up user's salt and
> includes it in the cookie hash.
> I can't see a justification for that, so in the attached patch I have
> removed it.  Please correct me if I've overlooked something.
> (I think what *would* improve security would be using a HMAC_SHA1 instead of
> a plain SHA1 with the server secret: see RFC 2104, RFC 2202)
> (2) The cookie currently holds the time it was created, not the time it
> expires.  It would be very useful if you could E-mail out a cookie with an
> expiry time further in the future (say 72 hours), whilst still leaving http
> cookies at 10 minutes.
> Making the cookie carry the expiry time would be straightforward to change.
> Are you happy for me to do so?

this sounds sensible to me. Jason?

> Regards,
> Brian.
> (*) You still need an _external handler to calculate the cookie and E-mail
> it out, and to convert the activation link into a Set-Cookie

Chris Anderson

View raw message