Hacker News Reader

Comment by skybrian | Hacker News Reader

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.

View on HN

This. This is why I am happy to use security keys at work (if I lose all of them, there is a way to be issued new ones using a manual identity verification method plus another person's security keys ) but I've been too nervous to put them on my own account.

Also, if you are adding support for security keys in your app, please make sure there are ways to add and remove multiple keys (so I can have backups, and per-device keys).

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?

Terminology clarification: The seed driving TOTP is a shared secret but NOT a symmetric 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.

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.

You could use Yubikey with Yubico Authenticator - the secret key is stored in the Yubikey. I did this because phone upgrades were a PITA, as you alluded. If you wanted you could have two Yubikeys (I have my second one in a safe deposit box).

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.

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.

This is actually against the WebAuthn spec (https://www.w3.org/TR/webauthn-1/#credential-loss-key-mobili...). Hope they fix it soon.

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

It's bad that many sites require you to set up TOTP (single seed) before they allow you to set up U2F (multiple keys), so you have the problem of having to take care of the TOTP seed anyway even if you have multiple U2F keys. (It's even worse when sites forget the U2F keys when you regenerate the TOTP seed.)

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.

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

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!

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

This is what SSI has done well.

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

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.

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.

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

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.

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.

Doesn't cover the scenario I outlined.

Step 1 then becomes "buy airline ticket to get home so I can get at the safe".

Sure, of course doable, but a million times more cumbersome.

What if passport was also stolen? Maybe in such a time it would be convenient to be able to contact anyone? Even if not to solve the situation but more of a heads-up.

Reply on news.ycombinator.com