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

91–100 of 104 posts

Re: Getting Started with Security Keys

#91

Post by bradstewart »

chowell wrote: post #34
vel0city wrote: post #30

Earlier quoted context omitted.

Including printable backup codes, most services supporting FIDO U2F or WebAuthn support tying multiple security keys to your account. Many of these authenticator devices are pretty cheap these days, its not insane to have a few of them. Have one on your keychain, another in a desk drawer, etc.

I was super surprised to learn AWS will only allow you to register a single FIDO token - the inherent lockout risk pushed me back to using OTP with the seed stored in multiple Yubikeys.

Yea it's very annoying. I ended up making multiple IAM users--one for each of my security keys.

Re: Getting Started with Security Keys

#92

Post by bradstewart »

parliament32 wrote: post #86

>I use and love 1Password and pay for the cloud account Is it just me, or does a hosted password manager smell like an absolutely terrible idea to anyone else?

The convenience outweighs the risks for the vast majority of users. My parents need something that is available on all devices, syncs automatically, and requires no maintenance.

You get a master encryption key that never leaves your device when setting up the account. Anything that touches their servers is encrypted with that key. You need that key to setup a new device (in addition to your username and master password).

Re: Getting Started with Security Keys

#93

Post by burner589432 »

tialaramex wrote: post #61
burner589432 wrote: post #19

Earlier quoted context omitted.

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

Last I checked hooking key events in Windows requires SYSTEM access.

Stealing session tokens can be as easy as just pulling the entire browser profile, which I doubt requires elevated access.

I imagine black market postexploitation kits would have session data theft as a feature.

Again, if somebody has system access, you're probably completely fucked from a different angle irrespective of your preferred authentication method so now we're talking about semantics of how you're getting fucked because most 'apt's are going to be grepping your disk for words key phrases like 'financial data', not caring about your facebook account.

Re: Getting Started with Security Keys

#94

Post by allset_ »

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.

Yubico Authenticator for iOS was released today.

Re: Getting Started with Security Keys

#95

Post by dfox »

setheron wrote: post #82
kop316 wrote: post #72

Earlier quoted context omitted.

https://developers.yubico.com/U2F/Protocol_details/Overview.... Via the U2F protocol, the browser embeds the URL and optionally the TLS Channel ID in the challenge, so a phishing website asking for a challenge will produce the wrong challenge (and response). Note this does not prevent an attack via webUSB ( https://www.wired.com/story/chrome-yubikey-phishing-webusb/ ).

There's no we ay to stop a full MITM though where maybe the State took over the certificate of a site.

If the Channel ID is included it stops MITM completely.

In fact doing the authentication inside the secure channel in a way that depends on the key that is used by such channel is the best way to perform mutual authentication. In MitM case the authentication will just fail and passive attackers cannot learn anything about the identities used for authentication.

Both SSH2 and many Windows-related protocols work in exactly this way.

Re: Getting Started with Security Keys

#96

Post by mxschumacher »

dragonwriter wrote: post #57
mxschumacher wrote: post #54

Earlier quoted context omitted.

The requirement I've set for myself is that I should not lose access to my accounts of data if I lose some or all of my hardware, be it to mechanical failure, theft or me losing my phone somewhere. I don't think there's any way around having a safe physical location to store backup codes / secrets on paper.

Codes on paper are still bits of hardware that can be lost, stolen, or destroyed.

I'm less likely to lose a piece of paper in a safe than I am to lose the phone in my pocket

Re: Getting Started with Security Keys

#97

Post by dfox »

burner589432 wrote: post #93
tialaramex wrote: post #61

Earlier quoted context omitted.

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

Last I checked hooking key events in Windows requires SYSTEM access. Stealing session tokens can be as easy as just pulling the entire browser profile, which I doubt requires elevated access. I imagine black market postexploitation kits would have session data theft as a feature. Again, if somebody has system access, you're probably completely fucked from a different angle irrespective of your preferred authenticatio…

While it is true that hooking _all_ keyboard input requires SYSTEM access (because it involves either impersonating the session manager or injecting code into kernel), you don’t really need that to exfiltrate passwords for random websites that are entered into web browser. Owner of session can hook any event that is passed to the session, which obviously includes any keyboard event that the browser is going to see.

Re: Getting Started with Security Keys

#98

Post by mceachen »

jessaustin wrote: post #75
kadoban wrote: post #36

Earlier quoted context omitted.

It's really quite unusual. I'm not sure what password managers these security experts are using, but there's no way it works like mine (bitwarden). I've never had it fail to recognize the domain, which is good because that seems like really obvious functionality. I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything bef…

Sure it can handle logins to both "theircompany.com" and "service.theircompany.com", assuming the cert is set up correctly. It probably isn't going to figure out that those are related to "theircompany-service.net". This would arguably be a failure in domain setup, but I've certainly seen similar setups before. Example: " https://hbweb.incompass-solutions.com/" uses the same credentials as " http://www.equineline.com…

Some password managers (like bitwarden) allow for N URL patterns for a given credential, for exactly this purpose.

Re: Getting Started with Security Keys

#99

Post by GoblinSlayer »

datguacdoh wrote: post #15
bodhi wrote: post #11

Earlier quoted context omitted.

How about phishing?

100% this. Phishing is incredibly common, really difficult for even sophisticated users to detect when done well, and the best password manager isn't going to help you. A security key will all but guarantee that this isn't an issue and is a pretty good UX too.

>really difficult for even sophisticated users to detect when done well

Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.

Re: Getting Started with Security Keys

#100

Post by deadbunny »

tjoff wrote: post #71
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.

Yeah, scenario that I still need to solve is: Go on vacation, loose your phone and security key (along with any written passwords) - by robbery, theft, customs or accident. You'd still need to be able to access your email etc. or else your experience is going to be a hundred times worse. What you really want is optional 2FA. You have a regular (unique) password but you never use it unless there is an emergency. Now y…

1. Buy 2 yubikeys (with U2F)

2. Add both for each site you use it for

3. If using gpg keys you masterkey lives on a USB key, use subkeys which get transferred onto both yubikeys

4. Lock one the USB key and 2nd yubikey in a safe* with the password you never use

5. If you lose your day to day keys, unlock safe

*safe can be an actual safe, a "secure enough" place in your house, a bank safety deposit box, etc... You can also have multiple safes, one on site, one offsite.

Post reply on HN