Live data from Hacker News

De-Googling TOTP Authenticator Codes

imrannazar.com

41–50 of 138 posts

Re: De-Googling TOTP Authenticator Codes

#41
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?

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

Re: De-Googling TOTP Authenticator Codes

#42
post #35
post #22

Earlier quoted context omitted.

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

All of this is true without 2FA, just storing securely generated passwords in the manager. Whether it negates the benefits of 2FA (i.e. whether it's 1FA) doesn't depend on the threat model. The threat model is what makes an individual decide whether 2FA is worth it

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

Re: De-Googling TOTP Authenticator Codes

#43
post #34
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…

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

It is symmetric.

Re: De-Googling TOTP Authenticator Codes

#44

Earlier quoted context omitted.

It’s still one device.

If you login from your phone, it’s still one device. Should we have different totps for different devices? Something that you have can be your own pc.

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

Re: De-Googling TOTP Authenticator Codes

#45
post #24

Earlier quoted context omitted.

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

If you use a password manager, or another mechanism that makes each password unique and unguessable, the password and the "2FA" seed token are both the same type of secret string, and both are stored on the same disk. There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely But I'm not saying you should care about this. Everyone can make their own risk 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.

Re: De-Googling TOTP Authenticator Codes

#46
post #9

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.

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

Re: De-Googling TOTP Authenticator Codes

#47
post #12
post #9

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

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

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

Re: De-Googling TOTP Authenticator Codes

#48
post #24

Earlier quoted context omitted.

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

If you use a password manager, or another mechanism that makes each password unique and unguessable, the password and the "2FA" seed token are both the same type of secret string, and both are stored on the same disk. There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely But I'm not saying you should care about this. Everyone can make their own risk 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 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.

Re: De-Googling TOTP Authenticator Codes

#49
post #42
post #35

Earlier quoted context omitted.

All of this is true without 2FA, just storing securely generated passwords in the manager. Whether it negates the benefits of 2FA (i.e. whether it's 1FA) doesn't depend on the threat model. The threat model is what makes an individual decide whether 2FA is worth it

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

Think about how the attacker gets there:

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

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

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

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

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

Re: De-Googling TOTP Authenticator Codes

#50
post #34
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…

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

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

Post reply on HN