Getting Started with Security Keys • Hacker News Board

Re: Getting Started with Security Keys

#71

Post by tjoff » Thu, Oct 31, 2019, 12:38 PM UTC

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 you just must make sure to remember that password that you never use, even when in distress... Not that straightforward either.

Also upon use any "smart" site would flag it for unusual activity and lock you out until you can verify it.

I guess I'm stuck with passwords.

Re: Getting Started with Security Keys

#72

Post by kop316 » Thu, Oct 31, 2019, 12:42 PM UTC

CGamesPlay wrote: post #70

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

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

Re: Getting Started with Security Keys

#73

Post by akerl_ » Thu, Oct 31, 2019, 12:47 PM UTC

lixtra wrote: post #64

akerl_ wrote: post #51

Earlier quoted context omitted.

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.

All of these aren’t related to your 1password vault. They all occur even if you’re using your phone as a totp device.

Re: Getting Started with Security Keys

#74

Post by ti_ranger » Thu, Oct 31, 2019, 12:55 PM UTC

burner589432 wrote: post #22

_jal wrote: post #16

Earlier quoted context omitted.

Other folks have mentioned things you missed, here's another: insider threats. A authentication event requiring a hardware token is significantly harder to deny, especially if used again by the legitimate user after the questionable event. So any insider attacks that are not last-hurrahs or one-shots plausibly explained by theft are significantly riskier.

If you're trying to prevent credential theft: Educate users on password managers, deploying 2FA, or tokens like this would also make sense. MFA deployments are probably significantly cheaper though (And yes, ActiveDirectory OTP and smartcard based MFA tools exist). Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many peopl…

> Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone.

(Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device).

Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP

Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin.

> I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.

Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious).

I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...).

And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.

Re: Getting Started with Security Keys

#75

Post by jessaustin » Thu, Oct 31, 2019, 1:04 PM UTC

kadoban wrote: post #36

pvg wrote: post #25

Earlier quoted context omitted.

It would be abundantly obvious to me That's what people say but even security experts have fallen for phishing attacks. And 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.

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/" since they're both owned by the Jockey Club.

Re: Getting Started with Security Keys

#76

Post by casefields » Thu, Oct 31, 2019, 1:19 PM UTC

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…

For me, I have a sibling I trust to store a set of back up codes in their fire safe across the country. Another option would a lawyer, such as one you already have a will with. That would be an expense though.

Re: Getting Started with Security Keys

#77

Post by zeroxfe » Thu, Oct 31, 2019, 1:42 PM UTC

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…

The author was pretty clear about the risks:

> This solution is fine for most people, but this section is about being a bit more paranoid, so I would recommend not using the 1Password integration for your one-time password codes.

> The more extreme option is to manually keep track of the QR code or setup key provided when setting up 2FA for a TOTP authenticator on each account. Backing up these setup codes is a bit controversial and not recommended by the more hardcore security folks as it introduces another avenue by which you could be compromised if not securely stored. If you opt to backup your QR codes, you may want to store them outside of your password manager and in an encrypted manner.

Re: Getting Started with Security Keys

#78

Post by minty_phoenix » Thu, Oct 31, 2019, 1:42 PM UTC

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…

Many services offering 2FA, esp. TOTP, will give you a set of backup codes – print/store them separately, safely (using the rule of backups). At the very least, Google does and allows you to view the existing ones and I think regenerate new ones on-demand as long as you can currently securely access your account.

The same can be done with security keys – typically you can add more than one to your account so have at least two and keep one stored safely somewhere.

Sadly, I recently set up an AWS account and, from what I could tell during that period, they support TOTP/hardware keys, but you can seemingly only pick a single 2FA method – so either TOTP or one single hardware key. That’s a service I would have expected better from (or perhaps I am misunderstanding my settings panel where I can’t find a way to add another factor – I am rather new to managing that ecosystem/account).

Re: Getting Started with Security Keys

#79

Post by zie » Thu, Oct 31, 2019, 1:45 PM UTC

londons_explore wrote: post #48

undefined3840 wrote: post #28

For some reason I‘m basically locked out of any paid Google product because my Google Pay account is disabled for whatever reason. I think it might have been flagged for fraud years ago and now cannot use it at all, including for Fi. It’s crazy.

Set up a new account, and remember not to link the new or old accounts by way of a recovery email address or using the same phone number. It's a bit of a hassle, but most things you can transfer over between the accounts, and then just dump the old one. Lots of effort, but the only way unless you know an employee to get the block removed.

Or just get off the Google bandwagon.

Googles customer service: None

Google's care of their users: None

Google's desire to sell every single thing about you they can figure out: Unlimited.

Re: Getting Started with Security Keys

#80

Post by tialaramex » Thu, Oct 31, 2019, 1:56 PM UTC

ti_ranger wrote: post #74

burner589432 wrote: post #22

Earlier quoted context omitted.

If you're trying to prevent credential theft: Educate users on password managers, deploying 2FA, or tokens like this would also make sense. MFA deployments are probably significantly cheaper though (And yes, ActiveDirectory OTP and smartcard based MFA tools exist). Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many peopl…

> Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone. (Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device). Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on…

Banks inside the EU probably can't easily go to WebAuthn because they're coming under rules that say their multi-factor authentication needs to tie into transaction details.

The concern is, a customer is tricked into _legitimately_ authorising transaction A ("Send my cousin $50 for emergency cab fare") but the bad guys use the authorisation instead for transaction B ("Send my entire account balance to Anne Actual Crook in Russia") and the bank thinks everything checks out because they used multi-factor. Making the transaction details part of the authentication can defuse this significantly if you do it properly.

A straight forward WebAuthn setup which is just proof of control isn't enough there. Maybe you can put together something using extensions to WebAuthn or fudge it somehow to add these transaction details, but out of the box the banks seem to be going for:

* Bank branded authenticator apps for smartphones

* SMS (ugh)

* Custom authenticator devices with their own input