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

71–80 of 277 posts

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

#71

Post by yjftsjthsd-h »

leetcrew wrote: post #48
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…

> 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. or it would force them to click "reset my password" every time they use your service. now your service is only as secure as their email account.

> now your service is only as secure as their email account.

Surely that was already true?

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

#72

Post by thecatspaw »

devit wrote: post #52
LeonM wrote: post #37

Earlier quoted context omitted.

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

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

#73

Post by PunchTornado »

still blows my mind how companies like medium think they use a superior system by making you log in to email in order to log in to medium.com

makes my 1password app useless and I just don't bother to login to medium => irrelevant articles => less time spent there.

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

#74

Post by lexs »

ilovetux wrote: post #51
lexs wrote: post #46

Earlier quoted context omitted.

At that point why not just switch to PKI?

pki is a barrier to entry for most. the user would have to set their browser up to present a unique key pair for each site they use. I think mutual auth is better suited to automated administrative tasks.

but isn't a password manager just as much of a barrier in this context?

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

#75

Post by snarf21 »

cyborgx7 wrote: 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…

It is generally always a trade-off between security and convenience. You can demand that a site allow passwords but you also aren't memorizing a 24 character nonsense password for each site login. The holy grail is can you bend the line and have something that is super secure and mostly convenient.

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

#76

Post by scraft »

I signed up for something recently and on the password screen it popped up with something along the lines of "Hey, can we generate a secure password for you, don't worry, your browser will remember it for you?" I said yes, sure enough a strong password appeared and Chrome offered to remember it. Seemed like a nice introduction to using secure passwords. The next thing I signed up for I manually generated a secure password and pasted it in and that is now stored in my browser too.

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

#77

Post by throwawaymath »

frutiger wrote: post #67
throwawaymath wrote: post #64

Earlier quoted context omitted.

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.

Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether there is processing or not.

I guess what I'm asking is this: can someone walk me through the attack scenario? I don't really get it.

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

#79

Post by paulryanrogers »

bad_user wrote: post #13
myWindoonn wrote: post #2

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.

An URL with a randomized path in it is, technically, a password. Also note that the transportation mechanism is pretty weak. If the URL is passed over HTTPS, then that keeps your ISP from seeing it, however it can still show up in logs on the server side or the client side, in your history. A URL will be remembered or even cached by your browser, whereas a regular password won't, unless you explicitly allow it. A reg…

If those password-URLs are one time use then they are better than a static password. Still, it's likely those are managed via email which makes that a single point of failure.

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

#80

Post by Sean1708 »

simias wrote: post #41
cyborgx7 wrote: 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…

I agree that it's a more salient point IMO. Smartphone based authenticator are not exactly difficult to understand, at least from a user's perspective. You enter your username, you get a prompt on your password, you're done. Yubikeys are not difficult either. You enter your username, you focus the password field and you press the button. There, you're done. If anything it's easier and more convenient than a password.…

> You enter your username, you focus the password field and you press the button.

How much set up does it take to get to that point though? Usability at point of use is great but setting something up is usually far more difficult than actually using it.

Post reply on HN