I use 1password for TOTP too, and this detaches my device from it. Now if I lose my phone, I just need to be able to access the app on my next phone and I'm all set.

I know that keeping the password and the TOTP at the same place is kinda not great, but I prefer this "risk" to the "hassle" you mentioned.

I'm open to better solutions!

At this point, what is TOTP actually doing for you? If you're using 1Password, it's already generating unguessable passwords for you. Your TOTP codes are literally just an extension of that password.

It mitigates phishing and password reset attacks. It also means you can give access to some account to a friend or family over the phone one time, without giving them permanent access. Also good on non encrypted public wifi or in a company network with a proxy that sees and logs everything.

The real word is very unperfect.

It mitigates the simplest forms of phishing. If someone is running a proxy server[0] and passing everything along to the real website, token (or SMS) based 2fa can't do anything.

[0]https://breakdev.org/evilginx-2-next-generation-of-phishing-...

Hence "mitigates" and not "cancels"

A single use password extension.

The important thing here is that you only enter the secret once. It’s different from a password which is reused by design.

Right, I know that's the obvious response, but what's it really buying you? The rationale I always see is "the server could log the request and my password would wind up in plaintext". But the problem with plaintext password logs is that in a breach, a substantial number of those passwords will be used to credential-stuff other accounts. A breach already requires you to reset all your credentials for that service, and if you're using 1Password, those credentials had no other value anyways.

I feel like I must be missing something here, especially given who I'm replying to, but doesn't it mean that, even if your password is compromised, it can't be used to log into the service which is also protected by TOTP? Regardless of impact on other services if someone reuses their password. So in theory, there's no desperate need for you to reset your password for the service (though of course you should) because it's still protected by your TOTP setup. (Well, unless your current TOTP was leaked and someone reuses your password and current TOTP before it times out, if the service allows that.) Of course, it depends on the nature of the breach. I've assumed the password leak via request logging as you mentioned (and possible leak of single TOTP), but if the seed for the TOTP is also leaked (e.g. DB breach), then naturally you're in trouble!

I'd love a dumbed-down answer to this. Here's where I think 1Password's TOTP is useful:

User creates a strong password in 1Password when signing up for a service. The password is used only for this service. The service stores all usernames and passwords in plaintext. These credentials are compromised without the service knowing. If I'm using 1Password's TOTP then, I think, an attacker is prevented from logging into the service with my credentials. If I'm not using 1Password's TOTP then the attacker can login to the service.

If the service is compromised, you can't trust your TOTP secret (the little binary string from which your TOTP codes are generated) either! The protections TOTP provide in this scenario are all based on magical thinking; that it "feels" secure. But really, with respect to a specific service, if they're compromised, your credentials are worthless and need to be reset wholesale.

It should be noted that the TOTP secret is probably kept in the same database (if not the same table) as the password hashes. I'm surprised we don't see more TOTP secrets in password dumps.

And you reset the password after you find out about the leak- but that may be a long time or even forever after the leak occurs, so with only a password, you more vulnerable.

You know, that’s actually right.

I’m going to reconsider why I’m using 2FA and go all U2F or remove it entirely.

You sound surprised I’m right! :)

2FA is strongly pushed in a lot of places. Creates an impression of importance.

You just saved me a ton of hassle next time I swap phones. Cheers.

Ha, I'd just not thought it through for some reason.

You're assuming that using 1password implies you're not re-using passwords, or using easily guessable ones. Is this assumption safe to make?

Not entirely. But 1Password does clearly flag weak passwords and reused passwords (i.e. used for two or more items in 1Password) with a message that's not dismissible.

In general, no, but for 1Password users sophisticated enough to store TOTP creds in it, I'm guessing: almost always yes.

Similar, when you are using a tool to generate something unique for logon why does it have to be long? 4 characters should be plenty if you do not reuse it.

It mitigates passive attacks: If someone spies me entering the password (by keylogger or in person) they only get my password but cannot login 2 minutes later (TOTP tokens should not be reusable for some time, so even this 1 minute window gets closed).

Plus, some buerocrat can tick the 2FA box.

Right, but you're mitigating an extremely marginal attack (a purely passive interception of a login) and enabling a somewhat more realistic attack, and for what? If you're just doing it to fake out 2FA requirements, sure, do whatever. But otherwise, just use 1Password passwords and skip the TOTP theater.

> Right, but you're mitigating an extremely marginal attack (a purely passive interception of a login) and enabling a somewhat more realistic attack, and for what? If you're just doing it to fake out 2FA requirements, sure, do whatever. But otherwise, just use 1Password passwords and skip the TOTP theater.

