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

51–60 of 104 posts

Re: Getting Started with Security Keys

#51

Post by akerl_ »

lixtra wrote: post #47
jen729w wrote: post #31

Earlier quoted context omitted.

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.

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?

Re: Getting Started with Security Keys

#52

Post by teekert »

Boulth wrote: post #50
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.

Exactly this. And that's why AWS's U2F feature is basically useless. They should've allowed to add multiple keys simultaneously.

With andotp I can export/backup the keys and use them on other devices. Also, you could scan the qr code (private key) with devices or print it out and keep it safe.

Re: Getting Started with Security Keys

#53

Post by tialaramex »

burner589432 wrote: post #29
kadoban wrote: post #17

Earlier quoted context omitted.

Correct me if I'm wrong, but password managers can prevent quite a lot of phishing, because autofill can automatically check the domain. It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme. (this is not to downplay security…

> 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 you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.

Re: Getting Started with Security Keys

#54

Post by mxschumacher »

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.

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.

Re: Getting Started with Security Keys

#55

Post by Boulth »

ryukafalz wrote: post #13
allset_ wrote: post #12

Earlier quoted context omitted.

For bonus points, you can also sign your Git commits.

Yup! And it's simple enough to do this automatically by just putting this in your gitconfig: [user] signingkey = [commit] gpgsign = true

You don't need signingkey if you have a GPG key with the same email as your git user.email (I guess that's the majority of cases).

Re: Getting Started with Security Keys

#56

Post by Boulth »

teekert wrote: post #52
Boulth wrote: post #50

Earlier quoted context omitted.

Exactly this. And that's why AWS's U2F feature is basically useless. They should've allowed to add multiple keys simultaneously.

With andotp I can export/backup the keys and use them on other devices. Also, you could scan the qr code (private key) with devices or print it out and keep it safe.

Yeah but U2F is more secure (non exportable key, non phishable). With AWS OTP is the only viable option.

Re: Getting Started with Security Keys

#57

Post by dragonwriter »

mxschumacher wrote: post #54
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.

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.

Re: Getting Started with Security Keys

#58

Post by cuu508 »

ryukafalz wrote: post #9
ggm wrote: post #6

SSH key storage needs more info I think. I am using SSH enough that this '...can also do SSH...' would want to be the main topic. advanced modes disabling API keys means a lot of the older third party integrations which depend on a simple API token are SOL. this worries me, lockin risks.

>SSH key storage needs more info I think. I am using SSH enough that this '...can also do SSH...' would want to be the main topic. Different audiences, I think - this article doesn't go into technical details that often besides mentioning various protocols and what they do. Using a Yubikey for SSH (either via GPG or X.509 certs) is significantly more involved than using one for U2F/FIDO2. There's a pretty in-depth gu…

There's also DrDuh's pretty comprehensive guide https://github.com/drduh/YubiKey-Guide

Re: Getting Started with Security Keys

#59

Post by thedanbob »

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.

Not locking yourself out and not letting a company lock you out. When the article started talking about using Google’s registrar, advanced account protection, and Google Fi, I started wondering whether it’s more likely these days to get specifically targeted for an online attack or for Google to randomly decide to lock your account forever.

Re: Getting Started with Security Keys

#60

Post by tialaramex »

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?

Terminology clarification: The seed driving TOTP is a shared secret but NOT a symmetric key.
Post reply on HN