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?
De-Googling TOTP Authenticator Codes
41–50 of 138 posts
Re: De-Googling TOTP Authenticator Codes
#42Earlier 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
Re: De-Googling TOTP Authenticator Codes
#43Earlier 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…
Re: De-Googling TOTP Authenticator Codes
#44Earlier 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.
Re: De-Googling TOTP Authenticator Codes
#45Earlier 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…
Re: De-Googling TOTP Authenticator Codes
#46I 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.
Re: De-Googling TOTP Authenticator Codes
#47I 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.
Re: De-Googling TOTP Authenticator Codes
#48Earlier 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 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
#49Earlier 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.
- "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
#50Earlier 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…
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...