Ask HN: Which login method do you use?

This is kind of silly:

* The hash you send will probably be password-equivalent; losing it to an attacker is just as bad as losing the password.

* If you're delivering the JS to generate the hash over HTTP, you have exactly the same threat model as with plaintext passwords (attackers will just subst a script that sends the raw password).

* If you have working HTTPS, you already have optimal communications security; just send the password.

* Even if you came up with a challenge-response protocol to make the hash non-replayable, the exchange itself would be vulnerable to a trivial dictionary attack.

Don't bother with this idea. Move on to something that will add real value to your app.

Since most people already talk about the backend of it, let me share how to securely send the password from the browser to the server encrypted, instead of simply in clear text. (when you can't use SSL for some reason)

+ Server has your passwords stored as sha1(password+salt(password)). salt function isn't secret (eg. reverse the text)

- Client visits login page

- Website generates random token. Then sends back HTML with the random token

- Client generates passresponse = sha1(token + sha1(password + salt(password)))

- Client sends the passresponse, token, and username back

- Website checks for existence of token, removes it, then computes it's own sha1(token + password_hash_from_db) and checks against the sent passresponse.

This way the password is never sent in clear text. Unlike HTTP authentication, this works nicely with html forms since you can do all the crypt in js. Then again, this might be a bit overkill... and using SSL is probably a better option.

Just sharing another solution.

Three sentences, three fallacies.

(1) Not only are rainbow tables avoidable, but they've been trivially avoidable since Unix crypt(3) was invented in the '70s. The only way you can become susceptable to them is if you make the mistake of designing your own scheme. So don't do that.

(2) There's a reason that no mainstream consumer application actually does this: as soon as you lock a normal user out of their account for an hour, you probably lose the user forever. Ok, there are two reasons: this technique doesn't add any security. Anybody nuts enough to brute-force your login page has as many IPs as they want. But that's not how they do it.

(3) People get to access password hashes as soon as you mess up a single database query. The idea behind storing safe hashes is to prevent your stupid mistakes from screwing over every one of your users. The stupidest people of all are the ones who assume they aren't going to make stupid mistakes.

You're describing the simplest possible challenge-response scheme. It has two problems, both severe enough that you shouldn't recommend people waste time implementing it:

* First, because no browser bakes this crypto protocol in, you have to deliver it over Javascript. The protocol basically stipulates that you don't have SSL/TLS. So all you've done is move the goalposts. No matter what kind of dance you do (for instance: Meebo actually delivers a JS implementation of RSA!), the action is now in the JS delivery, which is trivially compromised.

* Second, secure authentication schemes aren't vulnerable to trivial dictionary attacks. This one is: the attacker is stipulated to have access to your traffic. She sees the nonce the server sends and the hash the client responds with. She can solve for the password by (very fast) brute force against a wordlist.

Because, at least with mainstream browsers, users can't log out.

You can fail certain formal security audits for using HTTP authentication.