5 ms·

Here's the "password" killer: generating random passwords on the server and never letting users input their own passwords. All issues with reused passwords, pa

by devit 8y ago

Here's the "password" killer: generating random passwords on the server and never letting users input their own passwords. All issues with reused passwords, password strength, hashing passwords with slow hashes, etc. instantly solved. Also improves conversion rate since there's no risk the user gives up signing up because he can't be bothered to think about or generate a password.

LeonM 8y ago
Except that people won't be able to remember them, so expect massive churn when it's time for them to enter the password the very first time.
- devit 8y ago
  Just set a never-expiring authentication cookie in the browser, so they never need to enter the password in typical one-device use. When they need to change devices, have the standard e-mail based password reset as well as "show password" in the account settings (make the password reset not reset login, unless the user explicitly elects to "log me out on all devices").
  - thecatspaw 8y ago
    > show password You should not be able to do that if you're doing security properly. If you can show the password it means you're not hashing it properly and instead storing it as plaintext
    - devit 8y ago
      1. You can store it on the client side in a cookie. 2. You can encrypt the passwords with a key outside of the database instead of hashing them. That means that people can now login with a read-only compromise of both your app and the database, but chances are that such a compromise would be a full compromise anyway. 3. You can also not show them the current password, but instead generate another one and have them both be valid (until explicitly revoked)
  - TheDong 8y ago
    If you're doing that, you might as well do the "magic email" link as medium does now (and as mozilla's now-defunct 'persona' did [0]). In that case, you don't have any passwords at all, merely long-lived tokens which the user mints by using a unique one-time nonce in an email link. To login on a new device, they get an email and click a link, and that's it. No passwords ever. [0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Per...
kiriakasis 8y ago
Also there is a lot you can do with pronounceable passwords or easy to memorize ones. Hard to remember password and high entropy password can be very different.
ngrilly 8y ago
I agree, but how do you trigger the "save password" dialog of the browser built-in password manager, when using a generated random password? Edit: Answering to myself, maybe by generating the random password client-side, with JavaScript, and making the HTML input field non-editable. I've not tested it.
- Ajedi32 8y ago
  Or by using WebAuthn, which has an explicit API you can call to store a password in the browser.
salvar 8y ago
> Also improves conversion rate since there's no risk the user gives up signing up because he can't be bothered to think about or generate a password. Sure, but there's considerable risk of the user giving up signing up because they can't be bothered with memorizing a random password and want to set their own like every other service allows them.

by devit 8y ago

LeonM 8y ago

Except that people won't be able to remember them, so expect massive churn when it's time for them to enter the password the very first time.

devit 8y ago
Just set a never-expiring authentication cookie in the browser, so they never need to enter the password in typical one-device use. When they need to change devices, have the standard e-mail based password reset as well as "show password" in the account settings (make the password reset not reset login, unless the user explicitly elects to "log me out on all devices").
- thecatspaw 8y ago
  > show password You should not be able to do that if you're doing security properly. If you can show the password it means you're not hashing it properly and instead storing it as plaintext
  - devit 8y ago
    1. You can store it on the client side in a cookie. 2. You can encrypt the passwords with a key outside of the database instead of hashing them. That means that people can now login with a read-only compromise of both your app and the database, but chances are that such a compromise would be a full compromise anyway. 3. You can also not show them the current password, but instead generate another one and have them both be valid (until explicitly revoked)
- TheDong 8y ago
  If you're doing that, you might as well do the "magic email" link as medium does now (and as mozilla's now-defunct 'persona' did [0]). In that case, you don't have any passwords at all, merely long-lived tokens which the user mints by using a unique one-time nonce in an email link. To login on a new device, they get an email and click a link, and that's it. No passwords ever. [0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Per...

kiriakasis 8y ago

Also there is a lot you can do with pronounceable passwords or easy to memorize ones. Hard to remember password and high entropy password can be very different.

ngrilly 8y ago

I agree, but how do you trigger the "save password" dialog of the browser built-in password manager, when using a generated random password? Edit: Answering to myself, maybe by generating the random password client-side, with JavaScript, and making the HTML input field non-editable. I've not tested it.

Ajedi32 8y ago
Or by using WebAuthn, which has an explicit API you can call to store a password in the browser.

salvar 8y ago

> Also improves conversion rate since there's no risk the user gives up signing up because he can't be bothered to think about or generate a password. Sure, but there's considerable risk of the user giving up signing up because they can't be bothered with memorizing a random password and want to set their own like every other service allows them.