Agreed. I use keepass + dropbox secured with yubikey. You can even go a step further and configure yubikey with keepass as well.

Where about on mobile?

Strongbox for iOS.

Right on, thank you!

I believe KeepPassDX on android supports yubikey via NFC.

Same here.

KeepassXC to be specific: https://keepassxc.org/

I do this, but have started using Syncthing [1] for sync instead of a cloud service.

[1] https://syncthing.net/

Bitwarden is built as a zero knowledge platform and they can't access the contents of your Vault.

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.

They cannot store unencrypted data because the whole vault is encrypted client side.

And thats verifiable because their clients are open source.

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.

Only if you never use the web interface.

BitWarden doesn't get "complete access to your digital life", they get an encrypted blob.

It's not materially different than storing your KeePass vault in the cloud.

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.

That's why open source is important. You can audit them and verify that they are behaving in a trustworthy manner.

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.

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.

They have a paper about their architecture.

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.

Not if you are using their cloud version instead of the open source self hosted server.

The code they are running does have to be the code they are publishing.

And if someone compromises their cloud servers, they could also modify it to log the passwords entered.

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.

Trusting trust

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

They have a paper about their architecture.

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.

Hah, so I suppose the next step would be a browser extension that performs this auditing on every visit

But your data is encrypted client side. It shouldn't be too difficult to audit thay the client side code matches a build of their original sources.

Then host your own.

Microsoft too, since Bitwarden uses Azure. I think its find.

I used to do this. Now I self host vaultwarden since it allows me to use that database with faceID. Can keepass do that?

I like keypass, but merging my android and pc versions every so often is a task I'd like to automate. I dont do google/apple cloud so avoiding that.

I use the Strongbox iOS client. It reads .kdbx files, integrates with apple sign-in features, and supports faceID.

https://apps.apple.com/us/app/strongbox-password-manager/id8...

I use the Keepass2Android and it integrates with the OS fingerprint reader, so it's likely the same for faceunlock but I don't use that.

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.

Keepass has Key Files as a part of the spec https://keepass.info/help/base/keys.html

On my devices, keyfiles and a KP client are stored locally. The DB rests in the cloud.

Is that kind of file storage secure? I thought files stored on disk can be extracted quite easily?

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.

> 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.

> Yes, according to what 1Password is telling us

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. With that, you should be able to write your own 1P vault parser.

All valid points!

Same was said about LastPass many times and look at what happened, everything turns out to be a false promise.

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.

Unless you want to spend the time doing RE of crypto (so fun!), how to do you even know who works for 1Password?

Are you waiting for Snowden 2.0 to explain how things work a decade later?

Note that 1Password copies the "Secret Key" to iCloud... without asking.

Do you mean iCloud keychain? That's arguably one of the most secure cloud storage in existence.

Yes. And no, because it depends on how users setup and use their AppleID and its passwords/security/devices.

My only point is, if 1Passwords decides to share the private key with [whichever cloud service] the user should at least be notified, or get a choice.

> 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.

Ah, Apple recently improved things further: https://www.apple.com/newsroom/2022/12/apple-advances-user-s...

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.

How do you remember a 128 bit entropy password?

remember 10 random words

How is 1Password's secret key more secure than using keepass's key file feature?

Or, simply a password for your Keepass database with the same entropy as 1Passwords secret key.

Anyways, it depends on the app you use. Some Keepass apps haven't even been audited for example, so security of those apps may be questionable.

> Or, simply a password for your Keepass database with the same entropy as 1Passwords secret key.

How would you remember a password of 128bit of entropy?

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.

Here's a 142bits entropy password: CorrectHorseBatteryStaple

Also see: https://xkcd.com/936/

Depending on dictionary size, the entropy is way lower. Assuming a dictionary of 10k words, it’s only 53 bits.

That depends where you store that file. Is there a way to store this securely in a mobile device for use on the go?

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".

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 don't want my encrypted passwords on Bitwarden's servers. I'm OK with having my encrypted passwords on Apple's servers."

Difference, of course, being that keepass kdbx is offline and not dependent on any particular online service.

If apple gets too greedy with iCloud, you can sync your kdbx with 1000 other clients.