This alone lends credence to their claims. To this date there has been no major breaches despite being a large target (albeit smaller than LP). Moreover, the fact that your vault is both password protected and locked behind a secret key is about as good as you can get in terms of commercially offered security.
That's not to say they couldn't be lying. But after careful evaluation I've gone to them and people much more experienced in security have also moved to them as well.
FWIW a "source code audit" or "making it open source" does not imply intrinsic security. You are putting far too much weight in either a firm to do the right thing with money, or the existence of sufficiently motivated OSS researchers mining what might be millions of lines of code. We still find bugs in the Linux kernel regularly despite it quite literally having tens of millions of eyes on it. What makes you think this would do anything more than assuage your fears through security kabuki? In fact, OSS while sounding nice introduces an entirely new attack vector that a company may simply not have the staff to mitigate. To use the Linux kernel once more vulnerabilities have been deliberately injected into the kernel more than once. There have been game breaking SSL bugs. Huge overflow problems, etc. I love OSS. It is not a panacea. Signal chose this model - it does not imply it is the best, the most practical, or the most secure.
If a document alone lends credence to their claims, the source code would do wonders. It's not about public contributions, it's about transparency and good faith.
Why do you trust the source code is actually what they deploy to your device, or that what they build isnt linked against extra libraries, maybe even internal library?
I do. Having source code available does6 mean anything if you can't verify the source yourself, or if the source can't be community certified. There's no point in a backend being open source, if nobody can verify what is running there. There's no point in an iOS app being open source if the app is distributed through the app store, as we have no way to verify that it is what it says it is.
Meanwhile if I'm running Debian I trust the maintainers have built the source code to distribute to me, similarly with homebrew and chocolatey.
> Its a matter of trust and good faith
Indeed it is, and you have to trust 1password, and if you don't, it doesn't matter whether there's good faith or not.
> Indeed it is, and you have to trust 1password, and if you don't, it doesn't matter whether there's good faith or not.
Precisely. By not showing their source code, they implicitly state that they don't care about whether you trust them or not when it comes to source code. It is not a meaningless distinction. Bitwarden for example lists being open-source as a plus in security. You may not personally see it that way, but a big part of the industry does.
Intellectual property is important and making everything open source would allow our competitors to easily copy it or at least get an idea how to improve their products. It is hard to seriously compare the features, the security design, and the UX of Bitwarden to 1Password — it is not close. Just a few examples: being able to edit your data while offline, ability have large notes with Markdown formatting (aka "Moby Dick Workout"), support for large datasets (more than 100,000 items).
1Password has been in business for 17 years, longer that any other password manager. It is very difficult to have a long term business model built completely on open source.
I never said open source was to be the foundation. In fact, I never talked about open source at all. All I'm referring to is source availability.
As I said earlier I'm not going to complain that you won't use a free license such as MIT or AGPL or whatever else. The real issue is just the sources being publicly auditable. Are you worried about your competitors copying your non-copyrightable material? Ideas?
While there would still be an issue, I would be a bit less harsh on the policy if at least the clients were source-available. Transparency is security.
> It is hard to seriously compare the features, the security design, and the UX of Bitwarden to 1Password — it is not close.
How does Bitwarden not come close in security? All I can come up with is the secret key requirement. Is that all? If anything Bitwarden feels more secure because of its transparency. You can see the developers working live, each commit they make.
The client source code is the where the most of the IP is. The server code is pretty dumb on it own, all it does is the sync and permissions.
One of the issues with Bitwarden encryption is the fact that every field is encrypted separately and that could provide more info to the attacker. For example, you could tell how many URLs in a particular login or if there is note for an item and how long it is.
Noted, thank you. So why not source-available? I assumed you already published the non-copyrightable ideas in your public whitepaper. Is there a concern that even if the sources are made available under a "look but don't touch" basis (essentially all rights reserved) competitors would still gain an advantage by copying the non-copyrightable stuff like processes or ideas? (that are already public through the whitepapers and could reasonably still be obtained via reverse-engineering of the client binaries)
This alone lends credence to their claims. To this date there has been no major breaches despite being a large target (albeit smaller than LP). Moreover, the fact that your vault is both password protected and locked behind a secret key is about as good as you can get in terms of commercially offered security.
That's not to say they couldn't be lying. But after careful evaluation I've gone to them and people much more experienced in security have also moved to them as well.
FWIW a "source code audit" or "making it open source" does not imply intrinsic security. You are putting far too much weight in either a firm to do the right thing with money, or the existence of sufficiently motivated OSS researchers mining what might be millions of lines of code. We still find bugs in the Linux kernel regularly despite it quite literally having tens of millions of eyes on it. What makes you think this would do anything more than assuage your fears through security kabuki? In fact, OSS while sounding nice introduces an entirely new attack vector that a company may simply not have the staff to mitigate. To use the Linux kernel once more vulnerabilities have been deliberately injected into the kernel more than once. There have been game breaking SSL bugs. Huge overflow problems, etc. I love OSS. It is not a panacea. Signal chose this model - it does not imply it is the best, the most practical, or the most secure.