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

91–100 of 277 posts

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

#91

Post by Wowfunhappy »

lifeisstillgood wrote: post #65

Ancient Egyptians probably made the same argument "Keys just won't work - everyone knows how to use a door knob, but these new dangled keys, no one carries them, we have not invented key rings yet so people will fumble. Best not to." No people dealt with keys and locks because they did not want their stuff stolen. As more and more valuable stuff is kept behind our passwords we will accept more and more cost to protec…

Keys aren't actually secure at all. Anyone with a lock-pick and a bit of practice can break in. I'd say that's actually about equivalent to a poor password—it's not that secure, but random person off the street won't be able to break in with a snap of the finger.

Yes, with a password on the internet, there are far more possible attackers because you can attempt to break in from anywhere in the world. But that's somewhat beside the point—the standard locks we use on our homes are absolutely about convenience above ideal security. We could use locks that are more difficult to break, or keypads that require you to both turn the key and input a passcode. Most of us don't.

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

#92

Post by Ajedi32 »

Wowfunhappy wrote: post #87
scraft wrote: 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…

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

As long as they use the same browser on each of those platforms, they're good.

Yes, vendor lock-in is an issue; and I hope eventually there'll be a way to sync credentials across browsers. But keep in mind that, even as things are now, it only locks you to a specific browser, not to a specific OS.

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

#93

Post by quickben »

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

And that too, won't be a password killer.

Heck almost 20 years ago Nortel had something better than what you described, and still we have passwords around.

Everything old is new again, today we are solving passwords with X, tomorrow with Y, etc.

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

#94

Post by creeble »

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…

Where does 2fa replace passwords? It's two FA after all.

And I'd assert that password managers haven't exactly taken off; I'd be curious about their numbers, but the dozen or so people I know who use one are all software engineers. Also, they don't really replace passwords - they're based on them!

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

#95

Post by elcomet »

FooBarWidget wrote: post #62
AstralStorm wrote: post #56

Earlier quoted context omitted.

This does not work, you're a single point of failure. If you say, get sick, family members will override security. Nice try though. I'd recommend an actual password manager instead. Authenticated with biometrics and a simpler local password. Your service does the same, using voice and phone number as biometrics. (Perhaps with recovery question.) Feel free to replace it with sufficiently advanced AI.

Please, try to be in my shoes. Even teaching copy-paste is so difficult, how do you want me to teach them biometrics? The "I'll manage all your passwords for you" is the only solution that actually works. The ONLY other alternative is that they use 123456 as password everywhere. I already explained why I can't get them to use a password manager.

So what if 123456 is a sensible password for them? Explain them why they should use a more secure password. If they don't get it's maybe they really don't need a more secure password (they don't care who has access to their accounts, and the likelihood of them being hacked is very low).

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

#96

Post by Ajedi32 »

ngrilly wrote: post #70
devit wrote: 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.

I agree, but how do you trigger the "save password" dialog of the browser built-in password manager, when using a generated random password? Edit: Answering to myself, maybe by generating the random password client-side, with JavaScript, and making the HTML input field non-editable. I've not tested it.

Or by using WebAuthn, which has an explicit API you can call to store a password in the browser.

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

#97

Post by Ajedi32 »

quickben wrote: post #93
Ajedi32 wrote: 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…

And that too, won't be a password killer. Heck almost 20 years ago Nortel had something better than what you described, and still we have passwords around. Everything old is new again, today we are solving passwords with X, tomorrow with Y, etc.

Webauthn is a web standard; not a proprietary product by a company I've never heard of.

Whatever it was Nortel had, I highly doubt it was as usable or ubiquitous as what WebAuthn already is.

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

#98

Post by Filligree »

Ajedi32 wrote: post #92
Wowfunhappy wrote: post #87

Earlier quoted context omitted.

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

As long as they use the same browser on each of those platforms, they're good. Yes, vendor lock-in is an issue; and I hope eventually there'll be a way to sync credentials across browsers. But keep in mind that, even as things are now, it only locks you to a specific browser, not to a specific OS.

Exporting the passwords is also possible, so it's not really much lock-in. Not to the kind of person who'd care, and want to switch browsers.

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

#99

Post by vertex-four »

Wowfunhappy wrote: post #87
scraft wrote: 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…

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

I think most browsers can import most information from most other browsers at this point.

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

#100

Post by Filligree »

new299 wrote: post #26
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.

Yes, it almost certainly is quite sketchy... I can’t think of any way it could be securely implemented. In the case I’ve seen it’s the only password used... I wonder if there is a hashing scheme that would work with some kind of ambiguous entry... I.e. “is the 3rd digit between 5 and 10”. If you could confirm certain properties of a password/pin from its hash...

I could believe this would be possible with homomorphic encryption, even with today's capabilities, but I can't prove that; I'm not terribly familiar.

That is not to say that it's very likely, because it's not.

Post reply on HN