Possible way for attackers to grab your master password?

I’m just looking at setting up with Bitwarden, however I’m somewhat concerned over the possibility of the master password being compromised if the BitWarden server was compromised:

It appears that at the moment, the only way to change your Bitwarden master password is to log in through the web vault and do it through there - my concern though is that if the Bitwarden server has been compromised. (Not too likely I would hope, but it’s a nice juicy target for hackers and we shouldn’t have to rely on the Bitwarden servers to not be hacked)

I’m assuming that the web vault works in such a way that it uses client side Javascript to encrypt/hash the password so that the password itself is never sent to the Bitwarden server. That’s all very well and good, except that you’re still relying on the Javascript code being trustworthy - and for that to be the case, you have to trust that the Bitwarden server hasn’t been compromised. If the Bitwarden server were to be compromised, there’s nothing (that I can think of) which would prevent the hacker from modifying the Javascript that is sent to the client so that it sends a copy of the password off to some other server under the control of the hacker.

Maybe I’m just being overly paranoid, but I think that it pays to be paranoid when it comes to securing all of your password in a single location.

Thoughts?

3 Likes

Hi markg, welcome to the BW community!

I’m with you on being paranoid, specially for such an important ressource that is password manager. You’re raising a point, that’s for sure.

Being no export at this, I’m wondering.
Let’s imagine a fraudulent fake login page grabbing my password, replying “oops, please try again” then sending me to the real login page without me noticing anything and simply presuming I made a typo and now successfully logging into the real website.
Now what?
The hacker has my credentials, but they are sort of useless without my 2FA.

Now that I’m logged into my vault, I can confirm I’m on the real site since I recognise my stuff is here. From there I can’t imagine a hacker being inside the vault and grabbing my new password if I change it. Am I wrong?

I’m aware I’m not providing much help here but at least this is educational to both (hopefully) of us.

Cheers.

No. OP said the hacker has broken the Bitwarden site, so 2FA is useless. They already have all the encrypted data, so all they need is your password. (2FA has nothing to do with encryption, only for telling the server whether you are trustworthy of sending the encrypted data)

If it was just a normal phishing site, you would be right. But OP is saying “What if they broke into the Bitwarden servers” (meaning they can serve malicious JavaScript FROM THE BITWARDEN WEBSITE SINCE THEY CONTROL IT. and they also have all the encrypted data and just need your password)

Hi @dabura667, thanks for your reply.
You’re right, I derailed from the original post.

At that point, we’re all screwed I guess.
What’s you take on that?

  1. Self-hosting is a possibility. But to be honest, I think most hobbyist tinkerer types probably won’t secure their server better than Bitwarden. (Though they will have the advantage of being unknown to hackers… I’m sure Bitwarden’s servers have a big target on them because breaking them would gain a lot, whereas some guy’s private hosted Bitwarden is a smaller target, and as long as that guy doesn’t go screaming about it, they probably won’t even know where it is (IP or URL) to try and hack it.)
  2. Build any of the apps (chrome, desktop, android etc) by yourself and only use that. Then you will never download any javascript from Bitwarden’s server, and therefore you will still only send the hackers your HASHED master password.

A malicious Javascript replacement attack would only affect people who log in using a browser, not anyone using a browser plugin, or an app of some kind.

1 Like

Thanks to you both for your replies.

Since no one had responded as of about 24 hours ago, I sent a message directly to Bitwarden to ask the same question and I’ve received the following response:

Hi Mark,

We appreciate your concern and thank you for your interest in Bitwarden, I am happy to help. Yes, at this time there is a level of trust and confidence you are giving to Bitwarden that the javascript has not been tampered with. The javascript can be considered a possible attack vector. We are working to make more functions available in the client apps (like password change) so that users can choose not to use the Web Vault if that is a concern.

Please let us know if there is anything else we can help with.

Regards,
[Name Removed]

I’ve replied to ask if they have a timeline for adding in this functionality to the client.

Until that time, we’re left with the option of either hoping that the server hasn’t been compromised (which defeats the purpose of encrypting all of the data on the client side) or never change the master password (assuming that when creating an account with the client, it doesn’t use any Javascript fetched from the server)

To me, this is a pretty major flaw (security is never stronger than the weakest link) so it casts doubt in my mind as to how well everything else has been implemented - I’m going to move on and look at other options for password managers.

1 Like

Wouldn’t 2 Step Login prevent them from accessing the data? I haven’t set it up but after reading your post I guess I will.

Unfortunately, no - 2FA would add no level of protection if the server was compromised.

2 Likes

If the server of a password manager was compromised, this could certainly be very bad for the users of this password manager. But wouldn’t it be the same for any other password manager ? Why would it be worst with Bitwarden ? When one gains the control of the server of a password manager, I guess that he has then a great number of possibilities to obtain the passwords, even if I don’t know how because I’m not a specialist.

I would say, there is always a risk, when using a password manager.

@markg, thanks for the insight.

@dabura667 raise a great point regarding self-hosting. I’ve always seen myself as not skilled enough to properly secure a server, so never considered it. But you’re right, that would make for a way less attractive target.

There is always a tradeoff to be made between security and convenience I guess. I might store passwords in text files on an encrypted disk image and sync this image across machines using Resilio or Syncthing. That would be pretty secure. But unusable on a mobile device.

There are server-less solutions (Enpass.io comes to mind). But without access to at least one of my device, I’d be stuck.

The workaround I can see is I could store my encrypted database on say Dropbox, and in case I don’t have access to any of my devices, borrow computer from a friend, log in to Dropbox, download my database, install Enpass and work from there. Again, not so convenient, but usable.

