

Ask HN: Is this the right way to create a login? - xerophtye

Our current model is that we store salted hash passwords where the username is the salt.<p>When the user opens a login page, the server creates a session and sends a random string along with the login page. On the client side, JS computes the salted hash of entered password (salt = username), then appends the random string as salt and computes hash again. Then sends this hash to us via post.<p>The server matches received hash against hash of (stored hash+random string that we sent).<p>So is this method secure? If not, what can we do to improve it?
======
patio11
If you're storing salted hashes, substantial portions of your
username/password pairs will be decrypted as soon as you lose a copy of your
DB, unless you are intentionally choosing a hashing algorithm which is slow
(bcrypt/scrypt) rather than one which is fast (most of them).

You also seem to be reinventing a few wheels here, and I feel there's a "We
don't want to buy an SSL certificate" motivating part of it, which is a poor
call. Buy the SSL cert. Send the user's input to the server. Compare it
against the bcrypted hash. Simple, easy to implement, hard to screw up,
resistant against you losing your DB.

~~~
erichurkman
Don't forget to build a hash round counter into whatever bcrypt/scrypt setup
you use. Don't just take the salt+password and run it through bcrypt once – do
it as many times as your hardware setup permits, and store that counter as
part of the hash (~bcrypt~DKM303mGdoadyHerichurkman~5000~de455ae…).

As your computing power grows, you can increase the number of rounds.

If you ever replace your login algorithm like Kickstarter did, give your users
a few months to log in to upgrade their stored hashed password. Then purge any
outdated hashes. Let those users do password resets.

~~~
tptacek
Don't do this, as this is exactly the point of using bcrypt in the first
place. Just adjust the bcrypt cost factor.

------
asperous
Your approach doesn't work for people without js, and is ineffective against
man-in-the-middle-attacks. You still need https to secure against people
modifying the page so they get the plain password, and if you are going https,
the js stuff isn't needed.

Here's all you need to know:
[http://stackoverflow.com/a/477578](http://stackoverflow.com/a/477578)

~~~
xerophtye
Thanks, that's a ton of help. I tried stackoverflow but apparently i wasn't
using the right keywords. Bookmarking this for future reference

