Also, steam should never even see the password, they should only ever see the hash.
Sites/apps will generally handle your plaintext password each time you login or set your password. They (hopefully) just don't store it.
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.
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.
----- 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))
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.
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.
>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.
- https://en.m.wikipedia.org/wiki/Internationalized_domain_nam...
