[ivanbakel]

If Steam never saw your real password, the hash of the password would itself become the password, and Steam would be storing your password in plaintext.

In order for password security to work, you have to send Steam your actual password, which they then check against the hash themselves. So at some point, Steam will have your password in plaintext.

[archi42]

No, not really. I'll give you an example that's not really secure, but should illustrate one possible method:

1. You produce an "authentication hash" X = hash(normalize(your_username) + your_password) and send X to the server.

2. The server computes Y = hash(X) and checks Y against the stored hash.

Now you're not sending the plaintext password to the service (e.g. steam), and steam is also not storing the "raw" authentication hash X on the server either. Yes, a manipulated client can send a stolen X instead of a stolen password (but in reality it's a reused password that's been stolen, not X). The advantage is that a compromised server will then not be able to log the plaintext password for credential stuffing.

In case anyone thinks about using the above scheme: Don't. It's merely an illustration for one specific property. Other than that it is PAINFULLY flawed in many ways.

[ivanbakel]

You're just adding a step for generating the hash-as-password from some other information. Just because you label something in that generation step the "password" doesn't mean you're avoiding the hash being the password. From your and Steam's perspectives, "X" is still a secure value that Steam has to see in plaintext and not store.

[archi42]

I simplified my other post for better readability and just realized I made a stupid mistake doing so; I replaced a public per-user salt that's to be queried during login with "normalize(username)". In the given variant it would actually be possible to perform credential stuffing if both use exactly the same hash function and if I use the exact same username. However, if a user-specific (or at least site-specific) public salt is added, this doesn't work anymore. That's what I deserve for writing this by heart instead of putting it into ProVerif first. Maybe that bad simplification caused the misunderstanding?

----- edit, original post. feel free to answer if you still disagree :)

Now we're talking labelling. To me the password is what I, as a human, enter in some login form. What's sent to the server is derived from that. In once case the derivation function is just the identity, in the other case it's a trapdoor permutation (with a public salt). For the authentication flow it's quite similar, yes, and for many kinds of attack I wouldn't care what I have (e.g. PtH on Windows) - but for the user there is a huge difference if they memorize + enter "7110eda4d09e062aa5e4a390b0a572ac0d2c0220" or "1234".

Let me pose a scenario and ask you a question: Assume I'm dumb and my login on HN as well as Steam is archi42 with password s3cr3t. Now the simple "sent password in the clear to the server" allows GabeN [president of Valve/Steam] to log my credentials and post spam on HN. With a trapdoor derivation function that's not possible anymore [this is where I realized my bad simplification]. So if the two are exactly the same thing, why does that attack work in once instance, but not the other?

(edit2: if you answer this, assume that there is a user-specific, public "salt" A that the client queries from the server prior to computing X = hash(A + password))

[ivanbakel]

To me, you're overthinking the original comment. The particular line

>Also, steam should never even see the password, they should only ever see the hash.

is, if you interpret it generously, trivially true. There are 101 authentication mechanisms where Steam doesn't "need" to see a password (i.e. some secret information that is remembered by the user.) As you point out, the password can be hashed and even salted before transmission.

Alternatively, Steam could authenticate with e.g. a public/private keypair, in a way that means that it would be immune to replays of the authenication protocol, while never seeing or storing any sensitive info.

But I find it hard to believe that the original commenter's objection to Steam seeing your password is based on any of these alternatives. The comment didn't say "Steam should be using a protocol where they don't see your password", and I don't think many hackers have such an opinion about any service, given how prolific just basic username+password authentication is on the web.

My original reply was based on the interpretation that the commenter had misunderstood how username+password authentication interacted with password hashing, both of which are technologies used in 99.99% of web services - rather than a more esoteric approach which somehow justifies the idea that "Steam shouldn't see your password".

[tialaramex]

No. In order for password authentication to be something a five year old can do by pasting PHP code they found in a Stack Overflow search, that is how it works.

But algorithmically even if you want passwords (you don't in most cases, get WebAuthn for example for web site authentication) you can use an asymmetric PAKE such as OPAQUE:

https://tools.ietf.org/id/draft-krawczyk-cfrg-opaque-03.html

This is quite a bit more complicated than the one line PHP password stuff you pasted from Stack Overflow, but the user's password never leaves their machine, and so the Relying Party doesn't know the password, and yet they can verify that the user does know the password which they originally chose for the site.

[tialaramex]

When people downvote something I wrote because it's sharing an opinion they don't like it, I kinda get it, that's not really what HN downvotes are for, but sure.

However in cases like this what I wrote was just a fact about a world which they weren't aware of, I'm not sure what they hope to achieve by downvoting.

ivanbakel wrote "In order for password security to work, you have to send Steam your actual password" and that's not true. It's not going to become more true if you can just delete my comment explaining why it's not true, that's not how our universe works.

[detaro]

It seems pretty obvious that you were downvoted primarily for the entire entirely unnecessary "5 year olds copy-pasting from stack overflow" bit. "Actually, this isn't true anymore, a few years ago [afaik OPAQUE is from only 2018?) they found a protocol that solves this:" would've been a much more productive start to that comment.

[tialaramex]

While OPAQUE is modern, this whole idea isn't. SRP is a 1997 Stanford project with their results first published in 1998.

But you're probably not wrong about people not liking how I phrased my reply.

[detaro]

Somehow I thought OPAQUE had some important change that made it practical compared to previous variants, but now I can't find what that would be or why I thought that, so yeah, the reference to the date is indeed irrelevant I think.

[ivanbakel]

To quote the guidelines:

>Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.