Hacker News Reader

Comment by devit | Hacker News Reader

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.

View on HN

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

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.

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").

> 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

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)

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/Per...

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.

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

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.

Reply on news.ycombinator.com