[jimktrains2]

> Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server.

That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation.

Kerberos' KDC doesn't know the plain-text password either[3].

Even HTTP Digest didn't require the password to be stored in plain text [4]. [Edit: though if you leaked HA1 that effectively becomes the credential]

Moreover, client TLS certificates would also fit the bill, as the client key is never transmitted.

Don't spread FUD if you aren't sure. If you don't know, don't say anything or say you don't know.

[1] http://srp.stanford.edu/ [2] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... [3] http://security.stackexchange.com/questions/15849/does-the-k... [4] https://en.wikipedia.org/wiki/Digest_access_authentication

[mortehu]

> Even HTTP Digest didn't require the password to be stored in plain text

As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.

[jimktrains2]

Right, edited.

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

[jakobdabo]

Speaking of HTTP Digest, I like its concept, easy to implement and supported by all major browsers. Unfortunately MD5 is broken, I wonder whether there is a newer standard using SHA2 or BCrypt for example.

[drdaeman]

TLS client certificates are even easier, don't require consuming party (the server) to know private key at all, and are reasonably secure.

They are not working for end users, because no browser ever cared about those (UI/UX-wise), but I don't see any reason to not use those for automated access by IoT stuff. Generate keypair on-device, send a CSR, ask user to open browser and check if device's theirs (by comparing a conveniently formatted fingerprint - as a picture and/or series of dictionary words, not hex digits), sign and use if everything's good.

[jimktrains2]

HTTP Digest also makes HA1 (hash stored on the server) the credential, so if it were leaked, then you could still authenticate as the user.