I really dislike the idea of giving complete access to my digital life to any company, particularly one that needs to grow quickly.
The tech for password vaults is so simple, I use keepass + icloud syncing and get free end-to-end encrypted password syncing, without sharing any data with anyone.
There's still trust there. You're writing the key to decrypt everything into their web interface if you ever use it (vault.bitwarden.com). If they wanted, they could really get access to everything in your bitwarden vault.
Basically, your master password is never sent, and everything is encrypted and decrypted locally.
You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.
Well even then you have to make sure your compiler isn’t playing tricks on you. So compile your compiler from source … oh wait.
Then you have your cpu microcode, firmware, security coprocessors.
If you run keepass in a cgroup with no networking (or blocking in/outbound traffic in windows firewall) or extra disk access, your attack vector shrinks considerably. That's not particularly difficult to do, while it is to audit js on every single bitwarden page load
I can't audit their server-side code. Even if it's open source, it's impossible to verify that the software which the server is running is identical to the open source version, or that there's no proxy in between you and the sever which logs the passwords, or some debugger attached which inspects the passwords in memory as people log in.
Basically, your master password is never sent, and everything is encrypted and decrypted locally.
You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
The proxy would only see encrypted blobs; the client (which afaiui can be compiled and run locally despite using their hosted service) never sees the passwords in clear.
As long as the client and cryptography are uncompromised, the server only gets metadata.
Services like 1Password are often more secure than your solution because they need to harden vaults against full leaks. In the case of 1Password, a secret key in addition to the password ensures that brute forcing is (at the moment) not feasible, even if your password is really crappy.
LastPass would have also led their customers to believe that "brute forcing was not possible" and that they were taking extraordinary measures to keep vaults and data safe.
I think one distinction between services like KeePass and 1Password is end user perception of how easy it is for an attacker to acquire an encrypted vault to begin with. For many, they consider a KDBX database sitting in their Dropbox account to be less likely to be stolen than an encrypted vault being held by a company like 1Password, a high value target to the most sophisticated attackers including state actors.
Doesn't necessarily matter what LastPass "would have also led their customers to believe", the mathematical reality is still that LassPass vaults are crackable in a way that 1P vaults fundamentally are not.
Yes, according to what 1Password is telling us. But as we've seen, what these companies say and what they actually do in practice are not always aligned. And oftentimes customers are inserting a lot of their own assumptions into the mix, not only with respect to vault encryption but vault storage and operational security.
With their very comprehensive whitepaper and Charles Proxy you can verify all their claims. Their whitepaper is one of the best resources I have found on E2EE in general. With that, you should be able to write your own 1P vault parser. Then you can verify that traffic to their server is exactly what they claim it to be.
In another comment you are criticizing that their product is proprietary - that's IMO not quite true. Yes, 1P is closed source, but their crypto strategy is documented extensively - they list the exact cipher algos and settings.
> not only with respect to vault encryption but vault storage and operational security
That's a valid argument, BUT, if you read their whitepaper, you'll likely arrive at the conclusion that even a full leak of the encrypted vault is currently not that problematic. I wouldn't post it online, but I'm not worried if they announce a leak tomorrow.
> Yes, according to what 1Password is telling us. But as we've seen, what these companies say and what they actually do in practice are not always aligned.
That's just not accurate:
1. First off, all the encryption happens client-side. It is possible for anyone so inclined to validate how 1P and LP are doing their encryption.
2. The deficiencies in LP's encryption approach were well known for years.
My point it, yes, companies will spin things how ever they want, which is why you should completely ignore what they say and only evaluate what is verifiable. And 1P's and LP's approaches are verifiably different.
1Password's client side encryption is occurring within it's proprietary, closed-source product, so I'm not sure how the end to end process can be completely validated.
With respect to your confidence in 1Password's code and encryption methodology, would you be willing to send me your 1Password vault so that I can have a look at it?
> 1Password's client side encryption is occurring within it's proprietary, closed-source product
It's Javascript running in a browser.
> With respect to your confidence in 1Password's code and encryption methodology, would you be willing to send me your 1Password vault so that I can have a look at it?
Yes, absolutely (note I don't actually know how to get the encrypted version of the vault standalone). Are you willing to send banking information over HTTPS? It's the same level of security.
> Yes, absolutely (note I don't actually know how to get the encrypted version of the vault standalone).
I believe that, given that it's just JavaScript in the browser, that the encrypted vault should be available as a blob in one of the network requests when you are making a change to the vault.
> Are you willing to send banking information over HTTPS? It's the same level of security.
Maybe I'm being irrational, but I just think there is a fundamental difference in the risk profile between a breach of my banking credentials and having every stored set of credentials across my entire digital life exposed through a password vault breach.
If my banking details were compromised somehow, I at least have a bank I can work with and real people I can talk to. Both the bank and myself have a strong mutual interest in addressing the acute security issue. Government banking regulations come into play. Insurance comes into play.
If my password vault is compromised and credentials for every service and website are exposed, I would argue that is a far graver matter. And who do I turn to in that case? I have to imagine that any of these password management companies would just point to me being somehow negligent with my master key and tell me to pound sound.
9-10 words chosen at random from a list of 10k common words in you native language will get you to 128 bits. Sure not trivial to memorise, but far from impossible.
You're not wrong of course - this would come with heavy UX issues though. E.g. it's hard to type 10 words into a password field without messing up. And _really_ hard on a mobile device.
1P would allow you to have a password like "1234" and still have the same key entropy as that 10 word password alone.
A mobile app could easily facilitate that by storing a "passphrase prefix" (or suffix, etc) using biometrics/device key and requiring users to enter the remainder if you don't trust the device to store the entire thing.
But in the context of a strong master password, the additional benefit of the secret key is of neglible benefit, while the hassle and dangers of having to synchronise the secret key remain.
I'd rather use an extremely high entropy master password by itself.
> And no, because it depends on how users setup and use their AppleID and its passwords/security/devices.
Can you elaborate what the issue would be? I see that the AppleID password could be a weak link, but that's mostly mitigated by 2FA.
> if 1Passwords decides to share the private key
I'm not aware that they could do that. Their servers have no knowledge of either the password or secret key. Authentication happens via a zero-knowledge proof.
That's not a fair comparison. The differences in LP and 1P encryption approaches have been well known for years, and they are fundamentally different.
Now, while 1P encrypted vaults are not brute-forceable the way LP's are, that doesn't mean it's impossible to hack 1P (e.g. malicious code injection in any of their apps or plugins), but I don't like the "everything turns out to be a false promise" broad-brushing when there are real and verifiable differences in how these companies secure your data.
So is LastPass, but we users changed our passwords in December anyway as a precaution. Bitwarden is still a central entity that needs to be trusted to manage the zero knowledge platform with competence, e.g. not storing unencrypted metadata in a backup.
Because LastPass is a bad actor that falsely claimed to have a "zero knowledge architecture" that couldn't be compromised if they were hacked, and kept their code secret so nobody could independently assess their implementation, and then proceeded to store critical user data unencrypted, which was promptly hacked and leaked, that means the risks must be identical with Bitwarden, which publishes client and server code in public, so anyone can inspect their implementation.
That specific fault applied to LastPass, I used it as an example of a flaw in a system advertised as zero knowledge, to demonstrate that not all systems are created equal. It is true that BitWarden's Open Source nature helps prevent silly things like that.
You raise a good point that their open source clients are _verifiable_, but they're not often _verified_. I'm certain that you verify the checksums of all your updates or exclusively build from source, but the distribution channels on most platforms encourage users to trust updates from BitWarden inc. If those channels are compromised, most users are one unchecked automatic Play Store update away from a problem.
Not disagreeing, just noting that Open Source is not a silver bullet given BitWarden's default architecture is centralised web service with centralised client distribution channels.
Bitwarden can be self-hosted, it's fully open source so you can be safe that way, never giving a single byte to the company.
Do you have a browser extension that offers username/password autofill using keepass as datasource or do you alttab copypaste / rely on a program made by someone else to clear your clipboard?
I kind of want to point out the discrepancy in saying "I get syncing without sharing my data with anyone by sending my password database to Apple". If your argument is that the database is encrypted, how is Bitwarden different?
What this highlights in my humble opinion is that many users seek security signals and are less concerned with the actual security implementation. In the password management space, the signals are "local vault", and "not VC backed", at least on HN. It's quite odd since you'd think people would be more concerned with the application architecture, key derivation, key transport backup and recovery, etc. But it seems security is more synonymous with "company doesn't store my vault on their servers" than it is with "company helps me securely encrypt my passwords".
The tech for password vaults is so simple, I use keepass + icloud syncing and get free end-to-end encrypted password syncing, without sharing any data with anyone.
Outlined in more detail here: https://magoop.substack.com/p/how-to-manage-500-passwords-se...