Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

De-Googling TOTP Authenticator Codes

imrannazar.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: De-Googling TOTP Authenticator Codes

#61

Post by Aachen »

zeta0134 wrote: post #37
styanax wrote: post #29

Earlier quoted context omitted.

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?

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

Re: De-Googling TOTP Authenticator Codes

#62

Post by wolvesechoes »

Aachen wrote: post #39
quchen wrote: post #26

Earlier quoted context omitted.

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…

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

Re: De-Googling TOTP Authenticator Codes

#63

Post by Aachen »

freehorse wrote: post #48
Aachen wrote: post #24

Earlier quoted context omitted.

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 assessm…

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…

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

Re: De-Googling TOTP Authenticator Codes

#64

Post by zimpenfish »

tedk-42 wrote: post #52

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

Re: De-Googling TOTP Authenticator Codes

#65

Post by Aachen »

fulafel wrote: post #38
Aachen wrote: post #13

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 calle…

> 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

Re: De-Googling TOTP Authenticator Codes

#67

Post by aragilar »

Aachen wrote: post #13

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 calle…

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

Re: De-Googling TOTP Authenticator Codes

#68

Post by Aachen »

_Algernon_ wrote: post #45
Aachen wrote: post #24

Earlier quoted context omitted.

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 assessm…

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

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)

Re: De-Googling TOTP Authenticator Codes

#69

Post by Aachen »

aragilar wrote: post #67
Aachen wrote: post #13

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 calle…

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)

Re: De-Googling TOTP Authenticator Codes

#70

Post by Aachen »

wolvesechoes wrote: post #62
Aachen wrote: post #39

Earlier quoted context omitted.

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

> 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
Post reply on HN