Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

271–277 of 277 posts

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

#271
post #57

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

The problem with that is that in quite some cases I don't care about the security so I can just use a crap password.

But a sufficiently long password could literally just be 'a', repeated. Would that really be more secure?

Honestly if you want somebody to have a secure password, make it for them and e-mail it to 'em. Virtually no chance they are going to use it for anything else, and if somebody has their e-mail, they can recreate one anyway.

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

#272

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…

In that case the user would use their e-mail as password manager.

Which might be an improvement or might not.

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

#273

Has anybody made a list of [Insert Thing Here]s? I'm curious what kind of trade-offs they offer.

Here's a great one from Pico project:

http://www.cl.cam.ac.uk/~fms27/papers/2012-BonneauHerOorSta-...

Other publications that might interest you:

http://pico.cl.cam.ac.uk/technical/

Ross Anderson's blog, LightBlueTouchpaper, has writeups on this in authentication category.

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

#274
post #135

Earlier quoted context omitted.

There are some minor issues with the magic link workflow - one of them is security scanning software potentially visiting the link. So then you need to open the link in the same browser you want to use. But what if you want to log in on a desktop browser and only have your email on your phone? Maybe have the magic link show a couple letters you need to type into the browser?

They are trivially solvable problems. PKCE and just displaying a QR code if you open it on the wrong device makes it pretty much foolproof. e.g.: https://magic.cuvva.com/auth-callback?code=authzcode_000000B... We're oriented around mobile use cases. Admittedly less ideal if you don't have your email on your desktop. But ultimately, if all else fails, you can always log into your webmail. For me the key thing is that…

Does this work for the case you have your email on your phone but you want to use the site on a computer? That seems more likely to me than the case that you have your email on your computer only, but it is neat to see that case addressed.

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

#275
post #216

Earlier quoted context omitted.

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

Is this a JavaScript joke?

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

#276

Earlier quoted context omitted.

They are trivially solvable problems. PKCE and just displaying a QR code if you open it on the wrong device makes it pretty much foolproof. e.g.: https://magic.cuvva.com/auth-callback?code=authzcode_000000B... We're oriented around mobile use cases. Admittedly less ideal if you don't have your email on your desktop. But ultimately, if all else fails, you can always log into your webmail. For me the key thing is that…

Does this work for the case you have your email on your phone but you want to use the site on a computer? That seems more likely to me than the case that you have your email on your computer only, but it is neat to see that case addressed.

Yeah it's a fair point. The case I mentioned is for Cuvva, which currently is mobile-only.

Webmail is always a decent backup option though, so doesn't give me too much concern in terms of people getting stuck. But may be a little less seamless, particularly if they're using a shared/public computer. That scenario throws password managers out of the window too though.

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

#277

Earlier quoted context omitted.

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

Not sure about Chrome, but Firefox encrypts everything on the client before syncing, they only see blobs of bytes. Plus you can run your own Sync server.

Ancient reply, but...

Even if Firefox "encrypts" before syncing, they must decrypt in order to provide the clear text password from another browser, no? They don't send "blobs of bytes" to password form entries.

Post reply on HN