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.
De-Googling TOTP Authenticator Codes
71–80 of 138 posts
Re: De-Googling TOTP Authenticator Codes
#72Earlier quoted context omitted.
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.
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…
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.
Re: De-Googling TOTP Authenticator Codes
#73Earlier quoted context omitted.
> 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
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.
Re: De-Googling TOTP Authenticator Codes
#74Earlier quoted context omitted.
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" T…
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.
Re: De-Googling TOTP Authenticator Codes
#75Re: De-Googling TOTP Authenticator Codes
#76I 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.
Re: De-Googling TOTP Authenticator Codes
#77For years I've managed all my TOTP codes with KeepassXC. Not a single problem, great software.
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.
Re: De-Googling TOTP Authenticator Codes
#78If 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.
Re: De-Googling TOTP Authenticator Codes
#79To 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…
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.
Re: De-Googling TOTP Authenticator Codes
#80Earlier quoted context omitted.
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.
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
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.