Hacker News Reader

Comment by cremp | Hacker News Reader

> inserted code that allowed them to capture plaintext passwords as they were entered by users at the time

Huh? I get if you 'lose' a database backup, but hashing on the server side has always been the wrong way to do things. If you hash it in JS before the request is sent, there is no possible way for you, or any attacker to get the raw user password; only if they literally change production code to send a new request to another endpoint.

> users we confirmed to be affected.

So everyone who logged in during the event?

> resetting passwords for all accounts that were active at the time of the 2015 incident

That's what should have happened the first time. Once you have attacker modified code, you cannot trust what you have on file is accurate or not already taken.

View on HN

Client-side hashing of passwords does not provide any of the benefits of server-side password hashing, as the client-side hash of the password effectively becomes the password, as it's all that's required to authenticate.

Client-side hashing does provide very limited protection against plaintext reuse (on other sites where the user uses the same password) in the case that it's leaked in transit, which is far less of a concern now that HTTPS is cheap and widespread.

What about double hashing? Once on the client and once more on the server? Then, the server never sees the password, but prevents using a leaked password hash from the DB

I don't think that solves the problem. Instead of logging the plaintext passwords they would have just logged the 1-hashed password.

The problem with client-side hashing is that the client-hashed password then becomes the password. An attacker doesn't care if the password being sent to the server is "password123" or if it's "e2389cbb675c3ef00879482bd1702f76", because either way, all the attacker needs to do to log in as you is send that "e2389cbb..." string to the server.

I suppose double hashing would have the benefit of preventing your server from ever seeing the plaintext password, but I'm don't think I've ever seen that be a major concern.

The point of hashing it server side is that even identical passwords get different hashes in the database. You can't do that just by hashing the password in the js.

Is letting the client know the salt a problem?

A salt being public is usually fine. AFAIK most modern suggested hashing libraries use a random salt and store the salt in plaintext next to the hashed password anyway. A properly salted-and-hashed password is still practically uncrackable even if the attacker knows the exact salt used.

i've always stored the salt plain text, how else do you store a salt? i need to be able to use it with 0 information about the user other than "they are trying to use this password"

I've seen lots of people under the false impression that salts need to be kept secret, and jump through some hoops to do stuff like encrypt salts before storing them. Well intentioned, but misinformed and error prone, and likely indicates that they're not using standard login/password hash libraries and might be doing other things wrong, too.

Hmmm... I don't think so? I honestly never considered that possibility. My only concern would be accidentally leaking whether a login username/email is valid depending on your strategy for returning salt for invalid usernames. That should be able to be worked around though.

Anyone can get your JS hash function and reverse it. This has to be on server side

An attacker knowing what hash function you used does not reduce your hash security in any material way. The most secure thing you can do is to use just regular out-of-the-box Argon2 or scrypt hashing. And even if an attacker knows the exact code of the Argon2 function you used to hash, they are no closer to cracking it. In fact, customizing it in any way is almost certain to reduce your security.

Hashing password client-side is a terrible idea (not only is it a terrible idea but it's pretty much useless in terms of security), but it's not because of someone being able to "get" your hash function.

A hash function isn't feasible to reverse, even knowing the algorithm.

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

Reply on news.ycombinator.com