Two-factor apps

jimmyweg

Can I use Duo as the 2FA app on my Android phone? I now use it with other tools and would like to add 1P. Thanks.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

ag_ana

Hi @jimmyweg! :)

If your team uses Duo, you can protect your 1Password account through Duo.

On the other hand, if you meant if you can use Duo as your authenticator app to protect other websites other than your 1Password account, I believe you will have to switch to another app because Duo does not support TOTP. So you will have to use something like Authy or Microsoft Authenticator, for example.

XIII

Duo does not support TOTP.

While they don't mention the term, they do: https://guide.duo.com/third-party-accounts

Please take note of this:

because we use the most secure storage methods on your device, if you wipe data from your device, or upgrade your device, you will need to recover your third-party accounts from a previous backup with Duo Restore, or reprovision your accounts. It is not possible to export third-party accounts from Duo Mobile.

jimmyweg

Thanks! I use Duo only as a 2FA app with separate, specific applications, and I believe it supports TOTP. Does 1P allow for push notifications of the passcode?

XIII

Does 1P allow for push notifications of the passcode?

Unfortunately only in 1Password for Teams: https://support.1password.com/duo/

(I wish I could use it with Families too, without additional costs...)

AGAlumB

Thanks! I use Duo only as a 2FA app with separate, specific applications, and I believe it supports TOTP. Does 1P allow for push notifications of the passcode?

@jimmyweg: It does not with our built-in two factor authentication, as that's using the TOTP standard.

Also, to clarify,

Duo does not support TOTP.

While they don't mention the term, they do: https://guide.duo.com/third-party-accounts

The Duo service uses push authentication, but the Duo app can also generate one-time passwords for other services which use the TOTP standard.

AGAlumB

Does 1P allow for push notifications of the passcode?

Unfortunately only in 1Password for Teams: https://support.1password.com/duo/
(I wish I could use it with Families too, without additional costs...)

@XIII: The Duo service itself is not free. So we include that in the cost of 1Password Business memberships (along with a lot of other expanded functionality). It's not feasible to do that with 1Password Families, because we'd either be taking a loss, or we'd have to raise the price substantially for something most people won't use. That's why we added our own built-in two factor authentication, based on the open TOTP standard, which is available in all 1Password memberships at no additional cost.

jimmyweg

Thanks, Brenty! In sum, is there an advantage in using Authy or MS over Duo? It's not a big deal to switch to one of those, it's just that I have Duo set am ready to go.

AGAlumB

@jimmyweg: I'm really not sure I can give you a good answer to that question, as I use Google Authenticator or 1Password for all my TOTP stuff. :lol: I think part of it just comes down to personal preference, though I think some people use Authy for it's backup/recovery features. I don't use Authy because, as far as I can tell, they don't offer an export option or another easy way to get information out of it. What you could do is install all of them, copy the TOTP secret to each, and they can all generate your authentication code while you decide which one(s) you like. :)

jimmyweg

If I set up 2FA, does 1P provide one-time backup codes that can be used if 2FA is not available? Thanks.

I'll add another question if I may. I see that, in my profile, I can elect to "require 2FA on Next Sign-In." If I want 2FA on every sign-in, to I de-authorize the device, or is doing so not possible? Thanks again.

jpgoldberg

@jimmyweg asks

is there an advantage in using Authy or MS over Duo?

Sort answer: Go with what you have.

If you are using Duo's push system (available with our business plans as mentioned above), then you get the advantage of being notified immediately at authentication requests. Duo is "pushy" (in a good way).

But if you are using TOTP, then any TOTP authenticator app will do. There are differences among them, most having to do with how strictly the long term secret is tied to the particular device. For example, with Google Authenticator it is deliberately hard to your TOTP long term secret moved to another device (and so Google Authenticator is emphasizing your device as a factor). With Authy, these are more portable (and so down-playing the second factorness, while preserving other security properties of TOTP). I don't know what MS Authenticator does in this respect.

