Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

Ok, your proposal is, "application designers will control the login experience by invoking a browser-controlled popup box over which they have virtually no control, and then, when that popup fails, they can do a really creative error page". I think you're making my point for me.

Your point about the security of digest auth appears to be the actual inverse of reality. Allowing for the fact that I could be wrong, since I think about HTTP Authentication very rarely in my professional career, since nobody uses it and nobody ever will, can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? This is exactly the problem SRP was designed to solve.

Browsers didn't evolve in this direction because HTTP Auth was never a win over form auth. Form login is prettier than HTTP authentication, it's more usable, it's less intrusive, it's more flexible, it's easier to implement, 90% of it is required anyways since every app in the universe still needs a secure session store, and its future-proof.

No, that's not his proposal. The 401 message (which is what he meant to say) is what prompts the browser to display the popup box in the first place. The idea would be that if you provide a custom form there, the browser displays your custom form (in the browser window) in place of the default popup.

Then all you need to add is a couple of Javascript methods to allow that custom form to set the HTTP Auth parameters and retry (you could even use a special form target for that, if you wanted to, avoiding Javascript entirely).

>can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash?

That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Ad...

On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.

You're right; if you go out of your way, you can instead store an extraordinarily viciously crackable derivative of the password. I'd stick with basic auth and use BCrypt on the server; you're far more likely to lose your whole password database than you are to lose a significant number of basic auth logins to interception.

At first that appears to not store the plaintext of the password, but looking closer, isn't it really using the hash as a password? That is, if the bad guys got a copy of the hashes stored on the server, they could use a modified client to log in.

The protocol is requiring the client to prove that the client knows that hash, not that the client knows the password, if I'm reading it right (I might not be).

Yes, the intermediate hash is password-equivalent, but at least you haven't (directly) handed over your Google Mail password at the same time.

SRP was designed, in part, to make the serverside storage of passwords crypto-hard to break. It's an elegant protocol, but it's a little more complex than digest auth.

None of this stuff is anywhere nearly as safe as bcrypt and TLS with form auth. Digest HTTP auth can, in fact, make you even less safe than unencrypted form auth.

Reply on news.ycombinator.com