De-Googling TOTP Authenticator Codes(imrannazar.com) |
De-Googling TOTP Authenticator Codes(imrannazar.com) |
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.
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)
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.
Not quite, there's a lot more sandboxing on phones than what might go on with desktop.
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
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)
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.
The argument can me made that logging into something on your phone isn't 2FA either then...
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.
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
Do I still get the security of TOTP as a rotating component of my password to prevent breakins from stolen credentials? Yes.
In estabilished terminology you don't need multiple independent devices. For example email "magic link" is a common second factor.
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
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.
You're conflating "factors" and devices.
- 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.
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
They also have a good Google Photos alternative, which is how they make money.
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.
guess they cannot wait for passkeys to tie you to one apple or google account.
> // 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"
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/
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.
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.
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.
(One nice thing it does is wait for the next number if the expiry is within 5s before outputting the code.)
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.
> "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."
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.
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.
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.
https://fxedel.gitlab.io/fdroid-website/en/packages/org.shad...
andOTP.
https://gist.github.com/akssri/92a3b240c89212815a66e86c60eab...
* 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
It’s Microsoft that’s stuck in unsafe grounds, and it’s partly the cultural apathy of their user base that’s at fault.
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.
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
- "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
How so?
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.
Amazingly, I'd never even considered this as a possibility. Thank you for the paradigm shift.
Aegis also works very well on Android Go dumb-ish phones.
Since totp addition is not a frequent activity, the last manual import step was not a hassle to do whenever needed.
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 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)
Something that you have can be your own pc.
But if its on the same device, it will not protect you against a password database harvester.
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.
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...
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.
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
or
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)
Most sites require 2FA for changing the password, but do not require the password for changing itself.
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.
... 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.
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.
The only necessity is logical necessity, and it doesn't apply there.
> The second factor does not have to be a second device.
Now, you are talking about two pieces of information in single file.