2 ms·

There are well worked out schemes which do achieve this e.g. Password Authenticated Key Exchange schemes (PAKE): https://blog.cryptographyengineering.com/2018/

There are well worked out schemes which do achieve this e.g. Password Authenticated Key Exchange schemes (PAKE): https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

madacol 7y ago
I'm pretty sure there are lots more, that probably are even better But what I'm suggesting is that whatever it is, it should be integrated with the browser's, so that when I am typing my password in a special password-input-field (which doesn't exist today), no javascript is allowed to read it's plain text, until the user manually unlocks it and the page is able to read it's H(pw || bFixedPub) or whatever protocol is apropiate. That special password field, should appear outside the pageview, to prove that the page is not in control of it, or it's not allowed to phish it, only the browser has control, and when it's done, it sends to the page the resulting hash
- MattPalmer1086 7y ago
  I do like the idea of password fields in browsers which can't be interrogated by javascript, a secure password protocol built in, and some way of making the authentication interface non spoofable.
madacol 7y ago
In the comments section of that link, I found interesting this thread that touches what I am suggesting: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/#comment-3888 https://blog.cryptographyengineering.com/2018/10/19/lets-tal... Which ends up with one of the parties writing this: https://palant.de/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.de/2018/10/25/should-your-next-web-based-logi... The blog in the last link argues against the usefulness with the built-in browser implementation. The arguments are pretty useful, even though I disagree with he's conclusions. I think the fact that if a compromised server has to revert from the secure browser-built-in password form, to a "regular login form" in order to learn your password, then that's a win for me

madacol 7y ago

I'm pretty sure there are lots more, that probably are even better But what I'm suggesting is that whatever it is, it should be integrated with the browser's, so that when I am typing my password in a special password-input-field (which doesn't exist today), no javascript is allowed to read it's plain text, until the user manually unlocks it and the page is able to read it's H(pw || bFixedPub) or whatever protocol is apropiate. That special password field, should appear outside the pageview, to prove that the page is not in control of it, or it's not allowed to phish it, only the browser has control, and when it's done, it sends to the page the resulting hash

MattPalmer1086 7y ago
I do like the idea of password fields in browsers which can't be interrogated by javascript, a secure password protocol built in, and some way of making the authentication interface non spoofable.

madacol 7y ago

In the comments section of that link, I found interesting this thread that touches what I am suggesting: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/#comment-3888 https://blog.cryptographyengineering.com/2018/10/19/lets-tal... Which ends up with one of the parties writing this: https://palant.de/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.de/2018/10/25/should-your-next-web-based-logi... The blog in the last link argues against the usefulness with the built-in browser implementation. The arguments are pretty useful, even though I disagree with he's conclusions. I think the fact that if a compromised server has to revert from the secure browser-built-in password form, to a "regular login form" in order to learn your password, then that's a win for me