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:
- 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)
ori_b · 22m ago
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.
styanax · 4h ago
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.
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?
Freak_NL · 18m ago
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.
styanax · 4h ago
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. :)
Aachen · 3h ago
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
xethos · 3h ago
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
s2l · 3h ago
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.
nicoburns · 22m ago
> 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.
littlecosmic · 4h ago
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.
Aachen · 4h ago
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
jorvi · 1m ago
> 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.
tremon · 4h ago
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.
8cvor6j844qw_d6 · 4h ago
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.
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.
Aachen · 3h ago
> [...] 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.
_Algernon_ · 4h ago
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.
AstralStorm · 27m ago
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.
Aachen · 3h ago
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
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)
littlecosmic · 4h ago
yes, fair points. Thanks for clarifying.
nicce · 4h ago
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.
Aachen · 4h ago
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
nicce · 3h ago
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.
sceptic123 · 1h ago
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.
prism56 · 16m ago
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...
fulafel · 4h ago
> 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.
Aachen · 3h ago
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
unethical_ban · 30m ago
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.
aragilar · 3h ago
But if you log into your phone with the password and TOTP, is that also not 1FA?
Aachen · 3h ago
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)
gear54rus · 4h ago
> 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.
ezst · 4h ago
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.
And this is why Aegis has a working encrypted offline backup.
tigrezno · 4h ago
For years I've managed all my TOTP codes with KeepassXC. Not a single problem, great software.
blackbear_ · 4h ago
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.
StrLght · 4h ago
> 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
Aachen · 4h ago
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
brnt · 4h ago
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.
Aachen · 4h ago
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
brnt · 2h ago
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.
wolvesechoes · 4h ago
You are allowed to have two separate databases, with different passwords. You can even store them on different devices!
speedgoose · 4h ago
It’s still one device.
quchen · 4h ago
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.
speedgoose · 54m ago
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.
AstralStorm · 21m ago
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.
Aachen · 4h ago
> 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)
wolvesechoes · 3h ago
> 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.
Aachen · 3h ago
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
wolvesechoes · 3h ago
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.
alanfranz · 4h ago
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.
Aachen · 4h ago
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
broken-kebab · 3h ago
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.
Aachen · 3h ago
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
broken-kebab · 1h ago
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.
wolvesechoes · 3h ago
If you store two databases on two devices it makes them suddenly one device? What kind of security sorcery is this?
progbits · 4h ago
I can recommend the Aegis app for Android. Works great and has encrypted backups.
0x49d1 · 4h ago
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..
styanax · 4h ago
Replied to another comment with the same recommendation before seeing this, here's the URL for those interested:
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.
promiseofbeans · 4h ago
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.
chaz6 · 2h ago
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.
eek2121 · 4h ago
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.
mrweasel · 4h ago
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.
Aachen · 4h ago
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 :)
riedel · 4h ago
I also have the same problem, however, I think Microsoft started to use some proprietary protocol wit some challenge / response scheme.
Aachen · 4h ago
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
riedel · 3h ago
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.
unethical_ban · 27m ago
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.
8cvor6j844qw_d6 · 3h ago
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."
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.
cookiengineer · 4h ago
I actually built a tool that can do this from camera photos or screenshots. You know, for pentesting purposes :)
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
Way easier to open a terminal on my computer and pipe to `pbcopy` and paste it onto the screen.
zimpenfish · 3h ago
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.)
akssri · 4h ago
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.
Go for Aegis if you're on Android, 2FA Authenticator (2FAS) or Authenticator (by Matt Rubin) if you're on iOS.
bramhaag · 4h ago
+1 for Aegis. Encrypted backups, easy to import/export multiple formats, and very customizable.
theshrike79 · 3h ago
I'm just boring and use 1Password for this along with my passwords.
anonymousiam · 3h ago
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.
radu_floricica · 4h ago
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.
44za12 · 4h ago
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.
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.
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.
[1] https://github.com/beemdevelopment/Aegis
Since totp addition is not a frequent activity, the last manual import step was not a hassle to do whenever needed.
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.
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
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.
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...
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.
Most sites require 2FA for changing the password, but do not require the password for changing itself.
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)
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
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.
The argument can me made that logging into something on your phone isn't 2FA either then...
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
Do I still get the security of TOTP as a rotating component of my password to prevent breakins from stolen credentials? Yes.
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.
- 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
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
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
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.
But if its on the same device, it will not protect you against a password database harvester.
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)
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.
Something that you have can be your own pc.
https://github.com/beemdevelopment/Aegis
They also have a good Google Photos alternative, which is how they make money.
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.
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.
> "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
https://github.com/cookiengineer/forensics-tools
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.)
https://gist.github.com/akssri/92a3b240c89212815a66e86c60eab...
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
https://github.com/edify42/otp-codegen
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 use (Apple) Maps, personally.