The problem with 1Password 2FA is, I believe, that the 2FA itself is still gated behind your master password, in that if that gets compromised so does your supposed 2FA.
The central idea of 2FA is it's something you know and something you have. If that 1Password master password is the only thing needed to gain access then you don't really have 2FA.
Again, I don't use this feature of 1Paswword so this might not be exactly how it works.
But if so, I'm sympathetic to Google not treating it as 2FA because, well, it isn't.
As for "If that 1Password master password is the only thing needed to gain access then you don't really have 2FA." it's not, unless they get access to a device you have logged into 1Password on in the past (and thus entered your secret key [0]). For me this stays true enough to "something I have". If someone has my phone/computer AND can guess my 1Password master password then things are already pretty bleak and they already have access to whatever other 2FA app I was using (Authy/GA).
Lastly 2FA falls apart if you share an account with a significant other (or a team). In 1Password I can just move that login to a shared vault or share that login individually and everyone can log in and use 2FA. I'm not sure what the alternative would be. Sure, if a product supports multiple accounts or even multiple 2FA's (I don't think I've ever seen the latter, at least in non-enterprise settings) there is a way to do this but most apps/SaaS/etc there isn't an alternative (other than disabling 2FA).
On a flash drive/SD card, or even printed out, and then stashed somewhere safe/secure (i.e. not in an unlocked drawer next to your desk)
My threat model does not include "Nation state adversary breaks into my home and... reads the contents of the book". If I annoy the Russians enough, presumably they would just try to outright murder me.
In contrast, "Person I annoyed online plans elaborate Internet revenge" is definitely a potential threat I want to cope with, as are "Scam email claiming to be from company I have account with", "Facebook lose everybody's passwords", and so on.
If you meant somehow the building burns down and destroys all my possessions but leaves me miraculously alive, I lose access to a bunch of stuff. Nothing to be done about it.
But one of the Security Keys lives in my jeans pocket, so if I survive the fire in the regular way, by fleeing a burning building, I still have that Security Key. If I am wearing trousers. Not so many people actually flee naked, if the fire is going to kill you in the time it takes to pull jeans on you're probably just not making it out at all.
If you care about this, consider security through compartmentalization provided by Qubes OS. I store my passwords in plain text in an offline VM (with hardware virtualization).
For example: if you have an application protected by password+yubikey with "remember device" enabled, after prompting for your password it may decide not to also prompt you for the yubikey, and that can be because a cookie (perhaps ANDed with some other heuristics) is taking its place. A cookie which can be trivially copied to another device, but can't be trivially memorized nor guessed, and is for that reason not a "knowable" thing. If it was considered a "know" factor, then the "remember device" feature would effectively be a "conditionally disable 2FA" feature (two "knows" are 1FA), but it's really not that, outside of describing the interim UX.
It's true, of course, that once you have created an authenticated session on a device, anyone who has compromised that device (with physical access or a software hack) can likely gain access to that session. But the authentication method still prevents unwanted initiation of sessions, which is the whole point.
Any service provider obviously needs to choose their session policies to match the sensitivity of their service, their own threat models, and the threat models of their clients. So e.g. an online bank probably shouldn't issue cookies that last for a year and are portable across IP addresses. For some services, it could be a good idea for the session to only grant less sensitive access (e.g. only read access), and still require fresh authentication for sensitive actions (e.g. transferring money).
Our choice is either:
* No 2FA
* Virtual, 1Password 2FA
It's better. But it's not great.
Granted that if you put your TOTP seed somewhere else outside the password manager, you technically achieved "3FA"(1Password master password + 1Password private key + TOTP token) and it is more secure. But I don't think putting TOTP seed and password together in the same password manager weakens 2FA?
To login to a website:
- Without a password manager, your 2 factors are account password + account TOTP.
- With 1Password, your 2 factors are 1Password master password + 1Password private key.
But when I realised the 'something you have' is the password manager (actually, the data store) itself, and the 'thing I know' is my master password (and not the individual site's password) I've started using it for 2fa. I can still see how the subscription version of 1password stretches that definition though (because you don't actively have unique ownership of the data itself), which is why I use keepass now.
Just like a dongle, your pc is not immune to evil maid if left unattended. My threat model isn't inclusive of that (my threats come from the internet - I live rurally).
Requiring your phone for 2fa (google auth or sms 2fa or other) isn't a panacea either, especially if that's the device you're logging in with.
I wish Google would allow setting 2fa without a phone number...
The problem is, assuming your master password is unique (I hope so!), all of the likely vectors for exposing it also expose the database, even if it's only kept locally. Having the database only stored in one place is also quite inconvenient, of course, and any sync mechanism adds even more opportunities for it to be exposed.
My computer could very easily have a zero-day vulnerability get exploited. So could my phone. Either one would expose anything I do on it (for example: access my password database using my master password).
(My solution to this is to use a security key for as much as I can. If you're not concerned about this risk, great, but it definitely is a threat.)
I personally have all my MFA codes in 1Password, but 1Password is protected with my Yubikey. In the unlikely event that a bad actor did acquire my master password, they wouldn't get far unless they also physically had my hardware security key.
2. You can add 2FA (well, technically 3FA if you need the secret key, master password, AND a rotating token) to your 1Password signin as well (I auth Authy for that purpose)
1Password also seems able to bypass the secret key ("If you still can’t find your Secret Key, contact 1Password Support.") which means social engineering, phishing, and/or credential stuffing attacks are viable.
Well, this is not exactly true. You need to know the master password, and you need to have the device that has the 1Password database on it. Even with the knowledge of the master password, you can't login into your $random_website account from my laptop. So even without the additional one-time 2FA codes, using a password manager that has a master password and doesn't synchronize its database, de-facto, _is_ a form of 2FA. Yes I understand that this view is controversial and that auditors will disagree.
Another benefit is that I'm much less likely to lose my U2F dongle as it's on my physical keychain (and has been, for years, without damage) than I am to need to replace or wipe my phone (although a password manager with 2FA codes in it also avoids this).
A FIDO authenticator is actually a USB HID class device, like a keyboard‡. So, if your $WORKPLACE doesn't allow you to plug in keyboards then, OK, I guess maybe a FIDO dongle isn't worth trying, but few people are in that situation.
If your employer has a policy of specifically issuing and authorising only particular devices (e.g. you can pick from a list of 3 Dell branded keyboards and 2 Logitech keyboards and anything else needs HR director override) then seems like it's time for them to authorise and issue a nice high quality FIDO authenticator. Yubico make some eye-wateringly expensive models, maybe they should pick those.
‡ "Like" a keyboard but it isn't a keyboard. The FIDO protocols don't involve keypresses, the device is just HID class because well, it's a Human Interface Device, seems legit. It sets protocol to 0xFF custom, and needs dedicated software to use that, which is fine.
I have not, and it's frustrating that Google offers no support beyond their help pages for their own branded hardware.
For our iPhones, the NFC has worked fine even without the Smart Lock app. I believe Google phased Smart Lock out some time ago but I've not tried using it in a while, I don't use an iPad very often.
At least one of each of our devices is always stored at home in a safe place, where we store other valuable documents. If either of us lose one device, we will buy a new U2F dongle, enroll the new dongle, and unenroll the old lost/missing/stolen dongle from each of the services we use.
You can't backup a U2F dongle but so far everywhere I've enrolled to use one it always recommends you enroll at least 2 and keep one in a safe place.
I haven't been able to get any Google Titan Key to work with any Apple device via NFC.
I use an iPhone 8.
The whole point of 2FA is to have "2" independent pieces of data to verify logins. Gating 2FA behind a single password defeats the point.
Indeed.
It's also why I think U2F should be mandatory in way more places/sites/companies (it is in some, thankfully): you then need to physically have a Yubikey or similar and it's not possible anymore to trade security for convenience. It doesn't solve all security issues, but it's already a great step forward.
When you let people the choice, they'll pick the lazy, insecure, way.
Chaining just increases vulnerability.
If you would like your parents to have better security for these accounts, I commend Security Keys. Unless your parents aren't together any more, or are just really fervently independent, it's probably fine to buy them one each, but with the suggestion that they both enroll both keys. This way when Parent #1 loses the Yubikey you bought them, Parent #2 can use their Yubikey to save the day until a new one is purchased.
Yubico's USB A format factor "Security Key 2" is robust, but relatively expensive for what you need.
Searches for "Security Key" on Amazon or your preferred site will give you a pile of products and review feedback across price brackets, the only thing your parents are likely to care about are the connector (USB A is no use for a USB C MacBook for example) and maybe other form factor concerns like can it hang from a keychain, or would it fit in a wallet? For their purpose these things don't fill up, and shouldn't (modulo physically smashing it) wear out.
You can always buy a USB-A-to-USB-C adapter/converter. They are available everywhere, inexpensive, and if you're afraid it will be misplaced, there's always the option to glue the USB A key to the adapter...
You can fill forms and feedback but I have never heard of free users ever getting as much as a reply back.
Google doing it properly should not upset you this much.
"Your Fi number is tied to your Google Account." -- I'm sure you've seen cases of people's google accounts being randomly locked for no reason. Now you lose access to make a call too!
The last thing I'd ever trust security to is SMS. Lots of good technical details here:
https://lucky225.medium.com/its-time-to-stop-using-sms-for-a...
If a SIM swap scam is happening and your account is locked, it is incredibly unlikely they'll be able to swap it out.
[1] https://www.zdnet.com/article/nist-blog-clarifies-sms-deprec...