It's not a big deal to switch to one of those, it's just that I have Duo set am ready to go.

Go with what you have.

Aside: Other differences in TOTP Authenticator apps

There are huge differences (that make no difference) in TOTP Authenticator apps. For example whether the alg parameter is respected instead of just using SHA1 no matter what the serve sets. There are also differences in how the base32 encoding of the long term secret from the server is handled if it isn't fully valid. And lots of other things like that. Our MFA settings are designed to work with any TOTP authenticator app (meaning we can't actually set features we otherwise would), but this also means that you don't need to worry about which you use.

So whether these huge differences that make no difference are really differences is a matter of differing opinions. I will be blathering on about this at PasswordsCon in November (assuming I'm cleared for traveling).

jimmyweg

Thanks, JP. I installed Authy, and it seems a little handier in one respect: when I tap the app, it opens to the code. In Duo, I had to tap the app and also tap a dropdown arrow. So authy saves a tap ;)

I'd still like to learn whether 1P can provide a backup code that I can use if I can't use the standard 2FA. In Dashlane, I received a list of ten, one-time passwords that I could use instead of the totp. One always could get another list, though I used a password only once. (1P is an improvement over Dashlane in terms of enabling a better site logon experience.) Also, I still haven't figured out how to require 2FA on every login on every device. I haven't tried deactivating the device for bear of "breaking" something, and I don't know whether "Require 2FA on Next Sign-in" is persistent or applies only to the next sign-in. It seems to me that requiring 2FA on every sign-in is the best security.

Ben

@jimmyweg

We don't offer such backup codes at this point, and I'm not aware of plans to do so, but I can certainly pass the suggestion along to the team. As for requiring 2FA on every sign-in... That isn't something that is likely to be possible. I've written about why here:

https://discussions.agilebits.com/discussion/comment/524218/#Comment_524218

Ben

jimmyweg

Thanks, Ben. I looked over that thread, and please forgive me, but I'm not sure that I understand how the explanation applies to a single-user environment. I look at 2FA simply as a security enhancement in cases of a lost or otherwise accessed device. I appreciate that perhaps the design of 1P precludes every-time 2FA, but I'm curious about whether you feel that's a compromise with regard to efficiency vs security. I'm sure the reasons are valid, but I just need a little education.

AGAlumB

@jimmyweg: I'm not sure what your question is at this point, and I think we need to avoid conflating different issues.

• "Backup codes": These are static and could be stolen and used at any time in the future. Our two-factor authentication uses one-time passwords which are each valid only for about a minute and completely worthless after that. A better -- and more secure -- "backup" solution is to setup multiple trusted devices to generate the authentication code.
• "Every-time 2FA": 1Password's security is based first and foremost on encryption. Authentication is nothing to protect you if someone steals your device: the encrypted data is already there and can be attacked offline. Given that, requesting "two-factor authentication" when there is no authentication happening is security theater and not something that provides any actual security benefit to users, since 1Password's UI is not even a factor for an attacker.

I think that may help clarify, but if you have a question please let me know. :)

jimmyweg

Perfect! Thanks, Brenty.

AGAlumB

You're very welcome! Glad to help. :chuffed:

jpgoldberg

In case anyone is interested, there're a couple of reasons (combined) that we don't offer TOTP backup codes.

1. The single biggest reason is that we are desperately trying to get people to make backups of their Secret Keys. We don't want to dilute that message in any way whatsoever, and giving people something else they should save would be diluting it.

2. The Secret Key is confusing enough on its own, and we don't want to make it easier for people to think that they have it backed up when all they really have are TOTP backup codes.

3. TOTP back up codes don't really add a lot of value. So we aren't really losing much by not offering them. Sure, it isn't a lot of fun when people write in to tell us that they've lost their TOTP secret, but we can get those sorted out. (And as unfun as that process is, it is a picnic compared to when people write in saying they have lost their Secret Keys.)

