De-Googling TOTP Authenticator Codes | Hacker News Reader

De-Googling TOTP Authenticator Codes

imrannazar.com

105 pointsTwo9A135 comments

To be clear, the point of storing a secret token on your phone and then typing over some codes that prove you have access to the secret still, is to provide 2FA. If you use oathtool on your laptop, and the password is stored there as well, you're back to 1FA

That can be fine if that's what you want, but if you wanted 2FA:

- FreeOTP: https://f-droid.org/packages/org.fedorahosted.freeotp

- someone forked that and called it FreeOTP+: https://f-droid.org/packages/org.liberty.android.freeotpplus

- FreeOTP again but from the dark side of the internet: https://play.google.com/store/apps/details?id=org.fedorahost...

- etc. It's a dead simple protocol so there'll be lots of options. Pick one that you trust

Edit: Even with the PGP option shown at the end of the article, the secret is still accessible to any malware whenever you access it. Unless PGP-based 2FA becomes super widespread, this won't be something malware looks for and so you'll be fine unless you are targeted by intelligence agencies, but still, it's not quite 2FA because it's not something you "have" but something you "know" (the PGP data's unlock password)

> you're back to 1FA

Which might be exactly what I need if another dumb website wants me add 2fa where I don't want to.

Considering just making a publicly accessible webpage for those codes at this point lol.

The risk factor is mainly that someone got the password from a web application hack not that they logged into your computer and accessed your password manager. In the web app scenario it is still a second factor.

If you use a password manager, or another mechanism that makes each password unique and unguessable, the password and the "2FA" seed token are both the same type of secret string, and both are stored on the same disk. There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely

But I'm not saying you should care about this. Everyone can make their own risk assessment, especially if you know about common attacks like the data breaches that you mention

yes, fair points. Thanks for clarifying.

the password and the "2FA" seed token are both the same type of secret string

This is a category error. The 2FA seed token may be a string of bytes just like the password, but the seed is never communicated outside your device. That makes them different types of secrets: a capture of the transmitted login codes will not compromise the 2FA seed. Even if you auto-generate the password in the same way, it's the actual valuable secret that needs to leave your device -- by design.

I don't know if a website database breach compromises both keys. Is the 2FA seed a pre-shared key, or is the algorithm asymmetric? I seriously hope it's the latter, but I don't know for sure.

It is symmetric.

Symmetric as another poster mentioned. With some margin for connection delays (e.g., server checks 3 codes (1 forward and 1 backward) for a total of 90 seconds) [1].

I'll be interested in a asymmetric variant although I'll probably use a popular library and call it a day if I have to get involved in 2FA.

[1]: https://auth0.com/blog/the-working-principles-of-2fa-2-facto...

Do we have the crypto to build an asymmetric variant? The way that I’d immediately think to do it is have the authenticator create a signature over the current time (chunked into 30-second windows) and the service verify that signature, but obviously those signature texts are way too long to manually enter as a one-time code. (Symmetric) TOTP solves this length problem by just truncating the output of a hash function, which both the authenticator and the service can produce because they have a shared secret. But in the signature case the service would need the entire signature to validate it; any truncation would make it useless.

It’s been a while since I did any crypto. But it feels like the shortness of the one-time-code probably makes it impossible to do asymmetrically. If this is indeed the case there is probably an elegant proof or some better way of thinking about why it’s impossible. I would be interested in reading that.

Even if pw and 2fa secret are stored together you get better protection against phishing because you never enter the full 2fa secret into a website.

Thanks for providing a concrete example where this is indeed the case! You're right, and I'm aware of this, but the scenario is quite constrained. This matters when:

1. The attacker either captures the OTPs on the real website, or on a phishing page. They do not have access to either the website's store of 2FA tokens, nor your password vault.

and

2a. Having you enter one or two OTPs on the login page is not enough. The phishing page can claim "wrong OTP, you can try again in 30 seconds" to get at least two codes. The attacker can open a login session and go to down immediately when you enter it, but if there is a protocol where there's a delay of e.g. 24 hours, they would need to phish you again after 24 hours and that's unusual for them to bother with (beyond opportunistically) as far as I know

2b. The attack isn't automated and the attacker is also not laying in wait for someone to fall for the phishing (like when having sent 10 phishing emails and waiting for one employee to bite such that they can get into an organisation). In that case, the OTP almost certainly has expired and can't be used anymore

While #1 is common, #2 is rare as far as I'm aware. Once you're into an account, you usually can navigate to e.g. a transaction page within a few seconds and then enter the same OTP¹ again (because the time window hasn't expired yet) or ask the user for a new one a few seconds later as described

A great protection against this would be a device that displays what it is that you're authorising, such as these old bank card readers that show on a little screen like "login" or "transaction of 1337€ to NL00RABO0123456789", but these go well beyond the standard 2FA seeds that you can store in a vault

Either way, you're right, there is this benefit of having 2FA even if you store them together. If this is within one's threat model, but theft of your vault is not as big a concern, it's a valid solution

¹Yes, OTP can never be the "same" by definition. But this works in 9 out of 10 customer sites that we see (security consultancy firm; thoughts are my own yada yada)

Better idea, use something that is able to authenticate the server and disallows fishing, like yubikeys or passkeys! Much less challenging to secure than showing something on the screen.

It also provides enhanced security against session hijacking attacks.

Most sites require 2FA for changing the password, but do not require the password for changing itself.

If the threat model includes info-stealers, then having the TOTPs on the same device as the passwords is a risk.

If the threat model does not include info-stealers (and instead includes only phishing and in general getting passwords/codes intercepted, getting a website with bad security compromised etc) then having the TOTPs in the same device does not really increase risk.

Imo in the first case, one should probably not have the passwords on the phone either. Use a phone for the OTPs and computer for the passwords for example. But that is very impractical and carries increased risk of (temporarily) not being able to access stuff in certain situations. It could be a good thing depending on what one wants to guard themselves against. If your goal is to have better security than most people, using a good password manager that is not a browser and 2FAs is as many services as possible already carries you very far. If you due to work etc you have increased risk of being targeted, prob more is needed.

> [...] then having the TOTPs in the same device does not really increase risk.

... and having TOTPs at all does not decrease any risk, either. There's no benefit to the situation where you store 2 good secrets in 1 place as compared to storing 1 good secret in 1 place.

> There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely

Over this entire thread you keep repeating this, and you're so confidently wrong.

If a hacker (or shoulder peeper) gets my password to a site without a TOTP, they can login. 1FA. If I also use a TOTP adjacently, the hacker can't login and the shoulder peeper has a window of 30 seconds.

Its 2FA. Storing critical TOTPs in your password manager is bad practice and thus bad 2FA, but its still 2FA.

It is not necessarily 1FA even if just use the laptop.

One password could be leaked and if the password alone gives the access, that is 1FA.

If the combination of two tokens forces the each login require access to that laptop and you need some password to unlock the password vault, this adds 2FA layers to services which are not the password manager.

The password vault can't be copied? (In unlocked state I mean, same as how they could get the password)

Either your laptop is compromised or the server. In either case, if they get access to the password, they also get access to the 2FA secret if that resides in this vault together with the password. Just a password alone is safer than 2FA alone because that at least gets hashed and isn't stored in plain text on the server side

I am not sure if we can change the definition of 2FA based on that.

What if compromising the laptop requires brute forcing something? Then laptop was protected by something the adversary did not know. If we expand this argument, there isn't secure 2FA in place. Maybe laptop compromise leads into situation they can compromise your phone over the same network and the argument is the same.

I would say that there is some additional factor if instead of just guessing or reusing leaked the password, they also need to compromise my laptop and likely get the privilege escalation before they can read the plaintext vault content. You are not allowed to guess anything in that process or that makes 2FA definition valid.

2FA in practice is just about increasing the entropy and protecting against guessing. Passwords can be leaked so we added additional entropy with seedable TOTP suffix. Every additional factor is just an additional entropy that adversary needs to guess and cannot directly obtain.

So for 2FA to be truly valid, we should not use password managers at all and maybe we should be also immune to xkcd comic 538.

I would recommend Aegis Authenticator [1] - available in the Play store or F-Droid. It's been featured on HN now and again. One thing it can do is import the data of all the other OTP apps, and create backup files (the seeds) which you can do whatever you want with.

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

I use this, but recently ran into an issue: I only have one Android device. It's great to be able to back up my secrets, but frustrating to need to spin up an emulator on my computer to run an Android app just to use the backups, if my primary device is offline for whatever reason. Is there a way to use the vault directly?

Very interesting question, I have no experience here. What I do instead is scan my QR codes into two apps on different devices when I make them (I do not make them very frequently so it's not a chore). Because I'm sort of pessimistic after a lifetime working in tech - everything that uses electricity breaks and fails. I build redundancy into all my (things) and just expect one of them to fail. Goes for email providers, hard drives and OTP codes - if I could have a backup washing machine, I would. :)

> What I do instead is scan my QR codes into two apps on different devices when I make them

Amazingly, I'd never even considered this as a possibility. Thank you for the paradigm shift.

I do that too, but you don't really need to with Aegis as it has import/export.

Aegis also works very well on Android Go dumb-ish phones.

1. Aegis has a setting for creating secure backup on every change. 2. Autosync that backup directory via syncthing to your PC. 3. Run a compatible desktop software (e.g. linux has authenticator) to import aegis backup files manually.

Since totp addition is not a frequent activity, the last manual import step was not a hassle to do whenever needed.

Aegis authenticator backups can be imported into Gnome Authenticator. I'm using it, I know it works, but I don't recall the format GA requires

If you move the secret tokens onto the same device (like in that emulator that presumably runs where your password manager also runs), we're again back to the oathtool solution that is described in the OP, that doesn't have the same security benefits as the original intent of supplying you with a 2FA token. Not saying you shouldn't do this, just something to be aware of when you use the export mechanism in this way

I just copy the OTP-URL from Aegis and place it into pass (passwordstore.org, with the pass-otp extension) on my desktop computer. That pass instance is backed up along with everything else which matters.

Keepass now supports 2fa tokens, just use that. Plenty of open source clients on different platforms and you can sync the encrypted database file using whatever mechanism you like, drop box, one drive, etc.

KeepassXC (Linux) can import Bitwarden files directly as well, as both programs support H/TOTP there's a solution here. Not what I do, but I can see the use case aligning to the GP's comment - using Bitwarden (e.g.) as the TOTP app could allow importing it's backups to KeepassXC if your main/only mobile device fails and you only have a laptop etc.

> If you use oathtool on your laptop, and the password is stored there as well, you're back to 1FA

In estabilished terminology you don't need multiple independent devices. For example email "magic link" is a common second factor.

Because it requires access to the email system, that's a separate system even if it's being forwarded so long as you have a valid login to the email server

But, yes, the exact boundary is definitely debatable. It's clearly less secure than a separate token generator that you keep on your body at all times; clearly more secure than no second confirmation at all

But if you log into your phone with the password and TOTP, is that also not 1FA?

If both are on your phone, then yes. I should qualify, though, that "people [including me] generally consider mobile OSes safer because the permission model and process isolation is on a whole other level" (quoting myself from https://news.ycombinator.com/item?id=45091618)

That's not 1FA, it's just not using a separate device as the second factor. There is definitely a decrease in security having the 2FA provider on the same device as the password manager, but it doesn't negate the majority of benefits of 2FA.

Yeah isn't the threat vector your password being leaked/cracked. You're still safe here.

The argument can me made that logging into something on your phone isn't 2FA either then...

I happily store all my passwords and OTP in the same vault. Is it slightly riskier than having them separate? Yes. Would having all my passwords stored as a horcrux be safer too? Yes.

Do I still get the security of TOTP as a rotating component of my password to prevent breakins from stolen credentials? Yes.

> If you use oathtool on your laptop, and the password is stored there as well, you're back to 1FA... that can be fine if that's what you want.

A lot of the time that is what I want. 2FA is pretty overkill for low-importance accounts if you're using a long random password anyway. But some services make it mandatory.

I quite like TOTP for this reason - it's much less annoying to autofill TOTP than to retrieve a one-time code from SMS or email.

If you log into accounts from your phone, that's also 1fa in the same way. And if you keep your phone in the same place as your laptop, so it can get stolen at the same time, that's also effectively 1fa.

The threats that TOTP protects against are ones that don't involve losing your device. For example, if somebody breaches a password database or phishes your password, TOTP codes prevent them from using the leaked credentials.

Phishing/bulk password dumps are more common issues than device theft.

If you have a Mac, what about using keychain? It has a cli/api and is protected by the Secure Enclave (so 2nd factor to unlock that)

> Secure Enclave (so 2nd factor to unlock that)

How so?

You need the fingerprint sensor to unlock it

I don't think you do. My Mac Mini has the same Secure Enclave as other devices with the M4/A18 SoC, and it literally doesn't have a fingerprint reader (or Face ID).

The Secure Enclave is used to handle data around biometrics, but biometrics aren't a requirement for its use.

Biometrics on Apple devices are generally a convenience method so that you don't have to type your strong password every time, they're not a second factor to the password.

Or rather, the people interested in phone/device theft aren't expecting and aren't after your TOTP keys.

> If you log into accounts from your phone, that's also 1fa in the same way.

Not quite, there's a lot more sandboxing on phones than what might go on with desktop.

Not on my desktop. It is much more sandboxed than any smartphones.

That sandboxing doesn't help if your phone gets stolen.

iphones are pretty secure against theft unless they get your pin or some such. I have two friends who forgot their own pins and the data was unretrievable in spite of their best efforts.

It depends on the phone, but for many phones the security story remains very good even when lost, unless someone knows your passcode. So it’s still “something you know” protecting the password and the TOTP code, but it’s different things that you know and strict rate-limiting on the phone side that wouldn’t be possible on an internet-exposed authentication system makes it extremely difficult to guess the phone passcode.

I don’t think we need to couch it in unclear terms: Apple and Google have made very secure devices that happen to be phones, with Apple’s computers as locked rock solid as their phones now.

It’s Microsoft that’s stuck in unsafe grounds, and it’s partly the cultural apathy of their user base that’s at fault.

1Password works well too (Canadian company I think)

> If you use oathtool on your laptop, and the password is stored there as well, you're back to 1FA

This is trivially true, but also misses some nuance. Not all "1FA" is created equal. A leaked password can be used by any bad actor remotely who has never met you.

Also your computer could itself have a password and disk encryption, so someone who stole it would still need 2 factors: something you have (your physical laptop) + something you know (laptop password).

Regardless, TOTP is not phishing resistant, so I do tend to prefer passkeys but I understand they're problematic in terms of losing access to the devices/clouds with passkeys stored and then what do you do? (Sometimes services have an out-of-band process to prove identity and reset passkeys, but not all do)

I'd probably use Aegis on android https://github.com/beemdevelopment/Aegis?tab=readme-ov-file#... it's a bit more modern.

What you describe in the first paragraph isn't 1FA. There's still two factors—its just on one device.

You're conflating "factors" and devices.

Some time ago I realised how vulnerable I was keeping all my TOTPs in Authenticator __only__, in the event of losing/breaking my device (and no, there is no way I would sync them to Google cloud). This taught me few things:

- there isn't much to Authenticator and TOTPs in general, it's just a secret, which can be shared across multiple TOTP managers and devices. I had solved the "single point of failure" concern

- that opened a new need for "safe TOTP replication with offline access", and that's how I ended-up running my own vaultwarden instance and using the bitwarden clients across devices.

I'm glad I did, and I can't recommend it more. IIRC, this¹ helped tremendously along the way.

¹: https://github.com/scito/extract_otp_secrets

And this is why Aegis has a working encrypted offline backup.

Yubikeys support Google and other TOTPs too

For years I've managed all my TOTP codes with KeepassXC. Not a single problem, great software.

I can recommend the Aegis app for Android. Works great and has encrypted backups.

Or Ente Auth: https://ente.io/auth. Opensource, encrypted, can be used on any OS, has sync/backup. The problem with using same password manager for OTP is that you kind of loose 2nd factor: 1 app compromised - passwords and OTP are compromised too. My approach is to use password manager's OTP generator for non critical services and dedicated app for the critical ones..

Replied to another comment with the same recommendation before seeing this, here's the URL for those interested:

https://github.com/beemdevelopment/Aegis

Just consider that storing TOTP codes in the password manager negates the advantage of two factors authentication, namely the added security of needing a second device. This would keep your logins safe even if somebody managed to breach your KeePassXC database.

You are allowed to have two separate databases, with different passwords. You can even store them on different devices!

It’s still one device.

The second factor does not have to be a second device. Like everything security, it’s what you’re protecting against. Shoulder surfing and device theft are not something I worry about in my home setup, for example.

> The second factor does not have to be a second device. Like everything security, it’s what you’re protecting against.

It doesn't matter if you store your 2FA seed on a billboard or as a tattoo where the sun doesn't shine: 2FA means two factors. The definition doesn't change when your home setup's threat model doesn't call for 2FA and you thus decide to store two secrets in the same place (making a compromise of one necessarily a compromise of the other, thus 1FA)

> making a compromise of one necessarily a compromise of the other, thus 1FA

The only necessity is logical necessity, and it doesn't apply there.

You're saying you can store two pieces of information in one file, without a compromise of one implying a compromise of the other? Do elaborate

GP stated:

> The second factor does not have to be a second device.

Now, you are talking about two pieces of information in single file.

This is so wrong. You’re conflating where things are with what they are. Two factors does not mean two devices.

Yes it depends on your treat model. But being defeated by one simple keylogger isn’t a risk I’m willing to take even at home.

And yes, 2FA single use codes will protect against a simple keylogger.

But if its on the same device, it will not protect you against a password database harvester.

If you login from your phone, it’s still one device. Should we have different totps for different devices?

Something that you have can be your own pc.

You're onto something even banks don't seem to understand! The industry standard for doing financial transactions calls for 2FA but then they make a mobile app that can self-approve transactions. Yes, using only one mobile device is 1FA, just like using one desktop only, but people generally consider mobile OSes safer because the permission model and process isolation is on a whole other level

There's a grain of truth in your statement, but no matter how hard it's to accept for all of us nerds here, in real life words are defined by usage. If industry calls it 2FA, users call it 2FA, then it's 2FA.

They can call the sky green but unless the wavelength changed, I don't see the benefit of taking over that terminology, no matter if you're a user or a nerd or both. That's the real-life situation: sky isn't green, idk why anyone would need to "accept" that or not when it factually isn't the case

Your choice of example is somewhat self-defeating: blue-green is probably the best illustration of terms with big semantic overlap even in languages which care to have separate words for these colors (there are those which has one word for both). Generally, meaning of words defined by informal convention of majority. You are free to disagree with it, but it only means you will speak your own dialect always in need to explain yourself to everybody who's not you.

If you store two databases on two devices it makes them suddenly one device? What kind of security sorcery is this?

> negates the advantage of two factors authentication

Like with all things it depends on your threat model.

If your threat model includes risk of leaking all data from your password manager – then yeah, it worsens your security.

Otherwise it still covers all other risks:

1. it makes bruteforce basically impossible

2. it makes phishing harder (assuming that your password manager supports autofill and that it checks domains correctly)

3. it lowers the risks if a single password leaks

All of this is true without 2FA, just storing securely generated passwords in the manager.

Whether it negates the benefits of 2FA (i.e. whether it's 1FA) doesn't depend on the threat model. The threat model is what makes an individual decide whether 2FA is worth it

No? Without TOTP in Keepass, an attacker still only requires a password (which may be brute forced or otherwise obtained from badly secured websites). If you have TOTP, they _also_ need a copy of your keepass-file, the password and any other factor to _it_, or have access to your machine during a session or so.

Think about how the attacker gets there:

- "an attacker still only requires a password (which may be brute forced" Brute force? Then it wasn't generated securely. Use Keepass' built-in generator or another one that is meant to generate passwords with. You could make the same argument for the 2FA seed: that can also be generated insecurely or set manually by hand

- "or otherwise obtained from badly secured websites" The attackers can obtain the 2FA seed in the same way. Furthermore, the 2FA seed is stored plaintext in the website's database whereas the password is typically stored in hashed form (which is unbruteforceable if you generated it securely)

- "they _also_ need a copy of your keepass-file, the [main] password" The attacker either got the website's password from this same file (so they evidently have that file and the main password to unlock it), or if you imagine a scenario where the site got hacked and the stupid site stored your password in plain text, then they have access to the site (and the 2FA seed) anyway because they hacked it. So long as you don't re-use passwords (don't need 2FA for that, just a password manager), a site's breach has no impact beyond this one site that was hacked outside of your control

- "and any other factor to _it_" Do you mean the key file here? Or what other factor? Either way, again: if they need that to open the vault then they can't get at the passwords either, so what benefit does {2FA when stored inside the password vault} have?

I don't know of a scenario where an attacker can get the website's password from the vault, but not the website's 2FA seed, when you store both inside that same (encrypted) file

1. TOTP (the only 2F we could be discussing) is derived in a specific way by e.g. Keepass, which has been audited. There is an RFC for this. I don't see the vuln here. 2. But this info is transferred just once, so the method relies on either intercepted both (pw and TOTP seed) that one time. Far less likely than intercepting just the pw every time you login. With a compromised or insecure server: all bets were off already. 3. Even if you have safe service-dependent passwords, as one should, 2F renders it useless in certain scenario's, if all they have is the password. 4. Yes, factors to the keyfile. It does not have to be just a password.

While it seems a reasonable assumption that 2F seed and password are stored alongside eachother, the vuln does not need to expose both. We don't know. But we do know more factors means more opportunity for 1 factor to be accidentally safe.

It doesn't negate the advantage of 2FA. There are so many scenarios that don't involve your entire password manager database being leaked in plaintext. In that case, you likely have much more to worry about considering the attacker has a bunch of places to pivot from (account recovery flows, recovery email accounts, etc..)

I also store them in KeePass, except I have a separate DB for codes that exists only on my phone. I use Keepassium on iPhone, on Android I believe Keepass2Android is pretty good.

Ente auth is a great free option with sync and apps for every platform. https://ente.io/auth/

They also have a good Google Photos alternative, which is how they make money.

> The tool outputs the current date and time, so you can double-check that your code won't expire (at :00 seconds) before you get a chance to type it in

A lot of TOTP verifiers often check within ±1 time interval, so you can often just use the first code you see, no need e.g. to wait for it to roll over.

The worst offender in 2FA business is Steam, as it uses custom 2FA and you must install their app - no way to use 3rd party OTP without jumping through hoops and risking security.

I believe Aegis has you sorted with Steam as well

Couldn't Steam break this any second though?

Or one could run into some edge case, e.g. when Steam asks for different code when trying to change Steam password - https://github.com/beemdevelopment/Aegis/issues/1613 .

https://github.com/beemdevelopment/Aegis/blob/v3.4.1/app/src...

> // NOTE: this assumes that a global root shell has already been obtained by the caller

:-/

My recollection when I last tried this stunt is that it's a boatload of nonsense to try and exfiltrate the Steam credential material, and I wasn't able to find any supporting docs in the Aegis nor on their site about any alternative they have to "root your phone and sniff the keys out of the sibling app"

At work we use OneLogin, set to require the app. However, it stores a regular TOTP code in the app, it's just encrypted with the android keystore. I had to hook the base64 decoding function on my rooted phone to extract it, and put it in my password manager instead. I've been unable to figure out how to decrypt keystore-encrypted secrets in any other way.

You could have also used "fridump" [0] to dump the app memory and search for strings that look like TOTP secrets.

[0] https://github.com/rootbsd/fridump3

same with the european commission. they are turning standard otp off and requiring a custom phone only app.

guess they cannot wait for passkeys to tie you to one apple or google account.

I've been storing OTP secrets using `pass`[0] with `pass-otp`[1]. This does the whole symmetric encryption for me using `gpg`, decodes the URL for me to pass it into oathtool, and allows me to share the codes with my phone using Android Password Store[2]. This is all deceptively simple to set up, assuming you have a git server you trust to synchronize the codes with, or some kind of other method using maybe tailscale or syncthing? As long as you don't need the codes on Windows, where the QtPass app is unmaintained and can't generate OTP codes on Windows, you're mostly good.

Oh and I use `zbarimg` to decode the QR, as I've integrated it with my screenshot script and it can decode more than just QR codes.

[0]: https://www.passwordstore.org/

[1]: https://github.com/tadfisher/pass-otp

[2]: https://f-droid.org/packages/app.passwordstore.agrahn/

> This does the whole symmetric encryption for me using `gpg`

gpg actually uses a public/secret key pair with pass which has a pretty cool effect that you don't need to enter your passphrase when adding an entry to the store, because it uses the public key to encrypt.

You're right, gpg does asymmetric encryption. Don't know how I got that wrong, lol. But yeah the asymmetric part isn't really used in this context.

I actually built a tool that can do this from camera photos or screenshots. You know, for pentesting purposes :)

https://github.com/cookiengineer/forensics-tools

At least Google lets you export the keys. Authy removed that ability and now Twilio is forever on my shit-list.

I'm just boring and use 1Password for this along with my passwords.

I wish there was a way to export my codes from Microsoft authenticator on iOS. If anyone knows of a way to do this, please feel free to reply. I would like to move to an open source solution.

I also have the same problem, however, I think Microsoft started to use some proprietary protocol wit some challenge / response scheme.

Yes, Microsoft tries to get you to use their proprietary mechanism by default. You need to click on the "use a different method" link when doing the setup to get a code that is compatible with e.g. Google Authenticator, FreeOTP, and all the other ones

The last time I tried to that for an external MS Teams instance, the option to use another method was gone. Could have been a compliance thing of the 'owner' of the instance, however, I actually tried multiple times to circumvent installing their app, but failed.

It's a setting of the app owner. I ran into the same thing. Though I admit a push based 2FA is more resistant to phishing.

Learned that the hard way, never ever add ANYTHING to the Microsoft Authenticator app if you can avoid it. It is impossible to migrate to something else.

I had a client where I got a new phone and forgot about the Microsoft Authenticator. Three months later I had to go on site with the client to reset my Authenticator as signups could only be done from their network.

Keep in mind that perfect is the enemy of good! You don't have to switch all at once. Start adding new tokens to a better manager and see if/when you get around to migrating the ones that are currently locked into Microsoft. That way, the task will get smaller rather than larger over time :)

I've been storing TOTP codes in on my Yubikeys for many years now, it works pretty decently. They have an app for it (https://www.yubico.com/products/yubico-authenticator) which has gotten better over the years. For redundancy I've stored keys on two devices.

Most people don't really know how these TOTP codes work but yeah for the longest time I've just put the plain text secret in a place where I can wrap it with my own golang utility

https://github.com/edify42/otp-codegen

Way easier to open a terminal on my computer and pipe to `pbcopy` and paste it onto the screen.

I did the same for a work code that I have to use multiple times a day - compiled up a standalone binary (with hardcoded TOTP code) using the `otp` crate.

(One nice thing it does is wait for the next number if the expiry is within 5s before outputting the code.)

I’ve been using a Yubikey for TOTP codes for years.

When it’s plugged into my laptop, I use a fuzzy-search UI to pick the right credential, tap the Yubikey, and it writes the TOTP code into the focused text field.

There are iPhone and Android apps to generate codes. On iPhone, it works with nfc.

The same device also works for webauthn and for gpg. It has no network capabilities.

This reminds me of Steve Gibson storing his 2FA seeds by printing them out [1].

> "Steve: So in my drawer I have all of my QR codes printed."

> "Steve: They're in a safe place. And if it ever comes to the point where I need to set up a new authenticator, not a problem. I just scan the QR codes once again, and we're back in business. So the other thing to look for is an authenticator that will allow you to do that because it is nice to have hard copy backup."

---

I'm not sure what TOTP app he's using currently, since this was said 2 years ago [1].

> "Steve: OTP space Auth, and the logo is a simple gray padlock. Very modest logo. And it does all of this correctly."

[1]: https://www.grc.com/sn/sn-921.htm

This is actually an interesting idea.

I have my e.g. GitHub recovery codes printed out. I have to assume that the recovery codes are more flexible, but rescanning the original QR code would be better UX in case of loss simply because GitHub is not involved, they're nevertheless wiser.

But the recovery codes are process agnostic. I imagine they work whether you're using TOTP or any other 2FA mechanic. If GitHub deigns to discontinue support for TOTP, then the printer QR code won't be much help.

In the end, however, I have a piece of paper (or other visual artifact) with security information to manage.

I will keep the persistent QR code concept in my bonnet for potential consideration in the future.

+1. I stopped using google authenticator when they randomly wiped the app for me and lost all the codes.

Liked the 'Written by human not by AI' bagde

I get the feeling. Got a pretty bad experience with google when I migrated phones, and it messed up the data for a pretty important app (no damage, because I'm paranoid and have backups). I keep an offline phone with synced Authenticator because of this.

What is the reasoning that google makes it so complicated to export the TOTPs? Is it just to make it harder to migrate to other authenticators (which does not make much sense because other authenticators just build their tool to import this anyway) or is it just a bad case of "security through obscurity"? I cannot imagine any minimally dedicated attacker that has already put the effort to get the export qr code not being able to actually read it, but it just makes it harder for "common" people to actually get their codes. I remember I had to go through what the article describes to access my TOTPs and migrate to another authenticator.

There was a misguided line of reasoning that if you can back up a digital artifact, it is no longer eligible as a "something you have" type of security credential.

Earlier versions of Google Authenticator did not have any export functionality at all, and the only way to transfer the codes to a new phone was to use a Google backup of the old phone, which is only possible during the initial setup.

I have said time and time again, keep a copy of the QR code (or the text encoded within) before adding it to an authenticator app. You may find out too late that you cannot recover the keys. You can do this by simply taking a photo or screenshot of the QR code and storing it in a safe place.

Even better, avoid any MFA mechanism that relies on short codes with low entropy. Instead you could use U2F which uses a hardware token in which the key material is designed to be extremely difficult to extract, and requires physical access to the device to even attempt.

This is the nice thing about keeping it in Keepass XC. The seed is saved as an attribute in the database, you can easily add it to another app if needed.

I love the post. I know this is not the topic: There is a google-auth replacement which has appropiate qr scanning and doesn't require any connection permission, in f-droid. I don't know why freeOTP is more popular since it asks for full network permission.

https://fxedel.gitlab.io/fdroid-website/en/packages/org.shad...

andOTP.

Go for Aegis if you're on Android, 2FA Authenticator (2FAS) or Authenticator (by Matt Rubin) if you're on iOS.

+1 for Aegis. Encrypted backups, easy to import/export multiple formats, and very customizable.

If you use Emacs on GNU-Linux, you can have it run oathtool and copy the code to the clipboard which you can straightaway middle-click-paste.

https://gist.github.com/akssri/92a3b240c89212815a66e86c60eab...

Can I put a recommendation out there for andOTP?

https://github.com/andOTP

* Open source

* Support for encrypted backups

* It allows you to peek at the previous 30 seconds code (so it doesn't just vanish if you're halfway through typing it)

* Lockable via pin or pass etc

* Filterable views

Shameless plug.

I’ve been using a cli tool i had created for over 2 years now, it just works. I had more ideas but never got to incorporate those.

https://github.com/44za12/horcrux

6 years for me if we're counting :)

https://github.com/edify42/otp-codegen

Love the minimalism.

If it has a "Google" label, it's not in your best interests and best avoided. This is just another in a long list of examples and confirmations of this fact.

The solution to most 2FA/TOTP issues (including the one described here) is Stratum. It offers a full array of import and exports features (with or without strong encryption) including the ability to import directly from Google's user-hostile abandon ware.

https://stratumauth.com/

I've been waiting for this for years. I'll put this in a VM for some isolation, and I'll have more security and more convenience.

I actually write down the secret for all my totp codes in a notebook as a backup

I'd be more curious to know what the traffic data google maps alternative is.

He’s asking for one, he does not have one.

I use (Apple) Maps, personally.

Reply on news.ycombinator.com