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.
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.
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.
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.
>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/ ).
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.
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.
On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard.
I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.
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.
(Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device).
Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP
Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin.
> I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious).
I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...).
And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.
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)
Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.