The ability to share password in a collaborative team is what first brought me to BW. Enpass didn’t offer that at the time but they made some progress on that front since then. Enpass isn’t open source though.

Nothing is perfect.

Yes, I think that this would be an unavoidable issue for any service that provides a way to log into an account via a web interface.

If a service is fully functional without using the web interface (and Bitwarden isn’t since you can’t change your master password through the client app) then an educated user can simply never use the web interface and at least in theory, (provided that the client app is correctly written without backdoors, etc) there is no reason to be worried as to whether the web server has been compromised.

I am concerned the problem is worse than anyone posting here has realized.

First:

It’s a bit worse for me. I created my account and (before entering key passwords) realized this was a flaw and so if I want a password that I know hasn’t been compromised, I have to create a new account. I created one assuming I’d change it when I was sure I’d be using BitWarden.

Secondly, and more importantly:
Our browsers accept HTTPS certificates that are signed by ANY of dozens of root CAs (Certificate Authorities). From time to time, a CA messes up or is forced to issue a cert for an entity that already has a valid cert from another CA. Both have happened, on several occasions.

So I guessed a MITM attack would allow anyone to grab my BitWarden master password too. There are hurdles to prevent this, like CAA (Certificate Authority Authorization) but under 9% of sites support it.

dig +short bitwarden.com CAA shows BitWarden does support it. Whew! Unfortunate to see that this shortcoming still hasn’t been addressed.

Thirdly, and most importantly: This javascript vulnerability means that BitWarden is vulnerable to government-mandated, e.g. NSL (National Security Letter) attack. BitWarden could be ordered to serve a particular user or IP or nation with a compromised version of the javascript at any time. The clients, by contrast are open source and signed and relatively stable, so one can assume that if they ever weren’t properly built and signed and static, someone would notice and hopefully the media would report on it.

PS. Seriously? “Importing data to Bitwarden can only be done from the Web Vault.”

PPS. Good news. The documentation is wrong. The new CLI has bw import.

PPPS. Bad news. In order to enable 2FA: 1. Log in to your Web Vault.

1 Like

Fair point! @fschillingeriv :slight_smile:

@Logician - just so it’s said, the HTTPS/MITM scenarios you describe would only allow access to the encrypted data, or a hash of your master password, never your actual password.

The web interface is an entire javascript app that handles authentication and decryption separately. Authentication hashes the password and sends it to the identity service, while the ket derivation is done 100% locally.

More on the architecture if you’re interested: https://bitwarden.com/images/resources/security-white-paper-download.pdf

Hi, Trey. (@tgreer) Thanks for your reply. I currently believe this is not quite entirely true. To quote and extend what Mark said :"[Y]ou’re still relying on the Javascript code being trustworthy - and for that to be the case, you have to trust that the Bitwarden server hasn’t been compromised", AND that the Javascript you’re running is the standard version AND that it’s being served from the real Bitwarden server. ALSO, I’m going to read the white paper ASAP - you work for bitwarden, and I have a lot of faith in Bitwarden. 'till I read it and follow up here, assume I’m wrong, folks.


Although it’s true that,

the integrity of the javascript that is running locally can be attacked in either of the two ways I pointed out. Both of these attacks are extremely difficult to pull off. Because of, among other things, CAA and politics, respectively. But if pulled off, the compromised javascript (the authenticaltiopzn part) would receive your master password and then surely could exfiltrate it in any of a myriad number of ways, no?

Also, perhaps it’s not ideal to call the javascript an ‘app’ in this context. Could be seen to imply security features it doesn’t have (like being verifiably signed). But again, I need to read the white paper! I imagine it could address that somehow. It appears that without a ton of work, one could download the javascript as securely as possible (from GitHub, compare to …) and get it to run locally. Reassuringly,the last audit summary says “a whitelist has been configured on Bitwarden server APIs to allow only the Bitwarden web vault application to have unrestricted access. Namely, the Access-Control-Allow-Origin​ header will always return the web vault origin (for example, https://vault.bitwarden.com​ or a self-hosted server’s host URL).”

(I wonder what the Access-Control-Allow-Origin​ header holds. Gotta check.)


Also, there’s my

“PPPS. Bad news. In order to enable 2FA: 1. Log in to your {Web Vault}.”

So I can’t enable 2FA. That’s making Bitwarden less safe for me.


Also I think it’s reassuring and true that, as noted at https://RiseUp.net/canary ,

Forced speech is actually quite rare in the US legal context.

HOWEVER, that doesn’t mean that Bitwarden couldn’t have its arm twisted by, say the CCP or the Saudi authorities threatening to seize funds or block Bitwarden entirely. (OTOH, perhaps they already do! I wouldn’t be surprised.). These are powerful adversaries (one interesting example).


Last but not least, I think I need to edit / retract my statement,

Unfortunate to see that this shortcoming still hasn’t been addressed.

I must have written that before looking into CAA and finding it to be supported?

PS. I would donate if Bitwarden launched a Kickstarter (All or Nothing) crowdfunding effort to submit to (and hopefully pass) an audit by an outside party who has full access to internal systems. This would complement the two audits that have been reported so far. For what would make this a good audit, see here.. I’d love to hear how much such an audit would cost; Bitwarden could put out an RFP and solicit public bids.

Wait, WOW! Bitwarden achieves SOC 2 certification | Bitwarden Blog. says:

SOC 2 Type 2 and SOC 3 certifications are complete

HOT DAMN! That’s impressive!

(Haven’t examined the cert but still - WOW!!!)

(Admittedly, tthis is apropos a rather OT comment at the end of my last post.)