Password History Crazy Bug

Ask the Community Password Manager
,
1

Hi there,

I’ve stumbled upon a crazy bug in the Password History feature (the clickable number at the bottom of an entry, where you can see your past edits to passwords fields)

I’ve been playing with this for the past two hours; trying to pinpoint exactly what the problem is. I can reproduce it 100% of the time; yet I can’t share exactly the JSON to do that. Please, let me explain.

I have created a Secure Note to store ~50 gift card codes. They are in the format:

SECURE NOTE

Field Name: Amount of the Gift Card (e.g. $23.31)
Field Content: Gift Card Code (Format ABC1-ABC1-ABC1)

After loading the Secure Note with all of them and saving; automatically the Password History at the bottom shows “5” and keeps stored there the last 5 fields’ values of the Secure Note; no matter what!

I’ve tried adding a Hidden field below those 5, editing and saving (momentarely it gets added to the Password History list). When I close, open and save the note again; without doing anything else, that new test field dissapears from the Password History list and, again, the last 5 fields are being shown.

As I said, I’ve tried playing with the field titles, removing dashes of the serial, changing field names, etc. and the same behaviour happens. So, I thought, I’m going to create a .json to share with the community. The crazy thing is that, if I replace the real serial numbers with XXXX-XXXX-XXXX, the problem doesn’t manifest any longer! So, I’m guessing, something in those serial numbers are triggering the Password History feature to go crazy; still I don’t know what it is, as there are no extra space, crazy ANSI characters or anything weird in them!

By the way, I’ve tried reducing the fields amount to around 6, and the same thing still happens when using the real serial numbers! The Password History get automatically populated with the last 5

TL;DR: I have this happening in all the clients. I have a .json for a Secure Note with ~50 hidden fields for serial numbers. As soon as I import and save it, 5 Password History items appear at the bottom automatically; stamped all with the same date/time when I created the entry. Without changing anything, every time I open the entry and save it, those 5 fields are kept there and all updated with the new timestamp of the save event.

Hope I made myself clear and that there is a way to troubleshoot this without sharing the real gift card codes :slight_smile:

2

@Timmy256 Welcome to the forum!

You mention “loading” the Secure Note — are you creating these secure note items by importing JSON files? If so, at least for testing purposes, could you check what happens if you manually type in (or copy/paste) 6-7 of these fields into a new (blank) Secure Note item?

The behavior that you are observing is in part due to the following expected functionality:

  • The “Password History” stores not just passwords, but any hidden field (i.e., custom fields of the type “hidden”).
  • The Password History only can only hold the five most recent changes.

To determine whether you have found a bug, we would first have to ask what the expected behavior should be when a vault item contains (given the above constraints) more than five hidden fields. Then we can determine whether your experience differs from that expectation.

Also, your description is a bit unclear on some points, so it would be good if you could share an example. I doubt that there is something special about the values of your gift card serial numbers — more likely, if you changed all 6 gift card codes to XXXX-XXXX-XXXX, the reason that the behavior didn’t manifest was that all 6 codes were identical. Try to be more creative with your fake gift card codes, so that they are all unique, and have an appearance that is similar to the real codes. Here are 6 that I’ve generated using Bitwarden’s password generator:

XMBW-AXWM-RALT
SDGV-PHXL-BAKV
RJKF-NMYY-GPHY
PQTE-SYNY-RPTE
GULX-UZWD-SAQN
NZMR-DCKX-UDRC

(feel free to replace the last letter of each group with a number, but I really don’t think that will matter)

3

For what it’s worth, I was unable to reproduce your issue using the following JSON:

{
  "items": [
    {
      "type": 2,
      "name": "Imported Gift Cards",
      "fields": [
        {
          "name": "$12.34",
          "value": "XMB0-AXW2-RAL3",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "$23.45",
          "value": "SDG2-PHX3-BAK4",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "$34.56",
          "value": "RJK3-NMY4-GPH5",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "$45.67",
          "value": "PQT4-SYN5-RPT6",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "$56.78",
          "value": "GUL5-UZW6-SAQ7",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "$67.89",
          "value": "NZM6-DCK7-UDR8",
          "type": 1,
          "linkedId": null
        }
      ],
      "secureNote": {}
    }
  ]
}

 