Passive interception is not the only possibility. How many password dumps show up each year? Having TOTP enabled, regardless of where it is stored, helps mitigate that threat unless the password that is leaked can also access whatever is storing your TOTP secrets. But if you're using a password manager and reusing passwords, I don't know what to tell you.

Personally I use a TOTP implementation that lets me move the backing store as a file. It's not stored in my password manager, but it's available to me should I need to change phones. That seems like the best of all worlds.

Password leakage is not a marginal problem. I find saved passwords in public browsers all the time. Those with TOTP are much better protected against this as well.

Yeah, but you are not finding 1Password passwords in public browsers, are you?

1Password also has a web UI, so yes it is still very possible to copy a password from 1Password and accidentally save it on a public browser.

Not to mention the simplest: type in password from 1Password on phone on public browser. Accidentally save password.

Sadly, I found ones from colleagues that use 1Password and even to me it happened that I clicked save for password that I didn’t want to save in that environment.

Ho does having TOTP in addition to a password versus just the password enable a more realistic attack?

Agreed that you don't gain anything if you're using 1Password. But users may be required to set up MFA to access something like GitHub organizations, in which case having it available in 1Password is convenient.

It's true, putting the TOTP in a synced app actually removes the "something you have" aspect of the second factor. Now you've created a way to intercept the "something you have" factor without touching either the user or the authenticating service, so it's just an extension to the "something you know".

TOTP implemented with 1Password is not 2FA.

All TOTP devices must store the symmetric key, yes. 1Password goes a step further and provides a UI to allow the user to simply copy the symmetric key out of the login record à la a password.

TOTP clients that make opinionated design decisions prohibiting a user from getting at the symmetric key are correct implementations.

That said, if one wants to mandate 2FA for one’s users, TOTP is not the right choice, given it allows users to do the wrong thing.

Reduction of chance for a successful phishing attack. Is it possible for a hacker to get both the password and the TOTP? Sure, but the timing of that is a 30-second window, in which the hacker needs to be extremely sophisticated in order to successfully compromise your account.

This is not at all true, and we’ve dealt with unsophisticated but successful ATO attacks on TOTP all year. TOTP does not defend ordinary users against phishing.

> TOTP does not defend ordinary users against phishing

I never said it ultimately defends ordinary users, just that it reduces the chances because it requires a more sophisticated attack.

You said attackers need to be "extremely sophisticated" to pull it off, and I've spent a year seeing nitwits – clumsy and trivially detected nitwits – do it without much trouble. You were wrong, and wrong in a way that's important to correct so people know that it's wrong.

And I've seen the opposite, what's your point? How do you qualify "clumsy and trivially detected nitwits"?

PS - Telling people they are "wrong" isn't convincing, and is downright condescending. Thanks for that.

Then it's not really 2FA anymore. Anyone with access to your 1Password account can login anywhere.

If anybody has access to your 1pass account, you are fucked no matter what.

The biggest threat the vast majority of people face is getting one of their accounts taken over because they re-use credentials and some site, somewhere, got their account db compromised and now those credentials are on a list. Any account that has 2FA, even ones that use "weak" 2FA like SMS, will be immune to being broken into. These drive-by people won't be breaking into your 1pass account to recover your 2FA secret either--that is too much work. They'll just move on all the accounts that don't have 2FA enabled.

