secure user signups and logins, JavaScript/ASP

[andrewbadera]

hello-

looking to implement a secure-as-reasonable user signup and login process. I intend to carry out all user information and password interactions under SSL; I'm debating implementing MD5 hash clientside and passing the result of hashing the password to the DB and store the MD5 hash vs. simply passing the password cleartext, under SSL, and storing the password as an SHA hash in my SQL Server database.

any pros or cons to these options?

 

[danielhozac]

The problem with hashing the password client-side is that not all users will have JavaScript enabled, and your code may not work in all browsers even if JavaScript is enabled.

//Daniel

 

[andrewbadera]

not worried about JavaScript being disabled nor various browser versions, users will be forced to conform with ideal browser configuration.

 

[danielhozac]

So it's an intranet site? Then there should be no problem with hashing the password client-side.

//Daniel

 

[andrewbadera]

I'm curious more about the best process ... should I hash on the clientside and AGAIN in the DB, and compare the SHA-hashed MD5 password hash passed from the client to the database entry? or just hash MD5 clientside and store that hash in the DB?

 

[pansophic]

Hashing twice is generally redundant, as you are relying on the obscurity of the algorithm to provide additional protection. A dedicated cracker will be using a hash table, not actually performing the operation over and over again. In the case of a lookup table, the complexity of the algorithm makes 0 improvement in protection. There was an article released not too long ago explaining how it is possible to crack 99% of all alphanumeric Windows passwords in less than 14 seconds by using the lookup table method.

http://news.com.com/2100-1009_3-5053063.html

If you were hashing with a salt you will get a far superior result. But that is another reason to perform the hashing at the server rather than the client, so the salt is only known to the server.


pansophic

 

[andrewbadera]

see my thought was MD5 hash clientside using JavaScript, and then use SQL Server's PWDENCRYPT method to SHA hash before storing in the DB.

 

[pansophic]

I wouldn't bother with the MD5 hash if the link is SSL anyway. Are you salting the SHA hash?


pansophic

 

[andrewbadera]

that was my thought too actually -- if I'm under SSL, is clientside even necessary. But then again, it's not much effort to implement, so why not?

As far as salting, I'm not certain -- does the undocumented SQL Server PWDENCRYPT function utilize a salt? I'm guessing, in typical Microsoft style, that 7.0 does not, perhaps 2000 does, but I honestly just don't know.

 

[pansophic]

MS doesn't salt their passwords, so I would doubt that they do it in SQL Server either. Salts help to solve the lookup table problem, because each possible salt changes the end hash, making lookup tables impossible on current systems. But in the future, who knows?


pansophic