Hacker News Reader

Comment by Spivak | Hacker News Reader

This should just be how websites work. I see no reason that a site should ever transmit the user's password over the wire.

When you create a password send the client a salt, hash their real password client side, and send the hash over the wire. Treat it as you would their actual password and salt/hash it again.

Then when the user wants to auth send the client the salt you have on file for them^ and repeat. Bam. A domain specific password for every site even for someone who who reuses passwords.

^ inb4 "this creates another 'step' when logging in." Users will type their username and pw before they get the salt and the client will handle the rest.

View on HN

What do you gain with the extra hashing on the client side?

The attack you're protecting against is a compromise of the server's password database. If the attacker has that, then they have the client side salt too.

Hashing on the client side prevents the server side from logging the plaintext password anywhere, and from intermediaries from seeing the plaintext password. Replay of the hashed value is still possible, without other measures.

Hashing a second time on the server protects from a database leak being used to access the site.

> Hashing on the client side prevents the server side from logging the plaintext password anywhere, and from intermediaries from seeing the plaintext password.

No it doesn't, because all of those attackers have access to the client side salt which is sent to the client in the clear.

They would have the client side salt and the hashed password.

Now, depending on the hashing algorithm, maybe it's easy to turn that back into the plaintext, but with a competent hash, it's not expected to be easy.

Edit to add, if the site does it in javascript, of course they (or intermediaries) could decide not to do it, or to also pass the plaintext with the hashed version. That's a separate issue.

If you have the salt and the hashing algo, it's trivial to build a dictionary. If the password is good enough to not be broken by a dictionary attack, it was good enough without all the extra hashing.

Having to mount a dictionary attack which may fail/ take an indeterminate period time seems like a win. Albeit only for users who reuse the same, strong password.

Exactly. And if they’re using a strong password already than you haven’t gained anything.

The dictionary attack on the client created hash and the attack on the server hash of the plaintext take the same effort.

Right, but if you steal the client-hash you have the user's password for this service. If you steal their plaintext password you have their password for every service.

This measure is to limit the blast radius of a compromised password given that people reuse passwords.

No, if you have the salt and the client side hash then you do a dictionary attack and you have their plaintext password, the one they presumably use on multiple sites.

All you've done is move your attack from the server to the client. It's the same attack on both ends.

This doesn't do anything to make a weak password stronger, it makes a strong password resilient to being compromised over the wire or by an errant console.log(http_request) on the server.

If the password is so weak that you can just invert the hash then there's not much that can help you.

If they're on the server seeing your console.log, then they can just change the javascript to stop hashing the passwords on the client side.

An eavesdropper who overhears a password just has the password, but an eavesdropper who overhears a hash and a salt now has to run a dictionary attack which might only have a 99% chance of recovering the password.

In the first case, there's a 100% chance of the password being compromised, but in the second an attacker has to spend resources on cracking a password, and there's still a small chance that they're unable to crack it. The second case seems like a clear winner (I could still be missing something).

You're technically correct, but if they have access to the plaintext conversation, they can just steal the cookie that comes back.

So sure, you may have prevented the release of a reused password, but you haven't prevented anyone from impersonating your user on your site.

Depending on how they have access to your plaintext conversation, they could get your reused password from another site.

In other words, while this might make a slight difference in the stealing of reused passwords, it's not really worth the effort. There are far better solutions, like encouraging the use of a password manager.

> but you haven't prevented anyone from impersonating your user on your site.

That is the whole point. In this system the hash generated on the client is literally your password. It's just to provide some extra protection for people who reuse passwords that are compromised on the server or over the wire.

>There are far better solutions, like encouraging the use of a password manager.

That might be better but your solution requires telling billions of people to not reuse passwords and use a password manager. Or you could implement this on your site and your users are instantly better off. Real users are better off if we just make their behavior safer.

But it only helps real users in the rare case that someone has already compromised the secure connection between their computer and your server.

That's not a realistic use case if you use https on your site.

The effort in implementing this, testing it, testing fallbacks when Javascript is unavailable, testing every change with the fallback on and off, and so on, just isn't worth it for that absolutely tiny gain.

I agree with jedberg’s assessment that the password scheme described above, while preventing the direct transmission of a plaintext password, is still vulnerable to an offline dictionary attack in the event the server database is compromised. One solution may be to look into https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

> No it doesn't, because all of those attackers have access to the client side salt which is sent to the client in the clear.

Why would you send it in the clear?

In the same "clear" that the unhashed password would be sent. ie. I'm assuming they've already compromised your https connection, otherwise it's a moot point.

There is already a standard for this, called SRP: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

This is claimed in the linked Wikipedia article to prevent phishing but how could it?

If the phishing site presents a ui that looks like the real site, the user could be tricked into entering his real username/password which the attacker could then use to log into the real site.

Or am I missing something?

Alternatively we could use public key cryptography and challenge-response protocol. Browser could generate a pair of keys during registration and send public key to a server. While logging in server would send a token that would have to be signed with private key. Server would grant access upon verifying signature. Private keys should be password-protected and could be synced across devices via Chrome/FF account.

Or we could use WebAuthn. I am very curious whether it will get any recognition and support. I am definitely rooting for it.

What if I don't want to force users to use JavaScript?

Also I agree that it's not clear how is it useful, if your server password database is already hashed.

You could use HTTP digest authentication, with the salt as the realm.

https://en.wikipedia.org/wiki/Digest_access_authentication

Original implementation uses MD5. While I think that it's not broken, many people don't like those 3 letters and will avoid just for that. There are modern RFCs, but browsers are not adopting it.

For example this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=472823

I agree MD5 is not broken for digest authentication. MD5 is only weak for chosen-plaintext or brute force attacks. With a correctly generated nonce, it is more than secure enough.

Reply on news.ycombinator.com