(huge asterisk: what I said is only true for drive-by attacks where some bot is burning through a list of a million accounts to try. If somebody is specifically trying to attack you and your accounts... you've got bigger problems to worry about than simply having SMS-enabled 2FA or saving your 2FA keys in a password manager.)

Regarding people getting access to your 1Password account, things have gotten better recently.

1Password supports 2FA to login to the vault itself and most recently Webauthn security keys on browser, which I immediately switched to. On mobile it’s still TOTP, but better than nothing. I’ve got 2 physical keys and Google Authenticator as only 2FA methods.

Once U2F is supported on mobile, I’ll drop TOTP altogether for my 1Pass login. Probably buy another Titan key and throw into the bank box.

If your 1password is broken but 2fa is elsewhere, you are much less fucked than you would be in the case of a breach of 1password + 2fa.

It would be royally annoying, but salveagable.

It's two-step with a unique key every login. It wipes out phishing, password reuse and password leaks as vectors.

It doesn't wipe phising. Phising is getting more and more complex, now phising sites ask you for your ToTP to gain control to your account in real-time. And that's one of the origins of FIDO2. - https://fidoalliance.org/fido2/

Unique passwords wipe out password leaks as a vector. Anything where you type in a code is also still phishable.

People can still log into your account if your unique password leaks. It just prevents them logging into your other accounts.

Point is, TOTP isn't useless.

What's the second factor for 1password?

They added 2fa with duo security + a few other methods.

+1 to this! Moreover, if you are invested into the Apple ecosystem, seamlessly integrates with iOS and comes with a WatchOS app, so you can see your 2FAs in the Watch. A huge convenience when doing TOTP from the phone.

While you can use the watch for this, it's kind of a waste of time with the latest version of 1Password. 1Password automatically copies the TOTP to the clipboard for 1 minute after entering a password so you can paste the TOTP in immediately after 1Password has autofilled the initial login screen.

Works this way on Windows, iOS and macOS too. If you are using 1Password for TOTP this is synced anyway, making using the phone watch/app on a Mac or iPhone for the TOTP redundant. Just mash ctrl+v/cmd+v!

Use Authy. 2FA via account instead of device is hypothetically less-secure but as a practice for individual security, far better than being locked out of everything after the misfortune of losing a phone.

Note that by default authy is vulnerable to sim porting. You can take over an authy account with a phone number.

You could take over an authy account, but does that give you the ability to decrypt the encrypted blob with the TOTP secrets in it? Authy says no: https://support.authy.com/hc/en-us/articles/115001950787-Bac...

Haven’t you lost all your 2fa keys at that point though? Decryption aside, that seems incredibly inconvenient.

Well, maybe? If the SMS takeover attack results in the permanent loss of your phone number, then yes, you have lost everything. However, in most SMS takeover attacks, the attack only lasts some hours, where the attacker has control over your phone number and uses that to pivot into other accounts. With the Authy-style 2FA, they get your phone number, can then recover your Authy account, and get a copy of your encrypted blob, but they can't do anything with it. Any time they try to pivot to a different account, they don't have the 2FA and get blocked (ignoring account recovery attacks that bypass 2FA, that's out of scope). Eventually, you'd recover your SMS/phone account, and be able to download the blob, decrypt it, and have your keys. That's the model I'm seeing.

One protection that Authy should include is not letting someone who has recently performed an account recovery perform a blob deletion. That should require a delay.

Authy only for Chrome, no Authy for Firefox.

Is that really a problem when you have a mobile app and a desktop app?

Nobody paying attention was trying to get regular people to stop writing their passwords down. Threat models matter, there are no regular people for whom "Bad guys steal the book I wrote my passwords in" is a real threat. I bought my mother a nicer (but still inconspicous) Password Book for Xmas. Do I use one myself? Of course not, I have a password manager - but I run vi and flood-wired my home with Cat5 and my mother won't be doing either of those things either.

Regular people get done by credential stuffing, by phishing and straight up guessable passwords. Two out of three of those is fixed by having lots of separate passwords written in that old diary kept in the third desk drawer.

Phishing is hard, against online phishing (as opposed to lazier attacks that collect credentials offline to use later) the only really good defence is WebAuthn/ U2F and too many sites ordinary people care about don't offer that.

I agree to some extent, however most people I have seen with password books still have very simple passwords and often reuse them or create them with simple rules (pet's name + year born + first three characters of the site I'm logging into).

Why use GAuth and not AndOTP and do backups to synced folder?

https://play.google.com/store/apps/details?id=org.shadowice....

+1 on AndOTP.

It's also available on f-droid [1] and of course open source [2].

[1]: https://f-droid.org/en/packages/org.shadowice.flocke.andotp/

[2]: https://github.com/andOTP/andOTP

I'd even recommend Aegis [1]. Also open source with encrypted backups, but has better crypto than andOTP (both devs talk a bit about it here [2]). Plus, it can do imports from other OTP apps for easy migration.

[1] https://github.com/beemdevelopment/Aegis

[2] https://old.reddit.com/r/androidapps/comments/b45zrj/dev_aeg...

Thanks for this, I really like the discourse between these two in the second link. The andOTP author is open about their crypto being sub-optimal and giving the Aegis dev a thumbs up, reason enough for me to give Aegis a shot to replace it. Perhaps they'll join forces going forward and we all win. :)

Where are you storing those backups? If it's the same place as the passwords, you're weakening the second-factor assumption.

In same place as passwords, but with different password and both use different algo for encryption. Well, it's better that nothing.

There are services, like Authy, that let you back them up encrypted. Whether that is appropriate, when considering the security ramifications, is up to you. I, in the past, have printed out the QR codes and put them in a safe as backups.

Just a heads up, but the last time I checked, Authy did not have secure defaults for 2FA.

Authy supports two standards -- the Google Authenticator method, and their own internal standard. Any tokens that go through their internal standard can be recovered on a new phone using just SMS verification, which defeats the entire point.

Your encryption password only applies to Google Authenticator tokens.

https://twitter.com/DanielShumway/status/1092095395478556674

You are correct.

Calling them up one time the person on the phone seemed to be able to 'see' my Cloudflare TOTP code (back when cloudflare had beef with Google about their CEO account getting hacked) but wasn't able to 'see' what my manually added Google Authenticator codes were.

So I'm not even sure if Authy's own stuff is secure at all, perhaps someone from there will jump in.

But using the Google Authenticator way it's a decent option. Just be sure to treat your backup key as a critical component that needs to be stored securely.

Only if you setup SMS. Don't do that. Also, turn off the multi-device feature.

2017: https://authy.com/blog/understanding-2fa-the-authy-app-and-s...

You’re correct. I was referring the the standard TOTP here and not their weird Authy variant

Exactly what happened to me. I accidentally left my phone in my pocket and did a load of laundry. My phone was destroyed and could not be recovered.I had iCloud backups, but that didn't do anything for Google authenticator.

Now it's been a nightmare to recover my accounts.

Same here. What shocked me was how willingly companies would provide secondary ways to access your account. I feel like if I was trying to gain access to an account I didn't own and was blocked by 2FA, I would just say that I had lost my phone.

1Password offers a very usable solution to this problem. It can store your TOTP secret alongside your passwords and generate the necessary codes. And the database is synchronized across devices.

I imagine other password managers offer similar functionality as well.

But that also means that if your password manager is compromised, 2FA is broken as well. This is certainly more convenient, but also less secure.

> But that also means that if your password manager is compromised, 2FA is broken as well.

You either trust the implementation or you don't. If you think a breach of your password manager will result in the hackers ability to decrypt the vault them you need a new password manager.

At some point you have to trust the encryption.

Plus, if it's really on your mind you can store the keys in an offline vault with something like Keepass.

The point is defense in depth. If you must rely on one app, no matter how secure, it does nothing for depth. The whole point of MFA is to have multiple unrelated authentication steps so that when (not if) one is compromised, you're still protected.

It still does provide protection against the attack where someone looks over your shoulder while you type the password, since the TOTP is a rolling code

I don't disagree with at all and I should be clearer in what I'm saying. One has to think logically about where the dangers are and what MFA is used for.

If a cloud based password manager is breached and that leads to decryption of the password vault then that password manager is not fit for purpose under any circumstance, whether you store TOTP keys there or not.

So by default we have to approach from a position of trusting encryption, right? MFA in the realm we're talking about here plays no role in encrypting the vault (yes you can use keyfiles or hardware keys as part of the decryption/encryption process), under this context MFA is about authorising access to an account.

So you can go ahead and store your keys in a second vault, but that vault must have as good security as the password one in order to be secure - i.e. it must not be decrypt-able.

So if each of the vaults much not be able to be decrypted in order to be secure there is no reason to use two, as one will be 'good enough'. not decryptable x not decryptable =/ more not decryptable.

What I would say is that there are key accounts that need to be secured with offline physical protection. For me, and I'm guessing this is the point you're making, those would be the password managers MFA.

If you trust your password manager then you only need to secure access to it in order to secure any other keys/passwords stored inside. So you only need to remember a password (something you know) and use a keyfile (something you have) to get access. You can substitute MFA TOTP key here to if you like, but you just have to secure those two things.

If you trust your password manager, you don't need more than that. You obviously have to trust your machine, that's a rather obvious truism I shouldn't have to point out.

So my point is, be realistic about where you store thing and what you store and recognise where the defence in depth is of value.

I think you are missing the parent's point. It's not just a matter of "secure/trusted" or "not secure/trusted". You could trust your password manager but that doesn't mean that compromise is impossible. One reason for having a second factor is to hedge your bets against the possibility that you mistakenly trusted a service that turned out to be insecure or to have attacks that you didn't consider or know about at the time.

But that leads to something this whole discussion has made me think about - if the service is insecure my data can be hacked anyway. Add that to the fact I should be using unique passwords for each account I have.

So if both of those things are true - what does MFA get me?

You mean if BOTH services are insecure. That's the point, with 2FA you'd have to compromise TWO services to get access to all your accounts. As opposed to storing your TOTP keys in your password manager, where only one service would have to be compromised to get access to all your accounts.

You need to think about the security of the whole system, not just the storage encryption: very few people get compromised by someone running an offline brute-force attack compared to the number who get malicious code running on their system. Password managers can make an effort to harden against that kind of attack but ultimately that's why things like MFA exist since there's a high likelihood that someone will be able to ready anything you have open.

Again, I don't disagree per se, but it's such an obvious truism that you have to trust the device you're using it seemed a bit pointless to say it.

I'm also not sure of the point you're making?

MFA doesn't help you if you open anything like you said. So you're safe until you open something, at which point you've presumably used MFA to open it, but then it's open so MFA doesn't help you any more.

Basically, malicious code on device = game over in all any circumstance.

Here's a simple example:

1. You use AWS

2. You lose your phone, `npm install` the wrong package, etc. and someone gets a copy of your password database

3. The attacker tries to login as you to fire up their bitcoin miners

In the case where you're not using MFA or are using TOTP with a shared seed, they're successful. If you use U2F, TOTP on a separate device, etc. they'll fail even though your computer still needs cleanup.

Consider also that many attacks aren't full privileged code execution — say being able to read a file or dump browser memory but not installing a keylogger or trojan which would allow them to piggyback on your future sessions. If you're not using MFA, that's all they need to be able to open their own session.

The odds of your lost phone landing in the hands of somebody who is going to spin up a bitcoin mining farm on your AWS account is miniscule. A much, much more likely risk is one of your accounts getting compromised by some dude running a botnet using a list of a million leaked credentials.... if you have 2FA on the site the botnet is targeting, you are immune from compromise.

Besides, my phone as the ability to do a remote wipe. It is effectively a bricked door stop until they can log into the phone.

> Besides, my phone as the ability to do a remote wipe. It is effectively a bricked door stop until they can log into the phone.

If they got your TOTP seeds you're in race seeing whether the person who {compromised,stole} your phone can disable your ability to do that first and since a remote wipe requires network access they can simply ignore it and reuse your credentials until you change them.

What all of these have in common is that multi-factor authentication is based on having separate factors. If you store your passwords in the same place as your TOTP seeds, you have one factor rather than two. You might decide the risk is acceptable but that should be a carefully reasoned decision, which was … not apparent … from the comment I was replying to.

So, by that definition, every password manager is broken. If your machine is compromised, it's kind of game over there.

I think you're thinking about this the wrong way. I trust 1Password. I trust it so much that I don't bother storing TOTP secrets in it, because I don't need a small extra dynamic password tacked on to the strong password it already generated for me. The threat stories where someone somehow captures my password but hasn't fully compromised either 1Password or the site I'm logging into (thus invalidating the credentials anyways) are extraordinarily narrow.

1Password TOTP is mostly just theater.

> But that also means that if your password manager is compromised, 2FA is broken as well

Sure, but if your password manager is compromised, you are fucked anyway.

Not if you use MFA as designed: they’d still need to snag your token(s) to complete a login.

Whenever I read about "across devices" or "all your devices" I think "really? my various linux boxes, android devices and tablets including amazon tablets where I've sideloaded stuff?". If I can't use it on a single device I have to write down/remember the password as before which means i'm unlikely to use a long, strong password. And even on devices which are supported I've struggled to marry the now-built-into-android support for these things (not sure if it was 1password) and browser plugin support for sites so I ended up fighting the various UIs to cut and paste credentials between them.

1password and "very usable" should never appear in the same sentence.

I keep an old tablet at home with a second copy of all my rotating keys.

I know all the sites say not to do this, but if I loose my phone or it breaks or while switching phones I have that tablet around.

Not the ideal "cheap" solution, but I had it on hand already and if I hadn't I would have gotten something like a Yubi Key and use that as my second set of keys.

Do a lot of places really say not to do this? I think it's fine, and way better than using SMS as your second factor ...

There is probably no good answer that doesn't sacrifice security. At some point you have to be willing to say "ok, I accept this risk, this is still way better than using just passwords."

Personally, I enroll multiple devices for each account where I enable 2FA (technically not a supported operation, but nobody can really tell if you scan a QR code twice).

It's technically less secure, but I think a decent compromise.

(self promo, but related to the topic at hand: since I don't have 2 phones, I made a utility to enable using T2-equipped Macs as a 2FA client that binds the keys to the hardware. You can check it out at http://github.com/sqreen/twofa)

https://mattrubin.me/authenticator/ stores in iOS keychain and you can restore your device with TOTP codes from itunes encrypted backups.

If you use an iTunes encrypted backup to a Mac (or PC?) then restoring to a new phone works fine. I’ve restored my TOTP to a new phone this way.

I guess for those who don’t want to do old-school backups to a PC this isn’t helpful though.

I think just storing the TOTP in 1Password is probably the best approach for the average person. I print the backup codes and file them to a filing cabinet.

Edit: for certain TOTPs I’ve also put them in an app on my Mac, so that gets backed up automatically with time machine. Also makes it much more convenient to get them than having to pull out a phone.

> If you use an iTunes encrypted backup to a Mac (or PC?) then restoring to a new phone works fine. I’ve restored my TOTP to a new phone this way.

Really? That wasn't my experience when I restored from backups. Had to set them up again despite most everything else carrying over.

Google broke that for their Authenticator some time ago. This app https://mattrubin.me/authenticator/ works with encrypted backups.

Looked again and it seems like things changed sometime around 2015-2017. Sorry for the misinfo. https://dpron.com/recovering-google-authenticator-keys-from-...

This exactly happened to me (I took my iPhone swimming in the Mediterranean).

My personal solution is 2 encrypted files - one for my passwords, and one for the keys for the (sadly few) services using TOTP. So losing (ie stealing then decrypting) one is not losing both - ie the password and the TOTP are still mutually exclusive factors.

I got back many of my TOTP accounts fairly easily, but boy the amount of trust placed in a SIM Swap is still scary.

Compare for example to (my idealised way it should work) of every online account I have using 2 different U2F keys (ie different hardware IDs) to control the account. One I lock away in my bedroom safe and one I carry in my wallet [#]. Lose one and I still hopefully have the other. But a) can you name any service that does that today? b) is my bedroom safe actually safe ?

My work TOTP was backed up on cloud - and it still worked! The app had stored the key (probably securely) in a icloud backed up location.

So the TOTP was no more safe than iCloud. Which is to be fair a pretty high bar. So I am fairly relaxed about it. But still, TOTP hardly counts as "something you have" these days.

But I completely agree that the lifecycle problem (revocation mostly) is long way from being solved. I would just like to see dual U2F access controls as a default on web services today.

[#] That's another problem. I am seriously contacting wallet makers to see if I can design a USB key and u2f key friendly wallet - I hate my keyring appraoch.

This is why I use Authy for my 2FA tokens. They store everything encrypted in the cloud, so you can wipe your phone without losing access to your whole world.

This

Also, "users will try to provision multiple devices with 2FA" well, you know, some services need a shared login. What then? (And no, in many cases you can't expect the user to use their personal login in some cases)

Shared accounts are a thing, and if they need 2fa make it so.

And yes, phones get robbed, lost, dropped into toilets, run over, their battery catches fire, they get irrecoverably damaged, a recovery scheme is needed for accounts.

I ran into that issue when my Nexus 5X died to the bootloop issue. It was enough of a pain that I just gave up and use Authy with the remote backup enabled.

I've dealt with phones dying/being lost on three separate occasions and recovering the accounts, as you've said, is a huge hassle, and I always end up screwing up at least once resulting in dealing with a round of phone support calls to get access again.

Even after your edit: Treat your TOTP keys like passwords and store them.

It's like "secrets management". At some point, somehow, automation programs need secrets to access APIs. At some point, no matter what, there will be sensitive data in a file on a container/server for your program.

Likewise, "Kill the Password" initiatives are shorthand for "Yeah we know there will always be a password somewhere but let's merge it with 2FA, call it a PIN and we'll be good".

I'm ranting a bit, but what I'm saying is that people will need to store secrets for accounts for a long time. Every single Internet citizen should have Keepass or Lastpass for account management, and that database should be well secured, and should also house their TOTP break-glass codes. (If you're paranoid you can store them in a different database). Barring a Password DB compromise, 2FA still gives a good benefit.

Duo Security has a phone migration/transfer feature now. You need to enable it in your org settings and opt-in.

I just can't believe Duo doesn't have a desktop app of some sort, even if super basic. We use this where I'm at and I have to grab my phone while sitting at my desk to 2fa into things so many times a day. I use Authy for a lot of other stuff and it has a little chrome webapp/extension that'll let me not constantly grab my phone.

Random thought, they have apps that mirror your iPhone screen, typically for development or presentations. You potentially could use that as a workaround so your phone just needs to be connected or on the same network etc.

See Reflector 3, works with Android/iOS.

Authenticator Plus is a nice simple paid (one time) option for encrypted OTP syncing, and supports both Android and iOS.

Additionally, Duo Mobile supports cloud backup and restore of third-party OTPs. (Disclosure: I work for Duo.)

Sounds like the TOTP apps need an encrypted import/export capability, kind of like what HSM's have (including Yubikeys and TPM's.) You have one TOTP app generate a key pair, give you the public key, which the other TOTP app uses to generate an encrypted blob out of the stored codes, which only the target TOTP app can decrypt.

Since modern phones are getting TPM's, it's even becoming possible to do this without any private keys being accessible to the apps.

HSMs generally support import, but not export. Keys generated on the device can't be transferred elsewhere, but you can generate the key separately and import it into the HSM while keeping a backup copy. TOTP apps generally work the same way, except the keys are always imported: you can save the secret used to configure the app (screenshot the QR code, or scan it with a regular QR code reader) and use that to set up the same TOTP on a different device.

> You have one TOTP app generate a key pair, give you the public key, which the other TOTP app uses to generate an encrypted blob out of the stored codes, which only the target TOTP app can decrypt.

Unless you somehow verify that the public key came from a "genuine" TOTP app, that's essentially the same as allowing the keys to be exported in plaintext. (User/attacker generates their own key and presents it to the TOTP app which duly encrypts its secrets in a way the user or attacker can easily decode.)

Exactly this. The onboarding process is simple but the total cost of ownership expensive. I ended up having my older mobile phone with me like a token device and will migrate its keys when I have time to do that. I was even confused by the Samsung migration using the USB OTG connector since doesn't clearly states that some stuff is not migrated.

I hate when you need to put your brain in sysadmin mode instead of disconnecting it expecting a process that just works.

That's why I have an NFC hardware key. Doesn't matter if I get a new phone then. Of course if you lose the hardware key, you still have the same problem.

Something I do to mitigate this problem is take a screenshot of the barcode and store it in keepass - along with the password. So next time I change phones- I just scan the codes back and I am back on track with the TOTP.

> I thought we were trying to stop people writing their passwords down and storing them next to their computer?

Yes- but I guess it's okay to use password managers anyway. And they make it easy to store screenshots and stuff as attachments.

> Why are we developing systems that use TOTP if we are encouraging users to treat them like passwords, undoing the vast majority of the security benefit?

Better advice would be "treat them like passwords, but keep them encrypted separately from your password manager."

You shouldn't need to restore your TOTP secrets to your phone more than once every couple years, so there isn't any reason for you to have access to them 20 times a day.

If you're using Google Authenticator and rooted your phone, it's not hard to extract the database and transfer the secrets to your new phone. Or you could use an alternative like Authenticator Plus which supports export / import (and has some other nifty features). Of course, both these options come at a cost to your security posture.

>The main problem I have with TOTP (What you're using when you use Google Authenticator) is that the migration path doesn't exist when you get a new phone.

It also doesn't migrate when restoring from backup, as I found out when my iPhone had an issue and I had to get a new one - if I'd known that I'd have done it on a weekend :/

Saving TOTP keys is not that bad. Even if they are on a piece of paper next to your computer, it is still good protection against keyloggers. If they are in a safe and that safe doesn't contain the corresponding passwords, that's probably the best you can get.

Note that you can use two phones in case you want recovery.

> the migration path doesn't exist when you get a new phone

I faced with this problem last month. I was using `Google Authenticator`, mainly because of its simplicity. But you cannot see the secret keys for entries. I had to transfer sqlite database out of the phone and extracted private keys manually.

> If you now buy a new phone (which users might be doing once every 18-24 months), you need to log into each account and generate a new TOTP key and void the old. That's a couple of hours work.

No you don't. You can simply save the original key and enter it again 'manually'. I say 'manually' because it's really copy and paste, so it doesn't take very long to do at all. A few minutes at most.

Every single time I've set up TOTP for any account I can simply select to enter the key manually into Authy or Google Authenticator etc rather than scan a QR code, so you always get access to the key. Just save it.

You can be paranoid about this and store them in a separate password database if you like. Or you can store it alongside the passwords in a password manager.

Then just secure your password manager with TOTP and all you have to 'recover' in a disaster recovery situation is the password manager password (should be memorised) and the TOTP key which you can store under physical offline security if you like.

That behaviour is literally what this article is discussing trying to stop:

- Documentation: Warn users not to save their QR codes

- Documentation: Tell users to only provision one device

- Documentation: Suggest TOTP applications that don’t support unencrypted export

Why are we telling people to use 2FA if we then immediately remove the security benefits by telling them to treat it like a password?

The "Warn users not to save their QR codes" was to address the issue of users who might "Screenshot their TOTP QR codes and leave them lying in their Downloads folder". I don't see how that is necessarily applicable if, say, I print the QR code and save it in a safe deposit box, where I also have my FileVault recovery key and my 1Password Emergency Kit.

I also don't really understand the "Tell users to only provision one device" point. If the device is one like the gemalto thingy that we use at work to login to AWS, then sure, I can see why having more than one is bad for a given login. That shows the code to anyone who presses the button. If you had two, you'd need to keep both of them under your control at all times, and then there would be a decent chance then that if you lost one or destroyed one, you would also lose or destroy the other at the same time, so having two might not even gain you much in reliability.

But what if the devices are my iPhone and my iPad and my Apple Watch? They have pretty strong protections to prevent a third party from using them if I lose them. The consensus seems to be that unless I'm targeted by a government, a lost modern Apple mobile device with a long passcode is not going to cough up its secrets.

(Well...at least an iPhone or iPad. I think Apple Watch defaults to automatically unlocking if you are wearing it and unlock your iPhone. That might be exploitable if the person in possession of your watch can put it on and arrange to be close to you when you unlock your phone. I wonder what the range is for that? Would it work through a typical office wall?).

None of those points above address what I said, nor should they because TOTP should allow for disaster recovery.

To allow for disaster recovery the keys used to generate they TOTP codes must be storable somewhere.

The article is creating a strawman by suggesting to screenshot QR codes and leave them in the downloads folder. It's perfectly reasonable to save keys in a secure manner.

It's also giving borderline bad advice of trying to engineer in an unrecoverable state should a single device fail. That's a poor suggestion to give under any circumstance.

Saving TOTP keys into a separate dedicated encrypted vault under physical security is absolutely a valid method of allowing recovery from a device failure.

That's what recovery codes are for.

If you're ok storing the TOTP key, you could just store a recovery code instead. Recovering an account is generally audited, so this is more secure that just provisioning another device.

My point is just that it's still a lot of effort to recover, and we're basically encouraging people to undo the benefit of MFA by storing the TOTP key/recovery code right next to the password they used to get through the first factor...

There's no functional difference between the two codes in terms of account access. And I dispute the claims of 'audting'. No service cares. As long as you give a correct code then in you go.

So why use recovery codes and then have to keep them secure with the drawback of resetting up every lost account when you can put the exact same amount of effort it to storing and securing the original key and re-setup all accounts in a few minutes?

I speak from personal experience on this topic as to which is easier and how the effort to store and secure recovery/original keys is exactly the same.

>There's no functional difference between the two codes in terms of account access

Are you sure?

The last time I used a recovery code I got an email and my 2FA immediately stopped working.

If I have your TOTP key I can use your 2FA without you even knowing, even while you use it. It effectively gives me an unlimited backdoor into that account.

> Are you sure?

No, because I haven't tried every service. What I do know is that key services I have notify me of every single login that is made, so I'd know anyway.

Plus, one has to examine at which point back up the chain the problem might occur or be spotted.

In this instance you've managed to access my TOTP keys, which means you've hacked and broken the encryption on the password manager or you've got malicious code running on my device. Or you have physical access to a running and unlocked machine.

In either of those cases I'm already truly fucked.

I would imagine that any scenario where I managed to get hold of your recovery keys would involve the same things, so you'd be truly fucked.

So in that sense there's no functional difference in the way I have things setup for me.

On IOS use "Authenticator" app by Matt Rubin. It'll save codes with iTunes encrypted backups but not to iCloud. Then restore to new iphone. Not sure how that'll work out when they retire iTunes.

Yes! Plus you might not have an expensive data plan when you travel.

Better solution - central trust via apple face recognition (federated, private), but used by others as login.

AndOTP has an import/export feature. Bitwarden has automatic sync. tetripin has just a clear text file you can export. There are technical solutions.

Screencaps of the QR Code inside a good password manager with a different password/key.

Yes, the weakeast point is that password/password-manager now.

Is Authy not TOTP? I migrated to it from GA specifically because it divorced me from my single device.