Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Actually, I made a mistake in the diagram. The password will be hashed first, then the sha2(nonce + sha2(password)). Passwords will be stored server-side as sha2(password).

Can't update the post now, though.



Your method for storing the passwords server-side is actually not very secure. Hashing the passwords without a unique salt is not a secure way to store them.

For one thing, every user with the password of 'secret' will have the same hash in your database. Secondly, if I were to steal all of your password hashes, I would just have to compute sha2 of every 6-8 (or whatever password length you are using) character string. With a 32 character salt, I would have to compute a sha2 of every 38-40 character string, making my job a more time consuming.


The thing with a salt is that - would you include the salt in the Javascript hashing system? like sha2(nonce + sha2(password + hash)) ? If so, then the salt isn't really that useful - you can then just compute sha2 of 6-8 letters + salt.


The only usefulness of the salt is if somebody steals your database and uses a rainbow table to try to get the passwords. If you don't have salts for each users, then a pre-generated rainbow table for sha1 based on common passwords is going to be very efficient at getting the passwords for each account. If you use salt however, you are protected from the use of pre-generated tables since the attacker has to brute force all the combinations for each user. If you use sha1 or md5 it's still not too secure since sha1 and md5 are fast to calculate and getting faster with this : http://nsa.unaligned.org/hw.php

Read http://www.matasano.com/log/958/enough-with-the-rainbow-tabl... from tptacek, it's very informative...

Of course, the big problem with the javascript way explained here is that you send sha2(nounce + sha2(password+salt)) This means, that anybody who get access to the database can send sha2(nounce + hash_from_database) So basically in this case using salt in the database prevent people from getting the password too easily (so it sorts protects the attacker from getting a password associated with an email address that he could try later on paypal), but it doesn't protect the account in any way...

And for those who think that it's unlikely for anybody to get access to the database, it happened to the reddit guys...


This is basically what we do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: