Hacker News Reader

Comment by ryan-c | Hacker News Reader

My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value.

If you allow people to choose their own passwords, the vast majority will reuse them, and their account will eventually be compromised via credential stuffing.

I recognize that this solution will, at least initially, infuriate people. Letting people opt in to federated auth if they prefer that (I hate services that require it) might make it more palatable.

View on HN

That pretty much requires you to use something like 1password which if hacked (your error or theirs (who knows how good some random companies security is)) then you are completely screwed as all of your accounts are now compromised. To make matters worse, you don't know any of your passwords so you cannot even log onto any of your accounts to change them (this is also a big problem if you have a customer service problem as it will lock you out of all your accounts).

I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.

> That pretty much requires you to use something like 1password

That's the point.

> you don't know any of your passwords so you cannot even log onto any of your accounts to change them

Nearly every service allows email-based password reset.

> I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.

For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.

For services that generally "stay logged in", why have passwords at all? Just do "magic login link" emails, with some sort of 2FA if you're into that.

Isn't the former what Mozilla Persona was trying to provide? A shame that was canned.

We built a successor project under https://portier.github.io/. Alive and kicking :)

I think "magic login links" are fine for most services. Doing 2FA with that is not feasible though, unless you want to argue that receiving the email counts as "something you know" or that "something you have plus something else you have" counts as 2FA.

If you have your email protected with 2FA, I think you're covered -- "An unlocked device with an active session" is the thing you have.

I think this is actually what's happened -- people now know not to leave unlocked devices unattended, so you basically do 2FA every time you unlock your device, so the device can now stay persistently logged into all services.

I've considered using "magic login link" emails but greylisting[1] seems to be an insurmountable problem.

[1] https://en.wikipedia.org/wiki/Greylisting

Generally greylisting is supposed to let future emails through once it establishes that a server will re-send. It should be possible to detect greylisting and warn the user.

"Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"

> My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value.

I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.

Did you ever use StartSSL? They did TLS client auth and it was surprisingly terrible.

I never had the opportunity and, according to their website, they closed last month. Since I can't try it out myself, what was so bad about it?

TLS implementations themselves need to get a LOT better about describing error conditions before client certs will ever be a viable option for actual user authentication.

Could that be something that a web browser or other client could translate to a more user friendly message?

If the password is randomly generated by the service then you need a way to present the password to the user in plain text. I think you're trading 1 problem for another.

If your users are getting pwned because they reuse their easy leaked passwords on your service, then that's the real world adversary.

Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager.

The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.

That's fine. Storing passwords in plaintext is the problem.

It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.

Yes, that "show once" feature works well for keys / tokens because developers usually use them right away in their app so it doesn't get lost.

But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it.

Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever.

Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke.

Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.

You would still offer a "password reset" feature. Tell them to write it down or keep it in a password manager, and provide links.

Maybe call it an access code rather than a password to avoid "don't write down your password" training.

Everyone would have to get on board with that at the same time. If the user is forced to memorize the password your service generates, they'll use it for everything else anyway.

How many people are going to memorize something like this?

fvtwt gvltv wlbth wgwdh njfnn

The service should not ever get hold of an unencrypted password.

For a website, that's hard to achieve. You can ship some JS to pre-hash the password, but an attacker that can read unencrypted passwords from the server can probably also modify that JS code to send the original password to them.

If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.

Not storing passwords on the server removes some of the incentives to break into the server, and makes a quick and covert heist impossible.

If the server requires me to send it the md5 of my password (for example), it still has to store something to validate the password, which can then be cracked.

Sure, the server should expect a bcrypt hash, and only store a bcrypt hash.

OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.

Reply on news.ycombinator.com