Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

211–220 of 277 posts

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

#211

Earlier quoted context omitted.

Or use more than one device to login?

All major browsers can sync their passwords across their desktop and mobile versions. I use Firefox Sync on two laptops, one desktop and an Android phone.

I was unaware that Firefox / Chrome can own all your passwords in their cloud.

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

#212
post #133
post #86

Earlier quoted context omitted.

I know that environment well, you pretty much have to come up with a hash function you can do in your head. Is it secure? Maybe you can pull it off. I think most people can't, and that's what leads to people writing down passwords.

Writing down passwords is usually less bad than password reuse and use of weak passwords.

Its the same concept of the majority of offline password managers. You are hiding all of your amazing 32 character randomly generated unique passwords behind a single memorable password.

BUT its safe, because unless YOU are the target of the attack, the contents of your random slip of paper on your desk, or the password protected one note file on your dropbox, or the encrypted pwsafe3 file on your usb stick are outside of the reach of some bad actor trying to get ALL of the passwords, not just YOUR password.

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

#213

Earlier quoted context omitted.

I would never claim there is no legitimacy to enforcing 2FA. At my last job we ran into a situation like that. I always lacked things other people and services took for granted for financial and political reasons (like a smartphone). When we were required to use 2FA for some services at work it caused some friction for me. We found a workable solution, but it was less than ideal. They were right to turn on 2FA but it…

For your telnet example, you can still use ncat, opens, or gnutls-cli to enter HTTP commands directly over a TLS transport. Yes it's more complicated, but it's still doable.

Of course I feel a lot better using ssh than using telnet. I just don't want people to discount that this added complexity is the price we pay for the security.

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

#214

Earlier quoted context omitted.

You got it backwards. Vendor lock-in rarely applies to experts. It is the people who "don't care" that _we_ should care about protecting from lock-in. After all, that is how we got internet explorer 6.

Those, in my experience, are the same people who can't switch browsers. They aren't capable of learning new things, and can often barely keep going with what they have.

Not in my experience. They are the people who just don't care. What they have works well enough, so they don't look to change it.

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

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

Or, what if I don't own a phone? I do own a phone, but my wife does not because she doesn't want one.

I am particularly empathetic to that position, because I didn't own a phone until very recently and it caused a bunch of problems for me. It informed my perspective a lot.

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

#216
post #163

Troy Hunt's whole career is basically based on the brokenness of passwords, but now he's defending them here, and then touting his own services that claim to make passwords better. Something is fishy here. It could be that passwords are terrible, but everything else is worse, but I'm not convinced. We have had a big push towards SSL (TLS, actually) everywhere lately. I don't have to ask Amazon for a password to verif…

Troy Hunt's whole career is basically based on the brokenness of passwords... That's unfair. Troy's career is based on the brokenness of bad password implementations , not passwords themselves.

If every implementation of an idea is bad, maybe the idea is bad

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

#217
post #76

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

Most browsers still don't have a second line of defense (like password managers do), correct? So, if a user has access to my browser for two mins, they can see all my passwords in plain text. They can't if my passwords are in password managers which will ask for my master password. I never understood why browsers didn't give an option to have a bit more security with those passwords. Just let the user enter one master password before they can see their stored passwords.

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

#218
What is wrong with magic links exactly?

Email already is the single point of failure, password resets. People are already used to looking at their email, account verification etc. People are already used to looking at their email after signing in, 2nd factor with email exists on some sites.

Downsides are that they might be scanned by security software and visited, but surely that's also a problem for verification links? I can't imagine that people would appreciate accounts being automatically verified...

All other reasons I can think of indicate a problem with password resets as well, which also gives access to the account anyway.

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

#219

Earlier quoted context omitted.

We've had "magic" links as the primary sign in method for our site for about a year now. It works well but we very regularly get requests to allow password login. So much so that we'll introduce that eventually. Seems like both in combo could be a nice solution, but I'm sure we'll just start getting support requests from people whose password doesn't work because they never set one...

Did you have issues with delayed email delivery (the user wants to login but the email is delayed because of some grey listing or some network glitch)?

No, we use Postmark which delivers very fast.

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

#220

Earlier quoted context omitted.

Did you have issues with delayed email delivery (the user wants to login but the email is delayed because of some grey listing or some network glitch)?

No, we use Postmark which delivers very fast.

We use Mailgun which delivers quite fast, but we noticed that some customers, especially the big companies with an IT department running its own email server, tend to have some form of greylisting: if it is the first time they receive an email from our system, then they refuse it temporarily, and ask our system to retry in (for example) 5 minutes. Mailgun manages this nicely, but during those 5 minutes, the user is still waiting his/her magic link.
Post reply on HN