Either one of the two JSON exports will contain more data than the CSV export. If you are going to copy or move the file before uploading it into the Bitwarden importer, then I would highly recommend working with the password-protected JSON instead of the unencrypted JSON. If the files already exist and are going to remain at rest when you do the import, then it doesn’t matter which of the two JSON files that you import.
1 Like
Is there anyway to get history back? The issue I have is I was in the process of changing all of my passwords from LastPass when this happens and it doesn’t appear that any of that history transferred over. I know it isn’t the end of the world but certainly doesn’t make life easier for me.
Password histories and modifications time stamps are unfortunately not included in the exports, but you can still view them by opening your backed-up local vault in off-line mode (as you had done when you created the exports, in your post above).
Just a reminder that if anyone needs to connect with the official support team, you can do so here: https://bitwarden.com/contact/
Do we have a possible idea yet as to what maybe causing this yet?
I provided as much info on what happened with me and then the next response was asking me to join some chat room to chat with them about it. I haven’t as of yet. Thankfully I’ve recovered my vault and have pretty much moved on… it doesn’t seem like they have any clue what happened at least in my instance or anyway to restore an old vault so make sure you back up your vaults regularly which I’ve never done before.
In your instance, they at least do have the means to verify whether your stored master password hash was changed, or whether the master password is unchanged but there is some other obstacle blocking your login attempts. If a bug is the cause of this misadventure, doing the hash check could uncover that fact. Beyond the two hash values that you already emailed them, this shouldn’t require any further intervention on your part (other than delaying the account deletion until the hash values have been checked), so I’m not sure why the chat invitation was necessary.
@bw-admin Can you check with the team whether they have performed the hash checks, and whether it yielded any useful information? After a week of troubleshooting by the community, if would be a disappointment if the whole matter was dropped with no new information gained.
FYI to all…I sent another e-mail today and I got the following reply… I asked about joining Gitter and also mentioned that I was connected to my Home VPN when this occurred which I forgot to mention to them originally just in case that might bring up some additional possibilities.
We would just like to have real-time conversation with someone experiencing this unusual issue. We’ve had a few similar reports, but as of yet we have been unable to reproduce the issue ourselves. We’re hoping to sit with someone who is experiencing this issue and basically say “try this. Hmmm, ok, now try this”
If you have any questions or concerns about Gitter, let me know.
At this point, we do not have a clear understanding of the underlying problem, so I cannot say with certainty whether we can recover the data or not that was stored in the Bitwarden Vault. We are still investigating the issue, and we’re hoping you can help us further our investigation.
We have investigated the hashes you provided us, but unfortunately that did not seem to lead to any solutions for this issue.
Well this is a start.
@BostonPete Can you write back and ask them point blank: “Did either of the two hashes match the stored Master Password Hash (after the server-side PBKDF2-SHA256 iterations were applied), and if so, which one?”
They can probably not reveal this result publicly, but I see no reason why they shouldn’t be able to provide the answer of that question directly to you, especially if you are communicating to them using the email associated with your (original) Bitwarden account.
Good point, I asked them specifically for that info and I will see if they respond and what it is.
1 Like
This is what I asked…
Did either of the two hashes match the stored Master Password Hash (after the server-side PBKDF2-SHA256 iterations were applied), and if so, which one?”
This was their response…
The hashing process is a little complex, but in a nutshell, the hashed values you provided were determined to not be relevant in this investigation.
While we can never be 100% sure, based on what you have described, we are also currently assuming that you were entering your password correctly.
Thanks for sharing their response, which is disappointing:
This means either:
- The person who is responding to you does not fully understand the hashing process (e.g., first-tier tech support).
- The implementation of the server-side hashing is not as described in their whitepaper.
- The random salt used for server-side hashing is not accessible to anybody involved in the investigation (which seems unlikely, since salts are not secret).
There would be no other scenario I can envision under which it would make sense to respond that the hashes “were determined to not be relevant”. Based on the authentication scheme documented in the whitepaper, the hashes are highly relevant, because they can be used to verify definitively whether the master password hash stored in the cloud database was altered when you updated your KDF iterations. It is also not accurate for them to say that “we can never be 100% sure…that you were entering your password correctly”, because we can in fact be 100% sure of this, if it turns out that one of the two supplied Master Password Hash values is a match.
If I were you, I would respond as follows:
“I am being assisted by knowledgeable users in the community forum, who cannot make sense of your ‘nutshell’ explanation. Would you mind instead providing a detailed explanation for why you cannot perform the server-side PBKDF2-SHA256 hashing of the two supplied Master Password Hash values and compare these results against the MasterPassword stored in the user table?”
3 Likes
@BostonPete the team requires additional information to investigate, please continue to work with them directly as the forum is mainly a community supported space.
@bw-admin Do you understand our/my confusion about the claim that the supplied master password hashes are “not relevant” (and likewise, about the claim that it is impossible to “be 100% sure” that @BostonPete was entering the correct master password)?
If this is explained by the 2nd or 3rd scenario postulated in my post above, I would like to know about it, because it will affect advice and information that I give to users on the forum and other social media.
Hey @grb please remember that this is not an official support space, so the OP needs to follow up with the ticket so that our team can track, assess and report, this thread is still open, there is just nothing to share at this time as the team needs more info from the OP through an official ticket.
@bw-admin I’m trying to be mindful of that, but independent of this particular ticket, I would like to know if there are substantive omissions in the whitepaper’s description of the authentication scheme used when logging in to Bitwarden (which is the conclusion I must draw based on the fact that the tech support team was unable to use the master password hash values that had been supplied by OP).
@grb So BW Support replied back to me saying that the Hashes that I send do not match what they have but also asked me to confirm how I obtained them so I replied back that I obtained them off their page and not locally.
Also they asked me to try and log in to the Web Vault and check the web page / site response values to confirm what iterations is being sent over and what the password hash is in the browser response and sure enough the password hash matches the one that I generated off of their site for the 600k iterations but still get the log in error. I thought that the iterations being generated on the Crypto Page would be different?
Anyway I tried it on two different browsers and I got the same result from both of them which I thought was interesting to say the least. So this seem to prove that I did not forget my Master Password and that something else went wrong?
@BostonPete This is interesting information, but to make sure I understand what is going on (and to allow me to experiment), would you mind explaining what method you used to “check the web page / site response values”, and to check “the browser response”?
Of course this is what they asked me to…
Could you open your browser DevTools and check the Network tab when logging in? You should see two requests, listed below. What I would ask is if you could confirm a few fields on those requests.
-
A POST request to https://vault.bitwarden.com/identity/accounts/prelogin
-
Please confirm the KDF iterations in the Response (kdfIterations) from this call matches what you expect (600000)
-
A POST request to https://vault.bitwarden.com/identity/connect/token
-
Please check the password field on the Payload tab and confirm that it matches one of the hashes that you sent us previously. If it does, please tell us which one. If not, please tell us what that hash is.