Steve, something else you may want to consider is to salt the password. Basically create a couple of random digits that are stored as part of the user account. Then before hashing the password concatenate those digits to the password. This makes it so two passwords that are the same will be different in the DB.
Also as for my two cents: I believe in putting all of your password manipulation code in the same place for maintainability reasons. In the case you are referring to some later developer may come along not realizing the password in the db is a result of a double hash. Another thing I would like to point out is that changing this system means that existing users cannot login any more, unless you are lucky enough to have found this before it went into production. Otherwise you will need to create a password version field and then convert users after they login to the old way. Brian On Sun, Mar 16, 2008 at 11:14 AM, Steve Morrey < [EMAIL PROTECTED]> wrote: > On further consideration and after discussing it with the client, I > have decided not to green light the code as is. > > I figured I would share my reasoning with the group, so I could lay > the issue to rest. > > The reason is pretty simple. > Even if you hash the hash, you are still sending the authentication > token that the server cares about, in plain text across the internet. > This could allow for a replay attack. Nothing can prevent that except > for implementing SSL at least on the authentication page. > > Even if they only used a self signed SSL cert and only used it on the > log in page, that would be enough to prevent the attack, and that is > relatively simple to set up. > > Thanks for the advice guys, it took awhile for me to figure out what > was bothering me about the set up but I feel a lot better now I've had > some time to think about it, and gotten feedback from the list. > > Sincerely, > Steve > > > On 3/16/08, Bart Whiteley <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 16, 2008 at 12:29 AM, Dave Smith <[EMAIL PROTECTED]> > wrote: > > > > > Steve Morrey wrote: > > > > What has me worried is that $user_password is hashed prior to this > > > function > > > > by an SHA1 function written in Javascript, prior to being passed in > to > > > PHP. > > > > This means that we are comparing the hash of a hash, which we all > know > > > is > > > > generally considered bad practice. > > > > > > > > > > Agreed, double hashing is bad, for the reasons you outlined. > > > Additionally, if the client program is transmitting a hash to the > > > server, I hope it's also SSL encrypting the transmission or the > system > > > is subject to replay attack. Hashed passwords don't really buy you > any > > > security for transmission (since they are subject to replay attack). > > > They are mostly used so the password never has to be stored in the DB > in > > > clear text. > > > > > > > > If you don't need/want SSL, you could implement something similar to > digest > > authentication (rfc2617) to protect the password and provide a measure > of > > protection against replay attacks. > > > > > > /* > > PLUG: http://plug.org, #utah on irc.freenode.net > > Unsubscribe: http://plug.org/mailman/options/plug > > Don't fear the penguin. > > */ > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
