3 ms·

Hm, I guess I always assumed we would end up with SCrypt or something similar running on the client side with a nonce etc so the server never even sees the plai

Hm, I guess I always assumed we would end up with SCrypt or something similar running on the client side with a nonce etc so the server never even sees the plaintext password. Even if that means a new protocol that uses SSL to send the javascript, etc., and we're 15 years away. Do you think designing a system where the server never sees (or has the opportunity to store) the plaintext password is the way of the future? (Edit: more emphasis on future, not short term, ambitions.)

tptacek 17y ago
I'm sorry. I thought you mean Javascript challenge-response, which is a very common and very evil suggestion as a way to get SSL-like security without having to do SSL. You mean things like 1password. That's fine. I use Keychain and head /dev/random | md5 for any password I don't have to remember.
Tichy 17y ago
What scheme would allow for that, though? Except for public key cryptography? Seems to me storing hashes and nonces does not work, because without the original password the server can not create new hashes and nonces. So the client would still always send the same thing, which would be equivalent to a password.
- adamsmith 17y ago
  yeah, I know what you mean. I do think it's solvable though. one time during undergrad I was talking with Hal Abelson because there was this big stink about the new research building (Stata center) requiring rfid's to get around. Richard Stallman et al were making a huge ruckus about the privacy implications of not having physical keys. I mentioned some desired attributes of a protocol to let people in without logging it, and started worrying about the implementation details / feasibility. he said "oh don't worry about implementation. this building has people in it who can implement anything." he had this smirk about him. so give it some experts and time and they'll figure it out.
  - Tichy 17y ago
    Can they prove P = NP or P != NP? Some things just aren't solvable.
NateLawson 17y ago
There is a secure auth mode for SSL called TLS-SRP, RFC 5054. It is quite clean, deriving a session key and authenticating the session in the same number of round trips as a regular TLS handshake. It is secure against dictionary attacks. http://srp.stanford.edu/whatisit.html http://srp.stanford.edu/whatisit.html http://www.ietf.org/rfc/rfc5054.txt http://www.ietf.org/rfc/rfc5054.txt Now, if only more browsers would support it.

tptacek 17y ago

I'm sorry. I thought you mean Javascript challenge-response, which is a very common and very evil suggestion as a way to get SSL-like security without having to do SSL. You mean things like 1password. That's fine. I use Keychain and head /dev/random | md5 for any password I don't have to remember.

Tichy 17y ago

What scheme would allow for that, though? Except for public key cryptography? Seems to me storing hashes and nonces does not work, because without the original password the server can not create new hashes and nonces. So the client would still always send the same thing, which would be equivalent to a password.

adamsmith 17y ago
yeah, I know what you mean. I do think it's solvable though. one time during undergrad I was talking with Hal Abelson because there was this big stink about the new research building (Stata center) requiring rfid's to get around. Richard Stallman et al were making a huge ruckus about the privacy implications of not having physical keys. I mentioned some desired attributes of a protocol to let people in without logging it, and started worrying about the implementation details / feasibility. he said "oh don't worry about implementation. this building has people in it who can implement anything." he had this smirk about him. so give it some experts and time and they'll figure it out.
- Tichy 17y ago
  Can they prove P = NP or P != NP? Some things just aren't solvable.

NateLawson 17y ago

There is a secure auth mode for SSL called TLS-SRP, RFC 5054. It is quite clean, deriving a session key and authenticating the session in the same number of round trips as a regular TLS handshake. It is secure against dictionary attacks. http://srp.stanford.edu/whatisit.html http://srp.stanford.edu/whatisit.html http://www.ietf.org/rfc/rfc5054.txt http://www.ietf.org/rfc/rfc5054.txt Now, if only more browsers would support it.