Hi Brian, On 14 Jan 2010, at 17:23, Chris Anderson wrote:
> On Thu, Jan 14, 2010 at 9:08 AM, Brian Candler <[email protected]> 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 "[email protected]" unless it >>> sees that you are already logged in as "[email protected]". 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. 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? >> >> 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. 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. 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. If this is too limiting perhaps we can find a way to support session cookies that don't sign using the user salt. >> >> (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? This sounds fine to me, I think originally I wanted to keep the expiration times low to reduce the possibility of replay attacks. I have some ideas about preventing these using nonces anyway, but haven't had time to implement them. I don't know if they would throw a spanner in the works if you want to generate the session externally though. > >> >> 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 Sending a 72-hour session cookie via email sounds rather dubious from a security standpoint, as an attacker could then gain indefinite access by constantly refreshing his session cookie with new expiry timestamps. >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io -- Jason Davies www.jasondavies.com
