[Retric]

If password X is hashed to Y, and you store Y that seems ok.

But if you directly check if the client transmits Y then Y is just the new password.

At a minimum you should be hashing whatever the client sends and comparing that with the hashed password.

PS: Not that most developers should do this by hand.

[gohrt]

But don't pass on the salt! https://en.wikipedia.org/wiki/Salt_(cryptography)

[jimktrains2]

I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering).

> At a minimum you should be hashing whatever the client sends and storing that.

That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.

[gohrt]

Salt.

In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that intercepting a transmitted token gives you nothing that you can use to authenticate in a future connection (but you might be able to hijack the connection you intercepted, if you spoofed the server into thinking you are the intended client)

https://en.wikipedia.org/wiki/Forward_secrecy

[Retric]

Yes, there are many many more secure schemes out there. By minimum I meant minimum.

The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.