Report says an account password has been reused 3 times, however, the current password is a random 20 character PW generated by bitwarden, so there is zero chance it could be reused 3 times. What is this report actually telling me? I have another account with a 22 character random generated password (with a password history of 1 and it too was equally cryptic - no chance it could have been used for a different account) but it too says its been reused 3 times as well. Makes no sense to me.
Hey @Blue_Sky_58
Could it be that the reused report is showing you a duplicate entry that is perhaps in your trash? I found a similar post here where a user had a similar issue.
Otherwise regarding your question
This is the information I found in the help article,
The Reused Passwords report identifies non-unique passwords in your vault. Reusing the same password for multiple services can allow hackers to easily gain access to more of your online accounts when one service is breached.
Once identified, you should create a unique password for offending accounts or services.
Presumably this checks in your local vault for entries that exist that have duplicate entries in the password field.
I.E if you have an entry that shows it has been reused 3 times, then you will most likely have all three separate logins show in the report that the password has been reused 3 times. Each of the three corresponding entries in the report will show the password reused 3 times, and you can check the logins to verify that they might be duplicate entries.
there were a few trashed passwords from the two accounts I mentioned…I deleted them all from trash…report still shows them reused 3 times.
Not sure I understand your answer. My expectation is this…if I have a password that shows up as reused (somewhere in any other account), I go in and change it to something very unique, then rerun the report and it should disappear, but thats not happening. I’ve changed many passwords over time since running the report many months ago, but I think many of those accounts are still showing as reused despite the changes I’ve made over time.
do you mean the account (login/website/password) is in the report 3 times?
That should be correct, as I have checked if you create a login with a password even randomly generated and save this login.
It can them be cloned to make sure the login password is duplicated, this shows in the reused passwords report in the web-vault.
If you have three entries that all contain the same password, then all three logins will show in the reused password report and report that the password has been reused 3 times.
Once the password is changed in the login to another generated one this should now no longer show on the reused password report, and now the other two remaining logins with the same password would show in the reused password now being reused 2 times in my testing.
I don’t understand. Lets say I have an account with American Airlines ( I do). One account only. This online account has a 20 char unique password that no other account in my vault shares. No clones of the account. No duplicates of the account. Just the one. But , which he report is showing the password is reused 3 times. What this SHOULD be telling me is that same password I’m using for American is ALSO being used for thee other online accounts (which is impossible due to its length and random mix of charaters, letters, symbols). Remember… I only have ONE American Airlines account in my vault. My wife has an AA account and it too shows reused passwords even though her password is entirely different than mine, and also with no clones, duplicates, etc. All the references to account clones and duplicates and whatever is only confusing the matter.
If I can offer a suggestion here, you might try creating an unencrypted export of your vault contents and then searching through the passwords to see how many instances of that password appear in the search. From what you have said, it should only appear once. If it does, then that would definitively prove there is a bug in the report generation algorithm. On the other hand, you might end up determining that some duplicates did get inadvertently created , in which case it would be valuable to locate them and fix the problem.
One word of caution - you definitely want to save that unencrypted export file directly to secure location, such as a drive with full-disk encryption or an encrypted flash drive. Failing that, save it to a mechanical hard drive and use secure delete to get rid of it (not so easy to do on an SSD). Cheers!
Good suggestion David - I’ll do that today and check it carefully and report back.
OK, so here’s what I did:
1 - exported vault as csv file.
2 - Sorted data using the password column so i could easily scan and fine duplicate passwords
3- looked up some of the accounts that showed reused passwords, and compared that to the account in the data file to see if any other accounts are duplicated OR if an use the same password
results:
1 - No duplicate or cloned accounts (having the same data)
2 - No accounts with an identical password used by another account
So I’m left wondering if BW is including past passwords (as showing in password history for an account) and including those. For some of the accounts that show reused - they have HAD A COMMONLY USED password IN THE PAST BUT NOT PRESENTLY. If this is correct, IMO the report is misleading. Why would I care about a password I commonly used years ago but long-since changed to a hard password now?
Very interesting @Blue_Sky_58 - thanks for trying that.
II would say that if the report does draw on expired passwords or trashed login credentials, then that’s a bug. I encourage you to fill out a bug report for the devs. You can reach it by clicking BUGS in the blue menu bar at the top of the forum’s home page.
Then go where? I’m not familiar with this Github format or options.
If it’s a valid bug, that entitles me to a free lifetime premium subscription, right?
Another possibility I checked is that within an account “record,” there are custom fields that I often find contain old, retired passwords - not sure why these are added - I just assumed when I changed a password the record would only contain THAT password only, not add a custom password field with the old one, but anyway…
However, when i looked into this further some of the accounts that say the password is reused do not have any old passwords sitting in the custom field, si that does not appear to be a possible cause.
To my knowledge, Bitwarden never creates custom fields and puts old passwords in there. Custom fields aren’t automatically generated at all.
Actually - i checked many random entries in BW this morning and many (not all, but many) of them had two things entered into custom fields, my username and existing (or previous) password. I know for a fact I did not manually create and add these as custom fields, so it’s happening in some automatic fashion.
The other evidence this is the case - when I go to log into some sites, my credentials are sometimes rejected. I couldn’t figure out why but then concluded that the old password (that got added as a custom field) is auto-filling into the site, thus the rejection. I end up having to manually delete it in the BW record to get it to work correctly.
So to conclude, yes, my logon and password info is being added as custom fields in many BW entries.
Out of curiosity, were these login items that had the unexpected username and previous passwords in the custom fields items that you created from scratch in Bitwarden, or is there a chance these login items were imported from either a backup or from some other password manager?
I have not done an import from a BW backup. I might have done an import from Roboform but that would have been many years ago as I’ve been using BW for quite some time. I don’t recall exactly but I’m sure at least some of these entries were created from scratch over time. I suppose that it could have occured during the original import process, huh? Is there any way to “batch fix” that?
It just really odd. What will happen sometimes is I go to log into a site, and my credentials will be rejected. I’ve learned that my next step is to check the BW record and see if there is a custom field titles PASSWORD with what is usually an old password - often times there is. I delete it and retry and it usually works after that modification is made.
Yes, that’s really weird behaviour. It definitely sounds bug-like, yet I don’t recall anyone reporting this behaviour before, so hard to say exactly what is going on.
I don’t know of a way to batch process your login items to remove the custom fields, unfortunately. The safest way to approach this would be to sort that CSV file you exported on the custom fields so that the records containing custom fields sort to the top - at least then it would be a bit easier to find them in your vault and manually remove them.
I guess thats my best option for the custom field issue - now if I can just get the reused passwords report to be accurate…