Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

151–160 of 277 posts

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

#151
post #112

Earlier quoted context omitted.

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

As opposed to "Oh, they want a password? I guess I'll use the same one I use for every other website." I agree that the business makes the decision, growth is the top priority and friction reduces growth, but in reality this is how most of the world already works. If you rent a hotel room you don't get to provide your own key and if you lose their key then you must prove who you are to get another one issued. In the…

Your hotel example is pretty absurd, because there's no friction involved in carrying around a hotel room key.

There is significant friction involved in memorizing a long password. So no, it's not "how most of the world already works".

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

#152
> Netflix requiring... 4. But I'm hesitant to berate Netflix for what seems like an extremely low number because they're also dealing with the usability challenge that is people logging on to TVs with remote controls

Amazon handled this great when I set up Prime Video streaming on my Sony Blu-Ray player. I don't remember the exact sequence because it was 8 years ago, but it was something like this:

1. Go to Amazon on my computer, log in, and tell them I'm trying to set up a new device for Prime Video streaming. They ask me for the make and model and serial number, which was available on the device in the Prime Video app.

2. Amazon gives me an integer. I don't remember the length, but I'm pretty sure it was in the 4-6 digit range.

3. On the Blu-Ray player, give that integer to the Amazon Prime Video app, and it completes the setup.

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

#153
post #116

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…

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)?

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

#154

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

Interestingly, we replaced our login with magic links only over a year ago. We have roughly 1600-2000 active users, and as far as I know, we've never had anyone request a password login. Not that I think about it.. it's kinda suspicious that no one has asked for it in all this time. Hmm..

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)?

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

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

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

Sure, but there's considerable risk of the user giving up signing up because they can't be bothered with memorizing a random password and want to set their own like every other service allows them.

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

#156

All valid points. But there two other main reasons I see as why (strong) passwords are essentially a superior choice to everything: 1) Using passwords properly is an exceptionally powerful way of protecting your account/data/etc. If you use strong, unique passwords and store in a password manager (with the PW database encrypted, of course), it's virtually impossible to break into anything on the user side of things.…

"If you use strong, unique passwords and store in a password manager (with the PW database encrypted, of course)"

You aren't talking about passwords the same way everyone else here, especially TFA, is talking about passwords. You might as well be talking about RSA keys at this point.

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

#157

Earlier quoted context omitted.

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…

screye is almost certainly referring to XKCD-style passwords, like "correct horse battery staple" [1] which are memorable and comparatively high-entropy, but don't have symbols or numbers. [1] https://xkcd.com/936/

Yes, one is memorable, which is why it is a great password for your password manager of choice. Again, the problem is if screye is advocating that password managers are a "single point of failure" and that length should be sufficient: people don't have the mental hardware to remember an XKCD-style password for every single website or application they use.

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

#158
post #140

Earlier quoted context omitted.

>People aren't good at memorizing long lists of things It's much easier to remember a 40 character passphrase of real words than a 12 character password of random symbols including punctuation

A 40 character password of real words is usually easier to crack than a random 12 character string, though.

Citation needed (that sounds wrong without seeing the maths).

But also missing the point. It just has to be better than the usual 8 + some punctuation at the end that most people resort to when faced with these shitty, asinine password rules.

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

#159

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

I don't know what password manager you use, but I use TouchID to access mine. Yes it still has a password, which I can type if I need to, but it's a device-local password (or PIN in the case of my phone).

I feel like every argument against password managers, uses the worst possible implementation as their basis for how they work.

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

#160
post #90

WebAuthn is coming. In fact, it's actually already here. There are only two things it needs before it can start to take over the world: a cross-browser, cross-platform implementation with synced credentials, and server-side implementations from a few large companies like Google and Facebook. A cross-browser, cross-platform implementation with synced credentials will solve the one remaining usability issue WebAuthn ha…

Doesn't WebAuthn require hardware?

I can't find any user examples that don't mention a phone or yubikey or whatever.

Post reply on HN