couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Initial couchdb accounts feedback
Date Tue, 19 Jan 2010 18:31:29 GMT
On Tue, Jan 19, 2010 at 05:09:39PM +0000, Jason Davies wrote:
> See below for my comments.  I'm not really sure why the ability to
> generate a valid cookie externally is needed, perhaps you can explain a
> bit more about that?

It's for the following scenario: you want all usernames in the database to
be validated, rather than a first-come-first-served free-for-all.

So you need to validate the username, and then give the user some sort of
token that says it's valid and they can go ahead and create the account.

What I was thinking is that you could give the user a cookie, signed using
the same algorithm and secret as the HTTP cookie auth module; they could
then login using this cookie, and once logged in create their account.

The policy in validate_doc_update would be "you can't create account for
username foo unless the userCtx says you're already logged in as foo".

It minimises the amount of couchdb interaction which would have to be done
by a process with _admin rights.

> The session cookie is signed to prevent tampering using
> HMAC-SHA1(<server-wide secret> + <user salt>, <username, timestamp>).
> combination of server-wide secret and user-specific secret marginally
> increases the difficulty of attacks based on obtaining the server-wide
> secret.  Or alternatively, if the combined secret could be obtained
> somehow (perhaps with great effort, using cryptanalysis!) this would not
> give the attacker "access all areas" as they wouldn't have the other user
> salts.

Except that _users is world-readable at the moment :-)

> The main reason, though, is this allows an individual user's session(s) to
> be invalidated simply by changing their salt.  For example, GMail lets you
> log out all other sessions, and this provides similar functionality.

Ah, well that's interesting - you want to terminate someone's access fully,
and ensure there are no rights lingering on.

At the moment, rather than change the salt, you could just delete the user
record.  Your code will look for the salt and not find the user at all and
reject on that basis alone.  It's certainly an argument for requiring the
user account to exist.

BTW, sorry I didn't notice you were already using HMAC-SHA1. I must have
been blind when reading the code.

[cookie expiration time]
> This sounds fine to me, I think originally I wanted to keep the expiration
> times low to reduce the possibility of replay attacks.

I don't think it makes much difference. Actually, I think I could issue a
72-hour cookie already, because I don't think that the validation code
checks for times in the future. Maybe they should have both start and end

Also, having an explicit expiration time might allow things like different
session timeouts for different dbs or users.



View raw message