Live data from Hacker News

Getting Started with Security Keys

paulstamatiou.com

81–90 of 104 posts

Re: Getting Started with Security Keys

#81
post #79

Earlier quoted context omitted.

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.

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

Re: Getting Started with Security Keys

#82
post #72

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

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

Re: Getting Started with Security Keys

#83

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.

This is what SSI has done well.

See https://sovrin.org/wp-content/uploads/2019/03/What-if-someon...

Re: Getting Started with Security Keys

#84
post #67
post #49

Earlier quoted context omitted.

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

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.

Re: Getting Started with Security Keys

#85

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.

Yes, an interesting exercise I did once was to actually draw the dependency graph of auth material (both passwords and 2FA tokens/devices) and accounts, with edges where one thing can bootstrap another. E.g., with my password database and master passphrase, I have a password; with that and my OTP backup, I can recover my email account; with that, I can reset other account X; etc.

I now make sure I have sufficient backups of the roots in that graph so that losing hardware doesn't lock me out. It's easy to lose track of!

Re: Getting Started with Security Keys

#87
post #50

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.

My guess is that their thinking is that you should use your root account to make an admin user via IAM, and the admin user should use IAM to make users for your people who will actually manage your services. Their advice [0]:

> We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.

Here are those things that you need to use root for [1].

If you use U2F on your regular users and someone loses their key, they can ask the admin to temporarily disable 2FA on their user account, or switch them to TOTP, until they can get a new U2F key set up.

If you use U2F on your admin user and lose the key and there is only one admin account, I would guess that it is similar to the user account case, except you need to have the root account deal with it.

That only leaves the question of how to deal with the root account. If you enabled U2F and lose your key, Amazon provides a way in using email or phone instead [2].

[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-use...

[1] https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that...

[2] https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...

Re: Getting Started with Security Keys

#88
post #71

Earlier quoted context omitted.

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…

I think that you are intended to use AWS as described in this comment [1]. Even if you are a one person operation, you can create those separate IAM accounts for admin and normal use. Once you have this hierarchy of accounts in place, it is fairly straightforward to deal with a lost hardware key.

[1] https://news.ycombinator.com/item?id=21411013

Re: Getting Started with Security Keys

#89
post #73
post #64

Earlier quoted context omitted.

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

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.

Re: Getting Started with Security Keys

#90
post #88

Earlier quoted context omitted.

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…

I think that you are intended to use AWS as described in this comment [1]. Even if you are a one person operation, you can create those separate IAM accounts for admin and normal use. Once you have this hierarchy of accounts in place, it is fairly straightforward to deal with a lost hardware key. [1] https://news.ycombinator.com/item?id=21411013

In my organization there are certain operations that we require you to have authenticated with 2fa in order to perform them. For the CLI or terraform this means using something like awsmfa. There's no way of doing that with a FIDO key.

It would be nice to be able to use a FIDO dongle for the web console and TOTP for cli tools but the (bad) AWS restriction forcing you to only use one or the other means I'm stuck on TOTP for everything.

Post reply on HN