Hm, I’ve read about the concept of homomorphic encryption, but I’m not deep enough into crypto to understand how it works and what’s its limits (it’s still mostly under research, though).
But afaik, it’s not related to or needed by hash functions or KDFs which are used for password storage.
I agree, just pointing out how safe information can be now a days.
I am new to this forum, and I hope my post here will not be deleted. But, you can actually test the BW encryption at home by using Chrome/Brave browser. As I tested it myself, yes the password is encrypted on my device before being sent to the BW server.
You can watch this video on how it is being done. Not my video:
Thanks!
As an embedded developer, I don’t have so much clue about how to verify or debug what’s happening in a browser, so that’s a nice explanation. Great that Chrome makes it easy to check the data which is getting transmitted.
For a complete verification, we’d have to check that using the encryption algorithm + key – when using them with the respective plaintext string – actually result in the string that are displayed in the browser.
Otherwise the string displayed in the browser could be the result of another operation, e.g. of a reversible transformation.
It was mentioned that if their servers got compromised the javascript client could be modified and suddenly you’re running malware. This is a fundamental flaw with web-apps where you load from the server.
It would be nice if all account functionality could be managed through at least one of the non-web clients. Desktop, Mobile, etc.
As was mentioned in this thread, you can host your own instance of Bitwarden if this is a real concern for you. You make it sound like this is not possible with BW.
But, if you go it on your own, you then have to ask: who is better at securing a server to store my vault, Bitwarden or me?
Are you looking for a Desktop App? Look here as I believe you will find one.
I have the desktop app, not that I really use it at all. But I just tried to check something.
I am being forced to use the web vault. What I’m advocating for is that a customer can do anything and everything from at least one of the non-web-vault clients.
It makes trust/reviews easier to use the desktop client, because I have control over updating the client. When using the WebVault, I’d have to check the code each time to make sure it didn’t change.
I typically use only the desktop clients – my decision to use BitWarden depended on clients being available for all major platforms (Linux/Windows/iOS/Android).
I’ve seen two scenarios where I have to use the WebVault – for creating the account and for changing the master password.
I agree with @Ben86: having all functionality in the client somehow would feel better.
Greetings! You’ve given some great information in this thread–thank you all. May I ask a (hopefully) related question?
On occasion, I’ve wanted to access my Bitwarden vault from my work computer. My workplace uses SSL inspection to intercept SSL traffic as it passes through the firewall(s)–I believe for the purposes of scanning for viruses. I don’t know how it all works, but I’m going to assume that, while I trust the network, this leaves SSL traffic open for an unscrupulous firewall admin to snoop in plain text the traffic that was meant to be encrypted. I don’t know if that’s actually true, but I’m assuming the worst here.
So assuming my SSL traffic is intercepted, can someone gain access to my account by snooping my salted and hashed password? They may not know what my master password is, but unless the salt is changed, the hash function will always produce the same output when my master password is fed into it. One could conceivably feed the Bitwarden server my pre-salted and pre-hashed password to gain access to my account. Granted, I don’t think this will allow them to decrypt my vault, but if they could log in as me, could they change something to render my account inaccessible or outright delete my account?
Or is my complete ignorance of how that part of it works showing? 
Thanks!
Nice question, and I agree: this is a fun thread to read!
So if your traffic goes out through the HTTPS-tunnel, it will indeed be intercepted. Your network admin will be able to see the raw JSON-files sent out. But do have a look at that video a few replies up… You’ll see that everything inside the JSON-file is also encrypted using a derivate of your key).
Use the network tools in the browser tools of Firefox or Chrome (or even go all in, and set up an intercepting proxy or OWASP ZAP) and snif your own traffic. You’ll quickly notice that HTTPS is only a (pretty secure) gift wrap that BW doesn’t even rely on.
Thanks, JurgenG. Yes, I see the data in the JSON is going to be encrypted. I guess my question is can that be used in a replay attack of some sort to log in to Bitwarden and harm my account, even if my vault data cannot be used or changed?
I mean, in truth, this is more academic than anything, although I suppose a legitimate man-in-the-middle attack is feasible if my home computer is compromised in some way.
My two cents on that:
The SSL traffic is end-to-end (user to Bitwarden server), but it is plaintext after the Bitwarden server decrypts it.
So the scenario with the SSL inspection firewall is similar compared to someone getting access to the BitWarden servers, or to a malicious employee at BitWarden (where the server decrypts the SSL traffic).
The concept where everything is encrypted locally is supposed to prevent attacks in those scenarios.
Any keys which are sent via SSL are derived from the encryption key in a way that they don’t leak information regarding the encryption key.
So I think that SSL doesn’t contribute to Bitwarden’s vault security.
In a replay attack, the malicious person would indeed be able to intercept the encrypted set of data. But without the your password (which stays on your computer at all time), and the optional second factor authentication (be it Yubikey, some authenticator app or whatever BW supports), the ciphers say nothing.
Even if you would use the same password, it would not appear in the data leaked, as the URL is also part of the salt being used.
The edge case being that you could have a keylogger on your computer, compromising your master password. But this is where your 2FA can save your bacon. No way for a replay attack.
Reviving an old thread here. Sorry if this is a total noob question, but I’m trying to fully grasp this.
If I understand things correctly, when it comes time to change my master password, and it’s asking me to do so on a webpage (Bitwarden Web Vault), the information is encrypted before leaving my computer?
It’s asking me to enter my old MP, and then enter my new MP. I guess I don’t understand why these have to go their servers in the first place, and not just stay on my local machine. I thought their role was just to store an encrypted database on their servers, which is then downloaded to my machine every time I want to use it. If that’s the case, why would my MP ever need to reach their server for any reason?
Your master password is never sent to the server. When you enter it into the form, it is processed on your computer and encrypted and hashed and that ‘code’ is sent to Bitwarden for verification. Because the same algorithm is used each time, Bitwarden can verify if you entered the same password or not without your computer ever revealing the actual password.
Thanks for the explanation. So, how come this hashed code needs to reach Bitwarden at all? I thought their server’s role was merely storing an encrypted password database and nothing more.
If their servers ever got hacked, and someone got a hold of the database as well as the hashed code, could this code be decrypted to then compromise the database?
Well, you have to send them something - you need to be able to authenticate your identity somehow, right? How else would Bitwarden know it was you requesting to download your encrypted vault?
And no, the hashed password sent to Bitwarden is used for authentication, but it is not the same as the encryption key that is generated on the client-side and never leaves your machine - this ‘secret’ key is used to encrypt your data, and without it, nobody can read your data stored on Bitwarden servers. Plus, the hashed password is “one-way” hashed and salted so that it can’t be reverse engineered to obtain the original master password, so there is no way for even Bitwarden to decrypt your vault.
More details can be found here:
Better send everyone a copy of bitwarden white paper 
, it should leave no doubts i guess. The help article doesn’t explain everything in detail including the need to keep hashed version of master password on server to authenticate.
I used to have similar doubts too , untill i read the white paper😅
Ok, thanks for your explanation, that clarifies exactly what I was wondering about.
I guess that brings me to 1 more question. When running a data/password breach report, how does that work securely, basically how are my passwords/logins matched up to known breach ones securely? Is my local app sending out a query w/ logins & passwords to a server somewhere? I tried finding out more about this works, on Google, but didn’t have much luck.