4. There are (easy?) alternatives to TOTP backup codes. If you want a back up mechanism for TOTP just save the TOTP long term secret or QR code some place. You have ways other than backup codes to back up your TOTP access (which is the one thing we can reset anyway. (Some apps make it hard to do this; others make it easy.)

Anyway, so when you put all of that together, we don't do the whole TOTP backup code routine. At the deepest level its because 2FA for signing into 1Password adds different sorts of security properties than 2FA does for other services. So while TOTP is nicely familiar to most people, it plays a different role in 1Password security than in just about every other place you've used it.

jimmyweg

Thanks, JP, for the added clarification. I hope that when I used the term "backup codes," which was the term used by my former password manager (Dashlane), I might have misstated what I meant. I used Duo with the password manager and entered the six-digit code in conjunction with the Dashlane's login interface every time I logged in (locally or online). As there's a risk of losing your phone, Dashlane provides a list of ten, one-time use, alpha-numeric codes, e.g., YUMVMPM33F5TAWXT, which I could enter in lieu of the six digits. Thereafter, I could disable 2FA while I looked for my phone ;) As for me, I kept the file in an encrypted RAR. I simply looked at this 2FA system as a security enhancement, but perhaps its value is exaggerated.

jpgoldberg

Thanks, @jimmyweg, that is what I thought you meant by backup codes. We have made different choices about how and where we deploy 2FA than some other password managers have. This is because 2FA has different security properties for a password manager than it does for other services.

For the overwhelming portion of services for which 2FA is available, using 2FA lets you get away with a weaker or reused password (first factor) for the service. For a password manager that can store data locally, that is not true. 2FA offers no protection for you if someone gets your encrypted password manager data from your machine or device. The strength of your Master Password is what determines whether and how long it will take an attacker to decrypt your data if they steal it from your machine.

So 2FA for most services lets people get by with weaker passwords, but if you follow the same practice with a password manager you are substantially weakening your security. So we don't want people to weaken their most important line of defense by treating our 2FA they way that they've learned to treat other 2FA.

Why doesn't 2FA let you get by with a weaker Master Password?

Consider an attacker, Albert, who gets hold of your encrypted password manager data from your own machine. Albert does not need to authenticate to anything in order to try to decrypt the copy of the data that they've captured from your machine. It wouldn't matter if you had 1 factor, 2 factor or 25 factor authentication. The attacker doesn't need to authenticate. (Note that in the case of 1Password it is only true of data that the attacker gets from your machine. An attacker getting data from our servers would not be in a position to launch a Master Password cracking attempt. The strength of your Master Password is your defense in the face of what we expect is the most common serious attack scenario.

But not if stolen from us

The threat above only applies to data stolen from your machine. But your data is safe if it is stolen from our servers. That is because your Secret Key (which is unguessable) lives only on your machines. Your Secret Key and Master Password are combined when you unlock 1Password to derive the keys that are needed to decrypt your data. An attacker who gets data from our servers wouldn't have your Secret Key and so wouldn't be able to launch a master password guessing attack on such data.

Note that 2FA doesn't protect you if our servers are breached. It is your Secret Key that provides the big defense for you in such event. It is your Master Password that protects you if your data is stolen from your machine. 2FA protects you if someone somehow has your Master Password and Secret Key but doesn't have your encrypted data.

So this is why we limit our 2FA for when you first enroll a new device. That device won't have your encrypted 1Password data, and so 2FA does some good there. But it does not in any way reduce the need for a good master password.

jimmyweg

Thanks again, JP. I agree with your logic, and I don't want to belabor this point further, as you guys have provided an abundance of insight. Overall, any master (critical) password should be very robust. One thing I just noticed is that, if I'm correct, 2FA is required on every attempt to log in to my account after I sign out from 1P. Otherwise, an attacker needs my master password to steal stuff from my offline vault. Thereafter, it really wouldn't matter if 2FA were required, as my stuff could be used on any system. To go online to my accounts, the thief needs my master password and a trusted device. I'll worry more when quantum computing advances a bit further :) In the meantime, having used and tested quite a few apps, 1P seems like a clear choice...particularly in terms of support!

