Keepassxc: Warning if using TOTP because of 2FA to 1FA change

Created on 5 Aug 2017  路  10Comments  路  Source: keepassxreboot/keepassxc

There should be a strong Warning if using TOTP in keepassxc.

Because if the main password and the time-based one-time password are stored in the same encrypted database and/or are provided from the same program, this reduces the 2FA to a little bit more advanced single factor authentication.

Expected Behavior

If a user adds TOTP informations, there is a warning dialog informing the user that adding TOTP if the password is stored in keepassxc as well, is a security risk and degrades 2FA to a single factor.

Current Behavior

The user is not aware, that adding TOTP besides the password in the same database changes the security from 2FA to a single factor.

documentation TOTP security

Most helpful comment

I do not necessarily agree with this, its more like 1.5FA. The main point of 2FA is that an attacker cannot log into your account simply by using a stolen password. Recently, all these stolen passwords are from hacks on large commercial databases being provided to the public. If an attacker has access to your main password database, they likely have access to your TOTP database as well. You likely store your backup codes in the main password database even if you don't use it for TOTP.

All 10 comments

I agree 馃憤

Even though most users will probably just store their TOTP codes in the same database, we should add a warning/advice for them to store the TOTP keys in a different database and open it at a second tab along with the main database to maintain the 2FA.

I do not necessarily agree with this, its more like 1.5FA. The main point of 2FA is that an attacker cannot log into your account simply by using a stolen password. Recently, all these stolen passwords are from hacks on large commercial databases being provided to the public. If an attacker has access to your main password database, they likely have access to your TOTP database as well. You likely store your backup codes in the main password database even if you don't use it for TOTP.

"changes the security from 2FA to a single factor" is not neccessarily true. It very much depends on your threat model.

For most people that model will not include "stole and decrypted my password store". For them it will be

  • logged in to gmail at some sketchy internet cafe
  • friend of mine looked over my shoulder while I typed
  • someone got lucky brute-forcing my password
  • password was revealed by some large database breach; perhaps in combination with bad password storage on their part (think: Adobe Users Database)

In all those cases, you're still orders of magnitude better off with TOTP.

(edit: fixed a typo in "thread model" -> "threat model")

(in short: Yes, put it in the documentation. No don't put a "strong warning" in the program)

All the points (internet caf茅, spying over the shoulder, server breach) don't need 2FA to be mitigated. It would be enough to replace the one factor password with a other single factor TOTP.
So use TOTP instead of the password. It is generated by the server which solves the password reuse problem and it is hardened against replay attacks.
It is better then a password but it is still a single factor.

2FA is only necessary, if your device generating the TOTP is compromised.
Therefore is it a bad idea to store TOTP secret/generator and password on the same device. And a relay bead idea to use the same software if you want 2FA.

In theory you _may_ be correct (which I'm not entirely convinced of) but I can't set the proposed TOTP-only for BitBucket, GitHub, Mastodon, Dropbox, Facebook, GitLab, Kickstarter or Slack.

For all of those I _can_ set Password + TOTP. And This makes my account harder to be taken over in the exect scenarios I described. And it makes them harder to take over even though I store the TOTP-Tokens in the same KeePass-Database as the account's password.

So, again, in practise it is _still_ good to have Password + TOTP, even if it's stored in the same place and may (disputed!) be reduced to less than 2FA.

And also, I really think we need _more_ people using 2FA. Not less. Having this huge warning will result in less people giving it a try in the first place.

Maybe we're discussing entirely different usage scenarios? In that case: the services mentioned above are the ones that I currently use TOTP for. If you use (or plan to use) them in some other way, I'd like to learn about it!

I don't say it is general bad to put TOTP data into keepassxc.
If it is for you personal accounts and you don't have unfiltered rights access with this accounts to big projects with thousands of users. I don't see a problem at all.

Therefore I don't say the feature should be removed. It is for sure better to use both in the same database then only to use a password.

But most users are no security experts and therefore aren't aware that storing the TOTP and password in the same place removes a good part of the security of 2FA.

And if the TOTP allows someone to update a chrome extension with 100000+ installations or remote access to a cooperate server. It is a bead idea to store password an TOTP on the same device.
Because it makes target attacks much easer.

But you can't expect from a developer/employee to know this. If they use a security software like keepassxc, they assume that the developer of keepassxc takes care of the security. And if they include a feature that it is secure.

Therefore if you include in a security software, features which can reduce the security there should be a warning. To let the user know that this is a security/usability trade of.

This is indeed a scenario that I did not anticipate.

I can get behind something along the lines of

For maximum security, it is best to store your TOTP-Token seperate from your password

But it is very important that the warning does not scare people Off from TOTP in general. So whatever the final message will be, it should be chosen very carefully.

You still get the benefit of "one-time pad" when using TOTP even though it is no longer 2FA. e.g. replay attacks would be prevented.

Also 2FA is more commonly defeated when people put their password database on their phone.

Was this page helpful?
0 / 5 - 0 ratings