[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".