
Getting Started with Security Keys - flyosity
https://paulstamatiou.com/getting-started-with-security-keys/
======
skybrian
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.

~~~
jen729w
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.

~~~
lixtra
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.

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

~~~
lixtra
\- 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.

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

~~~
labawi
I think the point wasn't that 1password TOTP is more secure than separate TOTP
device, probably even less secure than typical alternatives, but it is
present, convenient, automatically backed up and safer than just a password.

------
ssivark
> Switch your carrier to Google Fi

Now no one can socially engineer access to your account -- including you
yourself, in case you're locked out :-)

~~~
1984victim
So is Google Big Brother?

------
peterwwillis
I think calling this 'paranoid' is a bit misleading. Paranoia suggests you are
deluded or irrational, and that nobody's out to get you. In reality, people
_might_ be out to get you, just like walking a city street, someone _might_ be
looking to mug you. The difference is, they aren't looking for _you_
specifically, the chances are pretty low of you running into them, and you
shouldn't be overly worried or take too many precautions just because of that
possibility. But you should be informed, and let your awareness of the
possibility inform your actions.

------
sebazzz
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.

~~~
jacekm
> 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...](https://www.yubico.com/2019/09/yubico-ios-
> authentication-expands-to-include-nfc/) my understanding was that WebAuthn
> will now work with all browsers, not only Brave.

~~~
sebazzz
No, I tried it. The APIs work normally from the web application perspective,
but no prompt comes up to connect the security key. You also need to enable it
from the experimental features page.

------
alpb
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 unlocks with
FaceID, do not make your Authy (or etc.) also unlock with FaceID. Otherwise,
you're defeating the purpose of 2FA (something you "know" and something you
"have"), I think.

~~~
wonnage
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.

~~~
jen729w
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.

~~~
tialaramex
This is true for some 2FA methods but you can literally publish all the data
for WebAuthn and it won't make any difference to the security for your users
or your site. Same reason seeing the certificate for Hacker News doesn't get
you any closer to successfully impersonating the site, public key
cryptography.

Bad guys who steal my WebAuthn credentials for foo.example don't learn how to
sign in as me on any site at all, even on foo.example. If they break into
another site. bar.example and steal all their WebAuthn credentials too, they
can't even correlate them to figure out who has sign-ins on both sites.

------
undefined3840
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.

~~~
londons_explore
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.

~~~
zie
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.

~~~
SaturateDK
To be fair they may have customer service, but you are not the customer but
the product.

------
ggm
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.

~~~
ryukafalz
>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 guide here on using one as a GPG smartcard with SSH
(that's what I do): [https://zeos.ca/post/2018/gpg-
yubikey5/](https://zeos.ca/post/2018/gpg-yubikey5/)

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

~~~
ryukafalz
Yup! And it's simple enough to do this automatically by just putting this in
your gitconfig:

    
    
        [user]
            signingkey = <your GPG fingerprint here>
        [commit]
            gpgsign = true

~~~
Boulth
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).

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

~~~
bradstewart
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).

------
breadandcrumbel
OP comment from Reddit post:

>Hey folks, OP here. I’ve been using security keys for a few years now and
decided to spend some spare time over the last few months writing this up.
Despite the name it’s pretty detailed (15k words!) and hope it can help folks
understand the benefits of security keys and what fido2 brings to the table.

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

~~~
kop316
[https://developers.yubico.com/U2F/Protocol_details/Overview....](https://developers.yubico.com/U2F/Protocol_details/Overview.html)

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/](https://www.wired.com/story/chrome-yubikey-phishing-webusb/) ).

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

~~~
dfox
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.

------
0b0001
Now we have APIs for 2FA tokens in place.

When will we get an API for password managers? That'd enable effective domain
name checks and such.

------
matheusmoreira
These hardware tokens usually support PGP as well! It's possible to generate a
full set of keys on the device. Combining this with an offline primary key
makes for a very secure system that's also relatively easy to use.

~~~
tialaramex
Most FIDO devices don't do anything else. Yubico sells a lot of products that
do, but Yubico's cheapest line of FIDO compliant USB keys, and most
competitors cheaper products do not do anything except FIDO.

~~~
dickeytk
Yeah and you really want FIDO. It's such a better experience.

------
arshbot
There is a depressing lack of open standards with these off-the-shelf physical
tokens. It's unfortunate that a company's security can rely on the APIs of
another company which could go bankrupt and disappear at any time.

~~~
couchand
This comment held water about five years ago, but times have changed.

------
burner589432
Unpopular opinion: These keys are about selling the idea that physical-based
security is somehow magically better.

If you have good password hygene (read: a decent password manager) then I'll
need to breach your host to obtain it - if you use a security key, I'll have
to breach your host and hijack your session which is slightly more convenient
but chances are you're royally screwed once you're breached anyway.

Sure there's some edge cases where this _might_ work (one-way keyloggers, etc)
but these aren't realistic threats for a large majority of people.

Somehow a sales team have taken a bullet hole, and attempted to use a square
peg to band-aid it.

Stop buying stupid products and just use a damn password manager.

~~~
bodhi
How about phishing?

~~~
datguacdoh
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.

~~~
kadoban
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 keys though, I think they're very important)

~~~
burner589432
> 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 enable it.

~~~
tialaramex
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.

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

~~~
tialaramex
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.

