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>). The > 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 times? Also, having an explicit expiration time might allow things like different session timeouts for different dbs or users. Regards, Brian.