jpgoldberg

If I'm correct, 2FA is required on every attempt to log in to my account after I sign out from 1P

You are not correct about that. Your second factor is only required when you set up a new 1Password client.

an attacker needs my master password to steal stuff from my offline vault. Thereafter, it really wouldn't matter if 2FA were required, as my stuff could be used on any system.

That is correct. And that is why we don't (pretend to) require 2FA when unlocking your data locally. We don't want to create the illusion that it protects you from someone who gets your local data.

I'll worry more when quantum computing advances a bit further :)

Yep. We are not facing the Cryptopacalypse, despite what some hand wringing headlines might suggest.

In the meantime, having used and tested quite a few apps, 1P seems like a clear choice...particularly in terms of support!

Thank you very much much for saying so, @jimmyweg!

jimmyweg

Thanks again!

If I'm correct, 2FA is required on every attempt to log in to my account after I sign out from 1P

Okay, but maybe I misunderstood.

You are not correct about that. Your second factor is only required when you set up a new 1Password client.

I had logged on to my 1P account and 2FA was required at the time on the trusted device. (The Windows app remained closed throughout this test.). I opened Chrome and logged in through the 1PX extension. I then accessed my account through 1PX, and was taken to the Sign in to your 1Password account page, where 1P had filled in my email, secret key, and MP. I clicked the Sign In button, and 2FA was required. I signed out and exited the 1P domain. I returned to the account at https://my.1password.com/signin. I accessed my account with the MP, which 1PX had entered, and 2FA was not required. I signed out of my account, and closed Chrome. I re-opened Chrome and logged in to 1P through the 1PX extension. When I returned to my account, the above three boxes had been filled in by 1PX, and when I clicked Sign In, 2FA was required again. Anyway, this is why I made the quoted comment.

gordcook

@jimmyweg it sounds to me like you have Chrome configured to remove cookies when you close it (or maybe you’re using Chrome in incognito mode). If you delete the cookie, then the browser would be a new client to the 1Password site the next time you visit it. The site would have no way to remember the browser from your previous visits because that’s what cookies are for. In this case, you would want to be prompted for the 2nd factor to ensure that it’s really you.

If I’m mistaken, forgive me for intruding.

jimmyweg

Thanks, Gord. That must be it, as I delete Chrome artifacts on exit. I could add an exception for 1P cookies, though I don't mind using 2FA on my systems for each login to my 1P account. I just wanted to see what led to my comment about this to JP. Please "intrude" any time!

jpgoldberg

Yep. Thank you @gordcook for pointing out that it your browser removes certain parts of local storage, it will not be able to prove to our server that it's already done the 2FA dance, and so it will have to do it again. And so this is very likely to be why @jimmyweg was finding that 1Password.com was putting him through the 2FA requirement each time.

On cookie killing

It's absolutely fine to keep things set up this way. Having to go through our 2FA each time may be a price you are willing to pay for the general benefits of removing cookies. Whether or not systematically removing cookies is the right way to achieve your privacy and security goals is a whole other question. There certainly was a time when that was pretty much all a user could do to reduce tracking.

The difficulty is that tracking mechanisms have long since developed non-cookie-based tracking mechanisms. The good news is that browsers are getting better developing counter-measures. You might be interested in the Brave browser, which is Chromium-based and is privacy focused. If you are on Mac, also consider Safari, which has been quietly deploying some very clever anti-tracking technologies. So there may be technologies available to you that help you achieve your privacy goals without interfering with cookies where you do want them.

Sadly, this is probably a battle we can never win. We are at the stage of counter measures to counter measures to counter measures. But the sorts of things that some browser developers are putting into their browsers mean that we, as end users, don't have to be so directly working to keep up.