Is there anything noticeably different between the above data and yours?

4

Thanks for your quick reply and for the idea of testing this in an easy; manual way. I did and was able to reproduce it!

  1. Create a new Secure Note; call it whatever
  2. Add 3 hidden fields
  3. Enter name for Field 1 (e.g. “$1231.12”); copy the name and paste it in the remaining 2 fields; as title
  4. Enter any random strings for the 3 fields manually (e.g. asdasd-sfdsdfds-sdfsdfds)
  5. Save the entry. Open it again. Save it. Without changing anything, I get 2 items in the Password History section. After I open and save it again (of course, still without changing anything), I get 4 items in the Password History section!

Here it’s a quick GIF video of how, without changing anything, the password history keeps growing! I hope it works:
Test

5

Yes, I see it too.
My first thought is that it is connected to all the fields having the same name. Curious that it works OK with just 2 fields, you seem to need 3 or maybe more. Also field name needs to be at least 2 characters long.

1 Like
6

Thanks for confirming I’m not going crazy! :smiley:

I though about the problem being that some fields have the same name, although I noticed during my .JSON test. import that, even with the fields being the same name, when the serial codes were replaced with XXX, the password history behaved correctly.

7

I guess if all the fields have the same value then the code doesn’t detect a change.

8

OK, I have now been able to reproduce this as well.

I believe this is caused by the following two conditions:

  • At least two hidden fields with the same name.
  • The field value must differ.

If I were to guess the root cause, it would be that Bitwarden includes some code to check whether a hidden item has changed (i.e., it has changed its name or its value) when the item is saved. If it detects a change, then it updates the password history. I believe that this code is getting confused when the above conditions exist.

Edited to add: The root cause seems to be that the database structure for custom fields does not include unique identifier for the fields that are created, so they are identified only by their name & type. The same problem causes the “Updated” timestamp to be erroneously modified by a Edit/Save sequence if two non-hidden text fields have the same name but different values (even when no modifications were made).

In my opinion, this is a bug, and should be reported on GitHub. Good find, @Timmy256!

1 Like
9

Below is a minimal JSON that will reproduce the bug. It is also easiest to reproduce this in the Web Vault, since the Web Vault item view is also an “edit” view. Thus, to reproduce, import the JSON, then open the corresponding secure note in the vault, and then click Save instead of Cancel. Each time this is repeated, the Password History increments by +1.

{
  "items": [
    {
      "type": 2,
      "name": "Test",
      "fields": [
        {
          "name": "1",
          "value": "1",
          "type": 1,
          "linkedId": null
        },
        {
          "name": "1",
          "value": "2",
          "type": 1,
          "linkedId": null
        }
      ],
      "secureNote": {}
    }
  ]
}
10

Thanks @grb for confirming and taking the time to further expand on this!

I was in a haste to type my first post, after hours of being frustratted by messing with this and trying to understand what was going onn, so it might have not been as clear as possible; yet you guys were able to quickly get it!

It makes sense your reasoning; Bitwarden code “thinks” that the field is being modified, because a same-name one exists, with a different value. I’ll try to post this on GitHub. I’m not familiar with how long do they take to fix bugs, so, for now, the workaround might be to add an index to the field name, to make them unique (e.g. “$111.11 (1), $111.11 (2), $111.11 (3)”).

Thanks again!

11

Since it’s not a security vulnerability, it will probably take a while for it to be fixed. Thus, the work-around that you’ve suggested is probably your best bet to deal with this issue in the near term.

The quickest way for Bitwarden to fix this would be to prevent the user from defining two fields of the same type that have the same name. I hope that they don’t go this route, and instead do a proper fix (probably requiring a change to the database structure to add a unique field identifier, which seems like it might be a major pain…).

12

 

FYI, this is now submitted on GitHub, as Issue #5636. Feel free to post your own comments in the discussion section for that issue.

2 Likes