Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

61–70 of 277 posts

Re: Why [Insert Thing Here] Is Not a Password Killer

#61
post #5

It is not just that everyone knows how passwords work. It is also that you can always enter a password. What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there? I will pretty much always b…

Also, I do not own a smartphone.

Re: Why [Insert Thing Here] Is Not a Password Killer

#62

Earlier quoted context omitted.

Agreed. I've tried educating non-technical friends and family about insecure passwords and how random long strings are more secure. Their responses are: 1. "I can't remember that password! / I don't want to type that!" 2. "I'm a nobody, hackers wouldn't be interested in me. My account has no interesting data." [explanations about botnets doing damage to others go way over their heads] 3. "If someone REALLY wants to h…

This does not work, you're a single point of failure. If you say, get sick, family members will override security. Nice try though. I'd recommend an actual password manager instead. Authenticated with biometrics and a simpler local password. Your service does the same, using voice and phone number as biometrics. (Perhaps with recovery question.) Feel free to replace it with sufficiently advanced AI.

Please, try to be in my shoes. Even teaching copy-paste is so difficult, how do you want me to teach them biometrics?

The "I'll manage all your passwords for you" is the only solution that actually works. The ONLY other alternative is that they use 123456 as password everywhere. I already explained why I can't get them to use a password manager.

Re: Why [Insert Thing Here] Is Not a Password Killer

#63

A little boring and reactionary, I think. Unguessable capabilities (long unchoosable URLs mostly) have been used to replace passwords. Plenty of systems refuse to let users choose passwords, and many common password problems are totally mitigated by this design.

Not the 'my password is on a post-it attached to my monitor' issue though.

Re: Why [Insert Thing Here] Is Not a Password Killer

#64

> Despite it's [sic] many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone. I think the problem is that people don't understand how to use passwords. They will reuse them among sites. They pick easily-guessable and low entropy ones. They will type them into any website that asks. The end result is that not much s…

Why is it not great for the password checking to happen client-side? What is the security risk? You can do client-side hashing safely as well.

Re: Why [Insert Thing Here] Is Not a Password Killer

#65
Ancient Egyptians probably made the same argument "Keys just won't work - everyone knows how to use a door knob, but these new dangled keys, no one carries them, we have not invented key rings yet so people will fumble. Best not to."

No people dealt with keys and locks because they did not want their stuff stolen.

As more and more valuable stuff is kept behind our passwords we will accept more and more cost to protect them.

Re: Why [Insert Thing Here] Is Not a Password Killer

#67

> Despite it's [sic] many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone. I think the problem is that people don't understand how to use passwords. They will reuse them among sites. They pick easily-guessable and low entropy ones. They will type them into any website that asks. The end result is that not much s…

Why is it not great for the password checking to happen client-side? What is the security risk? You can do client-side hashing safely as well.

I presume GP is talking about the plaintext password, not the hashed one. If plaintext, then every client gets to see the password so they can use it on the second attempt. If hashed, it still leaks more information than is otherwise necessary, and opens the door to rainbow tables (if inadequately salted) etc., since the server can no longer rate-limit validation requests.

Re: Why [Insert Thing Here] Is Not a Password Killer

#68
post #5

It is not just that everyone knows how passwords work. It is also that you can always enter a password. What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there? I will pretty much always b…

Medium is frustratingly guilty here. Your login choices are limited to sharing data with Google/Facebook/Twitter or clicking a magic link in an email.

If you don't like to share your data with third parties then you are basically restricted to logging in on devices that have access to your email. Which means you're stuffed when that doesn't apply.

Security at the expense of usability is fine when it's warranted. All too often it's not.

Re: Why [Insert Thing Here] Is Not a Password Killer

#69
post #42

Earlier quoted context omitted.

There’s also room for nuance even with financial sites: e.g. do MFA for everything which causes money to change hands but don’t require it every time someone checks their balance or confirms that their rent check went through, especially from a frequently-used client. Similarly, if you’re not a financial site question whether you’re doing anything of value. The Netflix example is great: a huge password really doesn’t…

Indeed, the best policy is to not store any data. Even easier to comply with GDPR this way. No account is best account. This requires that the site supports automatic completion and pasting. Quite a few sites explicitly prevent it for stupid reasons like assuming user browser is compromised. (If it is, you shouldn't be using the webpage for authentication.)

I really value the GDPR for getting companies to see stored data as a potential risk rather than just something which can potentially be sold later.

Re: Why [Insert Thing Here] Is Not a Password Killer

#70
post #25

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.

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.

Post reply on HN