[Aachen]

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)

[ori_b]

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.

[bkettle]

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.

[philistine]

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.

[dngray]

> 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.

[johnisgood]

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

[ori_b]

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

[tim333]

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.

[lokar]

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)

[Marsymars]

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

How so?

[lokar]

You need the fingerprint sensor to unlock it

[Marsymars]

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.

[philipwhiuk]

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

[styanax]

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

[zeta0134]

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?

[styanax]

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. :)

[BuildTheRobots]

> 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.

[magarnicle]

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.

[xethos]

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

[Freak_NL]

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.

[Aachen]

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

[s2l]

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.

[com2kid]

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.

[styanax]

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.

[littlecosmic]

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]

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

[tremon]

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]

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...

[bkettle]

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.

[justincormack]

It is symmetric.

[_Algernon_]

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.

[Aachen]

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)

[smw]

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.

[AstralStorm]

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.

[freehorse]

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]

> [...] 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.

[jorvi]

> 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.

[littlecosmic]

yes, fair points. Thanks for clarifying.

[nerdsniper]

> 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)

[nicoburns]

> 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.

[Marsymars]

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.

[sceptic123]

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]

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...

[nicce]

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]

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]

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.

[unethical_ban]

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.

[fulafel]

> 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]

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

[gear54rus]

> 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.

[sjs382]

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.

[dngray]

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

[aragilar]

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

[Aachen]

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)

[oulipo2]

1Password works well too (Canadian company I think)