Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Started with Security Keys

paulstamatiou.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Getting Started with Security Keys

#61

Post by tialaramex »

burner589432 wrote: post #19
judge2020 wrote: post #10

Earlier quoted context omitted.

> Unpopular opinion Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.

If malware is in a position to steal data from your clipboard or keylog your device, it's very likely to be in a position to hijack your session tokens.

Dubious. On a desktop device it's really common for there to be mechanisms that make it easy for software to steal the clipboard contents and intercept keypresses because these are things that some legitimate desktop software needs. There may often be a documented API that even a mediocre programmer can use to get this working in a few hours.

On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard.

I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.

Re: Getting Started with Security Keys

#63

Post by eaguyhn »

jen729w wrote: post #31
skybrian wrote: post #26

I would put greater emphasis on not locking yourself out, since that's the most likely threat for many people. Losing your phone (or having it die on you) is common and you should assume you'll do it sooner or later. Print out backup codes and store them somewhere safe that you won't forget before enabling two-factor authentication that depends on you having your phone or other device that can break.

Or you upgrade your phone, or wipe your phone for some reason, and forget that your OTP codes don't transfer over. This is one reason I love OTP codes stored in 1Password. That was until I read a post here which convinced me that this approach is a total waste of time as I no longer truly have '2FA'. I have 1FA, and that is 1Password.

You could use Yubikey with Yubico Authenticator - the secret key is stored in the Yubikey. I did this because phone upgrades were a PITA, as you alluded. If you wanted you could have two Yubikeys (I have my second one in a safe deposit box).

Re: Getting Started with Security Keys

#64

Post by lixtra »

akerl_ wrote: post #51
lixtra wrote: post #47

Earlier quoted context omitted.

Having 2FA in 1Password is still strictly stronger than 1FA. The a leaked OTP token stays valid for about 60 seconds. Your leaked password may never change.

What is the threat model where an attacker gains access to your 1password vault in a way that gives them only a single OTP code and your password, and not the underlying symmetric TOTP key?

- using your password on a compromised desktop

- attacker looking over your shoulder as you enter your password

- Company mitm breaks open ssl encryption and reveals your password.

Obviously, if someone breaks into your 1Password it’s game over.

Re: Getting Started with Security Keys

#65

Post by Bnshsysjab »

tialaramex wrote: post #53
burner589432 wrote: post #29

Earlier quoted context omitted.

> since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there. I imagine you can extract passwords out of security keys in some form without being on the correct domain, too. Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to ena…

WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account. There's no UI. Even if yo…

What’s to stop a password manager behaving in the same way?

Re: Getting Started with Security Keys

#66

Post by jacekm »

sebazzz wrote: post #44

I have a Yubikey but I can't use it fully yet: - There is no Yubikey OTP app for the iPhone - Safari iOS does not respond to WebAuthn APIs (the apis are available but don't have any effect). I rather use plain Safari or Firefox, so Brave browser is not an option for me.

> does not respond to WebAuthn APIs Hmm, is it still the case? I don't have an iPhone, but after reading this post https://www.yubico.com/2019/09/yubico-ios-authentication-exp... my understanding was that WebAuthn will now work with all browsers, not only Brave.

Re: Getting Started with Security Keys

#67

Post by jen729w »

wonnage wrote: post #49
alpb wrote: post #38

I can't help but think the author has recommended (1) storing backup keys (presumably in 1Password?) (2) storing OTP key generation QR codes in 1Password, so it can generate OTP codes for you. Doesn't this defeat the whole purpose of "two"-factor authentication? If your 1Password gets hacked the attacker has both your passcode and one-time password? You should consider keeping these two separate: If your 1Password un…

It's slightly less secure but much more convenient, which I think is worth the trade-off. Just having 2fa on means you don’t have to worry if a website has its passwords compromised, which is probably the biggest threat for most people.

See my comments elsewhere in this thread. I’d argue that ‘having unique passwords for every site’ is much more important than 2FA when it comes to the consequences of a site’s database being compromised.

For instance, I’ll happily give you my password to ‘My Vodafone’. It’s nXewr7Vq4f)s9>ky. It really is. I don’t give a shit if their database is compromised, it doesn’t affect the rest of my life.

(I haven’t been a customer in about a decade. The login no longer works. You get the point.)

2FA adds nothing to this scenario. I should assume that an attacker who has compromised the site’s database has also compromised their OTP systems.

Re: Getting Started with Security Keys

#68

Post by tialaramex »

Bnshsysjab wrote: post #65
tialaramex wrote: post #53

Earlier quoted context omitted.

WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account. There's no UI. Even if yo…

What’s to stop a password manager behaving in the same way?

Compatibility.

Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise.

If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product.

But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding.

The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.

Re: Getting Started with Security Keys

#69

Post by burner589432 »

Bnshsysjab wrote: post #65
tialaramex wrote: post #53

Earlier quoted context omitted.

WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account. There's no UI. Even if yo…

What’s to stop a password manager behaving in the same way?

So... Nothing apart from some convoluted anecdote?

If currently there's no password manager in existence that doesn't let you override the plaintext password extraction / override feature, there's nothing to stop one being made. You could probably hook it in with a system level service which cryptographically signs them, too.

Re: Getting Started with Security Keys

#70

Post by CGamesPlay »

> TOTP risks - You could still fall victim to a fake website (or real one being proxied via man-in-the-middle like with Evilginx 2 and Modlishka)

> Security key benefits - Even if the user willingly tried to log into a fake phishing site, the security key authentication would not work as the domain would differ.

Why are security keys secure against man-in-the-middle attacks?

Post reply on HN