Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

Post reply on HN
Print view View original

111–120 of 277 posts

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

#111

Post by Ajedi32 »

throwawaymath wrote: post #64
jrockway wrote: post #17

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

Because if it happens client-side, then I can completely bypass your site's security by opening the dev console and changing `if (enteredPassword === correctPassword)` to `if (true)`.

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

#112

Post by rocqua »

ilovetux wrote: post #34

I think that a lot of the problems that are inherent to passwords might be mitigated by not allowing the user to choose a password. A strong, randomly generated password being given to the user and changed periodically would almost force the user to use some sort of password manager. If this were adopted industry-wide (a big ask, I know) then users would be able to use the familiar "enter username and password" syste…

'Ugh, this site forces me to remember this shitty password, Guess I'll go to the competitor'

This kind of friction is exactly what troy is talking about.

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

#113

Post by hyperpape »

screye wrote: post #57
jrockway wrote: post #17

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

> I think the problem is that people don't understand how to use passwords From the looks of it, neither do the authenticators. The capital letter + symbol + number requirement had led to the current predicament. Just asking for really long passwords would have been a lot better. As it stands, people either use a predictable string of num-symbol to satisfy requirements or remember that one strong password,.which qual…

Just by itself, long passwords will result in people using "franklymydearIdontgiveadamn" and other things susceptible to a dictionary attack.

Long passwords plus a bad password check (https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...) might suffice. However, without that check, I suspect requiring special characters marginally improves entropy in practice.

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

#114

Post by bhauer »

creeble wrote: post #107

I just wish there were a more universal acceptance of entropy. I.e.: Use at least one upper case letter and symbol OR Use a password that is at least 20 characters long Passwords are fine, it's the differing standards that are nutty. Especially when you don't know them until after trying.

You can satisfy most entropy requirements without even trying by using a password manager's "create random password" feature. I feel the more important thing to attack is making password management more approachable to laypeople.

To your point though: the most bothersome constraint put on passwords by applications and web sites are limits such as restricting certain special characters (To what end? You're going to hash it anyway, so why limit my special characters? You are going to hash it, right?) and limiting password length to something surprisingly short like 16 characters.

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

#115

Post by will4274 »

chme wrote: post #7

I haven't heard of any system that replaces passwords all the way. Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token). So they don't replace something that you have to remember (password). Passwords are easy to change and while they can be copied, that would be the result o…

> Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token).

Actually... When you log on with a password today, an Identity Provider like Google or Microsoft typically issues you a "ticket granting ticket" (TGT) which you can use to get more tickets. The TGT is stored in a cookie on the web or in the OS. This TGT is something that be can copied. So, today, when you log on, you provide your password to get something that can be copied that you then use to log on to various services. Point being, something that can be copied is in the flow anyway, so switching from password to something that can be copied and revoked is only an improvement.

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

#116

Post by rocqua »

From the article:

> I'm referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or "magic" links sent via email.

I'm not entirely sure the argument holds for the magic links sent via email. To me, those feel like lower friction that entering a password. Because all of a sudden, users don't have to remember their password.

For any company considering this, I'd suggest looking at how often the 'forgot my password please send me an email' feature is used. I know that, before I had a password manager, there were accounts where I simply never remembered my password. I had to use them like once every month, and it was easier to just get the password reset link.

Now consider how much easier a 'click here and be logged in' link is than a password reset system. This only really gives friction for those few people who aren't always connected to their e-mail system. On account creation, this system is even better. All a user needs to enter is their e-mail address. No more needing to enter a password (twice!). No more dealing with password requirements.

"magic" e-mail links feel like they really could be a password killer in terms of lower friction.

However, it isn't clear at all that "magic" e-mail links are more secure than passwords. I'd guess that, given enough adoption, they'd develop some issues.

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

#117

Post by WorldMaker »

screye wrote: post #57
jrockway wrote: post #17

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

> I think the problem is that people don't understand how to use passwords From the looks of it, neither do the authenticators. The capital letter + symbol + number requirement had led to the current predicament. Just asking for really long passwords would have been a lot better. As it stands, people either use a predictable string of num-symbol to satisfy requirements or remember that one strong password,.which qual…

People aren't good at memorizing long lists of things, so just requiring long passwords isn't sufficient unless you are willing to also allow everyone to use the same password everywhere, and that's worse than the single point of failure problem than password managers because that's a distributed point of failure (just one breach of any site/application that you use; your security there is only as good as the weakest link).

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

#118

Post by kevin_thibedeau »

chme wrote: post #9
sbradford26 wrote: post #6

Earlier quoted context omitted.

The Nth letter of password thing sounds sketchy to me. Mostly because it sounds like they have my password in plaintext if they can check that.

No they just store a checksum for every letter of your password. /s

I'd hope they at least apply ROT13.

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

#119

Post by Ajedi32 »

orblivion wrote: post #19

If nobody understands anything other than passwords, how has 2FA taken off at all? How have password managers taken off at all? What if the password manager were in charge of logging you in _directly_, through some new protocol between browsers and PW managers? How could that _possibly_ be more friction? It would be strictly less. Hell, it could be done without even informing the user that this new feature was being…

> What if the password manager were in charge of logging you in _directly_, through some new protocol between browsers and PW managers?

FYI, this is exactly what WebAuthn is. The standard was just finalized in August. All we need now is some implementations.

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

#120

Post by kevin_thibedeau »

marcosdumay wrote: post #78
guidodassori wrote: post #47

The only password killer is a password manager. And guess what, is password protected.

Keepass can use a key file too.

Turning "something you know" into "something you have"... or anyone else can have too.
Post reply on HN