Implement History for Authenticator Key (TOTP)

Feature name

  • Implement History for Authenticator Key (TOTP)

Feature function

  • Currently the Authenticator Key (TOTP) field does not have a history which could lead to being locked out of an account if it is inadvertently modified or a mistake is made while editing. This critical field should have a history like the password field.
1 Like

I have never had the need to modify a totp token. Why would you?

Hopefully you never do. But what if you accidentally make an edit?

Then I have my external backup of the vault. Easy peasy.

Great, then you probably don’t need the password history feature either. But some people do, and it could prevent them from being locked out of their accounts.

1 Like

This is useful. Don’t listen to those being pedantic

4 years later.

Has this feature been added?

@MetBril here’s the scenario for you:

You manage 10+ different twitter/Facebook/etc… social accounts for your company. I’m talking 10+ accounts for the same website.

One day you’re trying to make sure that each account has 2FA enabled. While doing some account cleanup, you accidentally copy/paste a password into the TOTP field using the chrome browser extension.

The password field and the TOTP field are exactly next to one another, and the info in the field both look like this:

Password: 982374ioewarfgoijnaweiogfj892034589321
TOTP: kalsdfkjl2891277408245t89iofajioqwjaef23i4oj

Having updated this information ten thousand times, your eyes glaze over, and you’re not quite as careful as you should be. You end up copy/pasting an updated password into a TOTP field.

You save.

POOF

Gone.

Doesn’t take much creative thinking to imagine how this might happen.

The elitist technical types who think “this will never be a problem for me, therefore it will never be a problem for anyone else” are obnoxiously small-minded, obtuse, and often lazy in their thinking.

This feature needs to be implemented.

Regarding the “I have an external backup” point.

Yeah, I’ve got one. 99% of people probably don’t.

But my backup is encrypted, so it will take me importing it back into bitwarden to unencrypt it, and that opens up another whole fun set of problems.

I’d probably need to backup/export my current bitwarden library first, then delete everything in my account, then import this old backup. (emphasis on old), then get the old TOTP seed. THEN delete the whole thing again and re-import my current passwords.

All for ONE TOTP seed!

That’s best case scenario, assuming that 1. I have a backup. 2. I know how to use it/I have the encryption key to even re-import it.

Am I missing something?

Please build a TOTP changelog!

1 Like

I have a few tricks to help you here.

  1. Create a temporary bitwarden account into which you restore the backup. This way you do not risk messing up your real vault.

  2. KeepassXC is now capable of importing password-protected bitwarden exports.

  3. BitwardenDecrypt will decrypt a password protected export. Do note that it has not been updated in a couple of years and was written by a 3rd party.

  4. Use unencrypted backups.

Also, the risk of a data entry error is not just limited to TOTP; it can happen anywhere. Perhaps consider instead voting for this FR

1 Like

which can be done by backing up to a separately encrypted file or volume, so nothing is lost in security but independent accessibility is retained (no import needed). If your OS does not natively support this, there should still be tools available for it.

@DenBesten Thanks so much for the reply.

I went the KeepassXC route and it worked like a charm.

Note to anyone having a problem getting KeepassXC to open your file and seeing this error:

Error while reading the database: Not a KeePass database.

Click “import file” rather than “open database”.

The file import specifically gives you the option to select your Bitwarden file.

1 Like

I just did exactly that: accidentally pasted a new password into the TOTP field instead of the password field. Now I am locked out! Ironicially I did this for a customer’s Bitwarden account, so we are locked out of the admin for that company. If TOTP had a History feature then this would be a quick fix!

Sorry, maybe I’m dumb at the moment… But if you are already locked out (Sorry to hear BTW), how would TOTP history be a quick fix then? :thinking: (in my mind, there should always be a backup for any TOTP seed - and a storage of the 2FA-recovery code - both things would have prevented your situation… though I don’t know if this is an enterprise account and it works differently with the 2FA-recovery code)

Take a step back:
I have my own BW account. But I as an IT admin have access to the Owner account of several companies BW. My personal BW stores the Owner credentials for those company logons. I can get into my own BW fine, and it is there in my own BW account that I pasted the password into the TOTP box.

If TOTP had history, one could simply roll back to the prior TOTP code and get in. My actual TOTP code hasn’t changed on the server end, I just (dumbly) changed it in my BW client and so my client is now generating invalid TOTP codes.

Okay… I understand that. And I don’t want to play a “blame game” - but I guess, a TOTP seed should never be in one place only, be it in a Bitwarden vault or any TOTP app for mobile phones, because that is never a good idea… :wink:

Well thankfully it wasn’t only in one place. Turns out that KeyboardMaestro keeps a Clipboard History and I was able to use that to locate the 2-factor string from several hours ago… so I was actually able to get back in!

First thing we did: set Trusted Emergency Contacts.

Hopefully shortly followed by creating emergency sheets for you and your customers that include the MFA recovery code. And then implementing a periodic backup/export process for both you and your client’s vaults that follows the 3-2-1 strategy.

2 Likes