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).
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.
> 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...
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!
I don't think there's any way around having a safe physical location to store backup codes / secrets on paper.
See https://sovrin.org/wp-content/uploads/2019/03/What-if-someon...
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.
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).
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.
Now no one can socially engineer access to your account -- including you yourself, in case you're locked out :-)
- 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.
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.
> 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.
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.
>but you don't really want to have your password manager also store OTPs
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.
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.
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.
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/
Is it just me, or does a hosted password manager smell like an absolutely terrible idea to anyone else?
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).
>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.
> 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?
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/ ).
When will we get an API for password managers? That'd enable effective domain name checks and such.
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.
Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.
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 have rock solid audit trails that will stand up in court: This, or 2FA won't have a huge functional difference, but chances are unless you have NSA/Google tier security, your money would be better spent hardening infrastructure - your logs won't be worth jack if a pentest rips your network apart in two hours. I regularly see $1m+ SEIM deployments on MS17-010 vulnerable networks, I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
