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. > > 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 http://jchrisa.net http://couch.io
