How to prevent "weak" assessment for 2FA recovery codes?
For accounts that support 2FA I also store the backup codes in 1Password; in custom fields that I mark as password.
Unfortunately these are now classified as weak passwords (by Watchtower?).
How can I prevent that "weak" assessment, but retain the password category properties? (hidden, readable font)
Comments
-
Hi @XIII
How can I prevent that "weak" assessment, but retain the password category properties? (hidden, readable font)
There isn't a way to do that at present. This is a consequence of using a feature to do something it wasn't designed to do -- marking backup codes (which aren't passwords) as passwords. We may be able to find a way to better handle this use case in the future, but I can't make any promises at this point.
Thanks for letting us know this is something you'd like to be able to do.
Ben
0 -
Add my +1 vote for a more native way to store account recovery/backup codes in 1Password.
0 -
Thanks @AppleGeek. :)
Ben
0 -
@XIII my solution is to store them in the comments section, because frequently I have ten of them.
Another option is to use one Secure Note for all of your recovery codes.
It doesn't "retain the password category properties" but if you're worried about confidentiality then _that_secure note would only be accessed by you in the event you need one of your recovery codes.
0 -
@gazu Thank you for the suggestions! Using separate Secure Notes might work (maybe even linking them to their Login entry)
Would be quite some effort to migrate though...
(I have so many 2FA-enabled accounts that I even created Keyboard Maestro entries to generate a template and to fill in the 10 recovery codes as fields in a Login entry)
0 -
That's interesting too. All of my "backup codes" are pretty long and unique, so they don't show up in Watchtower. So it's something I wouldn't have thought of. Thanks for bringing it up! :)
0 -
@XIII, I would like to take it a step further back and beg the question: why are we storing backup codes? To answer my own question, this is for when you no longer have access to the 2FA key. I see 3 reasonable circumstances that could create this situation:
1. You have lost all access to your primary vault.
2. The login record has been removed (and the trash has subsequently been emptied).
3. The 2FA key has been removed (or corrupted) from the login record (but your password and backup codes somehow escaped this targeted damage)Under condition 1, you would still need the backup codes unless you keep a copy of your 2FA secrets in a separate system (e.g. Authy).
Under conditions 2 and 3, storing the backup codes in the same login record as the rest of the authentication data is not giving any protection whatsoever. You might just as well have clicked "NEXT" and not saved them in the first place because you won't have them now. If you feel the need to protect against these scenarios, I would suggest keeping the backup codes in a separate record in a standalone vault. As a side-effect, they won't show up as "weak" in your primary vault.
Going back to my original rhetorical question, I would argue against generating (if possible) or storing backup codes at all. If the system that I am logging into will allow a static password in lieu of a one-time password, then it allows someone to bypass 2FA and login to my account with the ID and two static passwords. In effect, they have reduced the authentication to "something I know" and "something I know", which in my opinion is only 1FA.
In summary, I would recommend keeping your 2FA secrets in 2 different OTP generators and not recording your backup codes at all.
P.S. I came across a system that would allow users to authorize more than one OTP authenticator. It might have been Mailchimp. I wish more sites did the same. People might not feel the need for backup codes if they had a backup OTP generator.
0 -
You raise a very good point, @gordcook. I agree, unless someone can outline a scenario beyond what you've already mentioned, it seems superfluous to store these codes. I personally do not generate them if given the option, and if they are generated automatically I generally do not store them. I utilize 1Password as my primary TOTP generator and a Yubikey with the Yubico Authenticator app as a backup. I think if one feels they are important it would be worth considering if storing them next to the TOTP secret and account password is the most prudent course of action. As gordcook points out, in any sort of scenario where you might need one of these, it is likely they'd be affected by whatever it was that caused you to need them.
I came across a system that would allow users to authorize more than one OTP authenticator. It might have been Mailchimp. I wish more sites did the same. People might not feel the need for backup codes if they had a backup OTP generator.
Sites / services don't have to "allow" it. Just use the same secret / scan the same QR code with both. :)
Ben
0 -
Of course, @Ben. I totally agree. This is what I meant by:
unless you keep a copy of your 2FA secrets in a separate system (e.g. Authy).
It works quite well for me. Unfortunately, this solution requires the user to customize the workflow on something that is already quite intimidating to the average user. In this case, they need to scan twice but only verify from one of the two products. The typical 2FA wizard will not guide the user through this atypical workflow. Allowing multiple authenticators simplifies the workflow for the end user and has the added advantage of being able to de-authorize one of my authenticators, should I lose control of it. If we want to encourage more people to adopt 2FA, simpler is better.
That said, double-storing will work with any site that supports TOTP and is a much better solution than backup codes, IMHO.
I personally do not generate them if given the option
I also wish that more sites made generating backup codes optional. Once they have been generated on their system, they will still work whether I store them or not. And as @XIII mentioned, sometimes the codes they generate are not very strong at all.
Errata:
In retrospect, I see that I botched up my comment. I changed the order of the bullets but neglected to update the paragraphs before I posted it. The first paragraph concerns bullet #3 (not #1), and the second paragraph covers bullets #1 and #2. Sadly, it's too late for me to go back and edit it now. :( Sigh.
0 -
unless someone can outline a scenario beyond what you've already mentioned
Can I try?
TOTP depends on the server and generator being in sync about what's the current time. I have experienced issues with that, resulting in generated codes not being accepted. In such a case a backup/recovery code can still get you in.
0 -
Can I try?
Of course! :)
TOTP depends on the server and generator being in sync about what's the current time. I have experienced issues with that, resulting in generated codes not being accepted. In such a case a backup/recovery code can still get you in.
It seems the better solution there would be to make sure your devices are in sync with an appropriate time server? All of the operating systems we support in 1Password have the ability to sync with a time server (NTP) out of the box, which makes for very accurate time keeping.
Ben
0 -
It seems the better solution there would be to make sure your devices are in sync with an appropriate time server?
Agreed!
However, all my systems already sync with a time server and still I have had such an issue on my PC...
0 -
However, all my systems already sync with a time server and still I have had such an issue on my PC...
What ended up being the resolution? Surely backups codes would only help temporarily?
Ben
0 -
@XIII: I've found (and so have others) that some Wi-Fi-only devices are just terrible at this, so periodically setting the date/time/zone manually can be more reliable. I'm not sure why that is, but it's come up often enough that it's the first thing I try. Hearkens back to the days where I was literally cracking open my desktop to physically replace the CMOS battery. A lot of stuff can break if the time "drifts" enough, like TLS; so for me a TOTP issue serves as an "early warning" canary that 1) other stuff breaking may be imminent and 2) I may have a deeper issue that needs to be addressed on the device. The end game can be data loss, if devices disagree on time and then synchronize data between them, with something older overwriting newer stuff. :sweat:
0 -
My personal habits are along the lines of what @gordcook implies. As I store the long term secret in 1Password, I usually don't bother storing the backup codes at all. When I do, it is as a note.
As people have pointed out, there are scenarios in which it might be useful to have the back up codes in the place that the long term secret it held, but I personally consider those to not worth the trouble.
But my habits may be unusual: If I have a strong, unique password for some site or service, I don't set up 2FA for it unless I am compelled to. Remember that the primary reason that services push for you using 2FA is because they know that most people have weak or reused passwords. So they like how TOTP works in which the user is given a strong, unique long term secret that is never transmitted. But I already have a strong and unique long term secret, and by using 1Password to fill into web pages, I dramatically reduce the threat of getting phished.
I'm not saying that 2FA adds nothing in those circumstances, but I personally find that it adds too little additional security to be worth the hassle for me. But of course for people who are reusing passwords, TOTP does a lot of good.
0 -
What ended up being the resolution?
Mannually correcting the time.
It seems Windows is not very good at using ntp servers or DST calculations. For example: whenever I boot Windows after having used Ubuntu the clock of my PC is off by (exactly) 1 or 2 hours (depending on whether DST is active).
0 -
@XIII: Ah gotcha. Yeah unfortunately it's not limited to Windows. I've seen similar issues across all platforms. Network can come into play too. It's complicated, and since it's difficult (if not impossible) to really pin down the cause in any given case, I find it's easier to just set it manually like you did. Get's the job done, I think so. :)
I will say that there can be big differences with how time is handled between OSes, so dual booting could definitely confusing things. Not something I'd have thought of!
0 -
@XIII ,
If you want to store your recovery codes in a custom hidden password field, join them together using a unique separator. 1Password will let you copy multi-line codes into the field, where you can just replace any newlines or the resulting whitespace with your separator. This will provide you a very long, complex "password" which will thwart Watchtower.
0 -
That's an interesting thought. :)
Ben
0 -
That’s a nice workaround!
0 -
OK. I don't use 2FA with 1Password, but do elsewhere.
I store backup codes as notes usually and link them to the login record in question
I store these code for those systems where the long term secret doesn't nec apply and are usually related to work 2FA. They want work stuff in their password manager of choice, which also has 2FA. (I remember storing the recovery codes for that password manager in 1Password when one of the infosec guys came by and he was like, I'd rather you didn't put those in another password manager, and I asked him if he preferred post it notes. He said, "got me" and walked away....0 -
Nice. :lol: :+1:
0
