Hacker News Reader

Comment by briffle | Hacker News Reader

  Server knows the plaintext password already, too.

Servers should NOT be storing passwords in plaintext, ever. This has been clear for at least 20 years now. You should only store a salted hash of a password, and please, do not roll your own. Use one of the many popular libraries for this.

View on HN

Servers routinely handle plaintext passwords when authenticating. They may not store it, but it's not something that is invisible to them, unless using some auth method that uses challenge/response instead of plaintext passwords. Most web apps use plaintext password auth.

There is a difference between the plaintext password being stored in memory and in a database. One is just how things work (the client browser needs the password in plaintext as well), and another is a security breach waiting to happen.

> There is a difference between the plaintext password being stored in memory and in a database.

Yes, if you already got in, then reading RAM for active users is much more convenient than exfiltrating a bunch of potential trash accounts.

Any non-brain dead design will keep the password around only long enough to hash it and compare that to the store hash, and then promptly get rid of it. You can’t just read passwords from memory as if it were an open book.

Attacks, as opposed to data breaches/exposures, may occur over longer time periods and sample memory as they go. Iirc, the attacker in The Cuckoo’s Egg both read password files and temporarily patched the login form.

You don't have to hold clear-text data around for very long for it to be exfiltrated.

And noone said clear-text passwords would just stick around in ram.

Your first sentence seems to describe sticking around and your second sentence says nobody claimed they would stick around?

But more directly, "reading RAM for active users" as a method of gaining passwords, written in context as a direct consequence of "the plaintext password being stored in memory", sure sounds to me like a claim that they're sticking around.

If my password is only ever kept in RAM during my login process, there’s a small window of time where it can be exfiltrated, it’s only really at risk if there is an attack in progress while I’m logging in. Persistent storage is always susceptible to exfiltration.

Nothing is ever 100% secure, but we can limit the exposure, and the blast radius when you do get breached.

The server knows the plaintext password in order to hash it, salt it, and compare it. How else would it do that

No, the server doesn't "know" the plaintext password, the server knows the hashed password and the salt. The plaintext password is in memory during your login request's lifetime, once it is hashed and compared against the stored hashed password, the plaintext version no longer exists on the server.

Very different case from storing them in plain text in the database or elsewhere.

If the plaintext password traverses the server's memory space then yes it "knows" the plaintext password. A nefarious server administrator can do whatever they want with those plaintext passwords.

There is a large difference in attack surface there, though:

Passwords stored unhashed in a database fail catastrophically and irrevocably against a point-compromise attacker. Hashed passwords, validated using plaintext passwords, only leak all passwords entered since the moment of compromise.

I'm certainly not denying that. But to try to claim that the server doesn't know the real password is completely false. Whether they hash/salt the stored value is completely irrelevant to the point that you have to trust the plaintext password handling end-to-end since the server can do anything it wants with your real password.

it's not about nefarious server administrators, it's about an attacker getting in, dumping the database content, logs and whatever else they can grab. they then search those for valuable information they can sell - like email addresses, username+password combos, payment info, the likes. those are then bundled and sold on the darknet to spammers and phishers.

if the credentials are in the logs they'll harvest those to attempt logins on other sites.

Not always. The client could salt and hash the password before sending it to the server for storage and comparison.

To be clear: a properly designed system can and should operate without the server ever knowing the plaintext password.

The browser can do it too, Keybase handled passwords like that.

I thought it could get hashed client side

Then the hashed password is effectively the plaintext password

Not if it's scoped to the username/domain in some way (e.g. by making the client-sent value H(password, username, domain) rather than just password or H(password)).

But that would require a canonical and secure (i.e. not (only) controlled by server-fetched code) way of client-side password preprocessing, and if you have that, you can just as well use a PAKE, modern instances of which have all of these nice properties and more.

Except, if you run rounds on the client and server, you now never handle plain passwords (that users might be reusing) and reversing the thing you store into something you can use against that services' API is still just as hard (if not harder because you need to do either do the total rounds on plain or the server rounds on a very long input)

It's not the same. If you the un-hashed password leaks it can often be used to authenticate on other websites since people reuse passwords. You can't do that if all you have is the hashed password.

Does it matter when you can use the hashed password to log in?

I think you missed the other websites reference. If you're at the point of being able to steal the table of users, you're probably not too concerned about using the credentials to login to that website.

Reply on news.ycombinator.com