2 ms·

Stupid question department: W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn

Stupid question department: W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn't we create a http browser/server authentication method that has something closer to a nonce-based challenge/response mechanism? If it were standardized, the browsers could even do some clever hashing of some peer addresses or other things that we think should be static. All of the browsers could still present a "username/password" field that looks remarkably similar to existing forms but never reveals the plaintext password to the peer. As long as I could type my password into other browsers on other computers and still get the same result, it seems like it's moving things forward. It would be opt-in, traditional username/password forms would continue to live on for decades to follow. So what am I missing? Presumably something like this was considered and ruled out? EDIT: yes, of course, I forgot about the existing HTTP authentication mechanism(s) in RFC 2069. I don't know why it never caught on but the fact that the browser uses modal dialogues for these means a significantly different context/user experience.

richardwhiuk 9y ago
Mainly because the modal dialog can't be styled for security reasons, so the UI designers and marketing tools will want to style the dialog box like everyone else. In the end user experience vs security is a straight tradeoff. Secondly, the digest authentication only supports MD5 anyway.
rocqua 9y ago
These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption. Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt.
- wyldfire 9y ago
  > This means the server still needs to know either your password or a hashed version of it. Yes, the latter, please.
- MarkMc 9y ago
  > Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt. That sounds a lot like Secure Remote Password protocol: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

richardwhiuk 9y ago

Mainly because the modal dialog can't be styled for security reasons, so the UI designers and marketing tools will want to style the dialog box like everyone else. In the end user experience vs security is a straight tradeoff. Secondly, the digest authentication only supports MD5 anyway.

rocqua 9y ago

These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption. Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt.

wyldfire 9y ago
> This means the server still needs to know either your password or a hashed version of it. Yes, the latter, please.
MarkMc 9y ago
> Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt. That sounds a lot like Secure Remote Password protocol: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...