[netsharc]

Yahoo! Mail also does (maybe "did", I looked at it a decade ago) something similar. When the user opens the login page, s/he gets a random string in one of the hidden form fields, IIRC it hashes the user-entered password, and then adds the random string and hashes it again, and sends this result to the backend.

On the backend, it knows the random string it sent to the user, and it has the hashed password in its DB, so it can do the same algorithm and compare the results.

[k1t]

The danger with that approach is that the hashed password has become the password. If the hashes are leaked, they can be used to login.

[lostcolony]

Yeah; I've seen this done elsewhere and facepalmed.

Actually, I've seen this done -worse- elsewhere, where they were actually encrypting the password, using a symmetric key. So if you sniffed the traffic and never loaded the website, I guess, you'd not know the actual password...but you wouldn't need it; it as as good as for the purposes of logging in. If you did load the website, you could still determine what the plaintext password was.

It was really irritating, since I had to figure out what the encryption scheme of a backend app was doing (when I only had access to the frontend code, and the datastore).

[lostmsu]

That only works if the string is the same each time. But it won't, if it changes like TOTP code.

[k1t]

If all you are comparing is HASH(random_string + hashed_password) then it will still work.

The server will give me random_string and I know hashed_password from the DB leak.

Obviously this assumes the login process actually works as described in the earlier post.

[lostmsu]

That protects hashes from leaking in transit, for the scenario with 3rd party TLS terminators mentioned above.

[jarkhen]

If the string changes each time, how could they possibly have the matching hashed password stored in the database?

[fgonzag]

They have the users password hash stored in their db so they can replicate the process server side:

login_token = hash(pwd_hash + nonce)

its nothing too wild, especially considering the age of yahoo mail.

[jarkhen]

Ah, right, I misread the original description of what they were doing.

As is, then, it really is just making the hashed password the new password. If I can get the hashed password out of the DB, I can load the login page and simply skip the initial hashing step that's done on the frontend. I now have access to the account without ever knowing the original password.

[SAI_Peregrinus]

Except that it's easy (indeed, required for security) to change the nonce for each login request, so you can't just replay the hash.

[lxgr]

Coincidentally, that is exactly what MS-CHAPv2 does if memory serves me right.