The PDF linked below states that there is zero integrity in 1Password file format.
I happen to like and use KeePass, but that is not a secure-software guarantee.
We use Encrypt-then-MAC authenticated encryption everywhere we use encryption. The MAC is HMAC-SHA256 and encryption is AES-CBC using 256-bit keys. Key derivation is uses PBKDF2-HMAC-SHA512. More detail about these choices will be presented in the relevant sections on key derivation and item encryption.
https://blog.agilebits.com/2013/03/06/you-have-secrets-we-do...
Members of the 1Password team are vocal participants in the ongoing conversation about secure software and cryptography. For instance, Jeffrey Goldberg frequently gets involved in discussions of crypto vulnerabilities on Twitter. I don't have a formal recommendation to offer you regarding their team, but I can offer the same "I've talked to these people and feel like they know what they're doing" vibe that Schneier tried to offer for BestCrypt.
Anyways: that's one of the reasons I like 1Password.
1. The "Agile Keychain Format" (versions 2 and 3, which lack integrity). 2. The "Cloud Keychain Format" (versions 4+, which have integrity).
You didn't specify which version you use & like.
I also note that the 1Password team had been selling security software which was not designed well - see (1) above. And it's not like HMAC wasn't invented when 1Pass got started.
Mr. Goldberg learns as he goes. There is nothing wrong with that. Or is there - when it comes to selling security software? Rhetorical question for all to ponder...
(I thought, no, no way is this actually ECB mode, maybe they just did the XOR'ing for CBC mode outside the TwoFish class, but no: they appear to pad blocks explicitly to block boundaries and then ECB them.)
I looked for a total of 4 minutes, so if someone wants to correct me...
http://sourceforge.net/p/passwordsafe/git-code/ci/333dd9f23a...
ECB mode is only used for the internal keys. The database records are encrypted in CBC mode, and there is an integrity authenticator HMAC as well. However, the format was designed in the days when Mac-then-encrypt was considered proper. So the authentication HMAC is over the plaintext prior to encrypting.
Also: in PWSfileV3.cpp, are they HMAC'ing the IV?
This is interesting; we might be able to make an exercise out of it.
> When the Agile Keychain format was developed, chosen ciphertext attacks (CCA) were seen as theoretical. Furthermore the primary threat to 1Password users was thought to be from an attacker stealing the data once and pursuing an off-line attack. It did not anticipate an attacker who could tamper with user data that would be subsequently processed by the legitimate owner.
> CCAs are no longer just theoretical, and we also see (and encourage) widespread storage of 1Password data in “the cloud” for syncing. Thus data integrity needs to be addressed in our new design.
It would have been great if the Agile keychain format included integrity, but hindsight is 20/20.
[1]: https://learn2.agilebits.com/1Password4/Security/keychain-de...
Even if they could not anticipate an attacker tampering with user data, surely they should've been able to anticipate filesystem corruption?
Let's not pretend that MACs and secure integrity checks were a modern marvel just because CCA attacks were seen as theoretical back then.
Whatever that subtext might be: it's especially weird coming from you, since you're the author of the story at the top of this thread, about a current version of KeePass that uses unauthenticated encryption. The EtM CBC+HMAC crypto design we're talking about for 1Password is years old.
With author trust being a non-issue (humor me in this assumption), we must look at facts & evidence only.
Both 1Pass and KeePass repositories are well-specified, with latest 1Pass clearly having an advantage due to AEAD.
1Pass implementation quality is unknown due to it being closed-source, and I'm not aware of any independent audits. KeePass implementation quality can at least be observed & discussed. 1Pass cannot even be discussed due to being a "trust-us" blackbox. Well, I don't trust them.
I would wager that even you don't know whether 1Pass actually HMAC's their IVs.
On a more holistic level, this category of software is client-based password managers (as opposed to centralized password managers like LastPass). My position is that trustworthy client-based password managers cannot be closed-source.
It's a minor thing to be wrong about, but it's also something you could have checked yourself before dinging me about it. :)
The story of this whole thread culminates in a place where I trust 1Password a lot more than KeePass; KeePass knows they need a better cryptosystem, but retains a broken one. 1Password has an extensively documented file format with 3rd party implementations, the author of which format actually responds to academic research.
I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!
I would argue that KeePass and its loyal and vast userbase does not in fact seem to know they need a better cryptosystem (and ideally better implementation). My HN post was intended to bring this to everyone's attention.
"I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!" - so would I.
As for the other things, like using the rng properly and whatnot, no, you can't really check that stuff. But your implication here is that open-source apps can be trusted because you can verify that stuff, and I don't buy that. Unless you yourself are a crypto expert that's qualified to carry out such an audit, and you have the spare time / inclination to perform a full audit of the app, then there's no reason why it being open-source should make it any more trustworthy. Perhaps if some independent trustworthy third party performed the audit you could then decide to trust it, but closed-source apps can still be audited, it just requires the help of the app developer to do so.
And of course even if the app is audited (whether open- or closed-source), that audit will only really verify the particular version that was audited. Future changes may introduce vulnerabilities again, so unless someone qualified to do so is constantly auditing all future changes, then you can't really trust it anymore, since your trust model is that the source needs to be independently verified to be trusted.
On other hand, if your trust model is that you determine whether you trust the people involved to get it right, then it doesn't matter if the app is open- or closed-source, as long as it's developed by the right people. Granted, it can be hard to determine whether someone can be trusted to get it right without independent audits, but speaking personally, I take tptacek's "I feel like they know what they're doing" recommendation as carrying a fair amount of weight. I certainly would welcome an independent audit of 1Password, but I recognize that I can't really expect a closed-source software vendor to hand the source of their flagship application to a 3rd party.
(if it isn't clear, I'm a happy user of 1Password)
I have ample factual evidence that both KeePass and 1Pass authors had made multiple crypto blunders. Both score low on my trustworthiness scale.
It's extremely difficult to prove crypto correct, but it's very easy to discover that it's wrong. Open-source software allows one to discover crypto mistakes. It does not allow one to prove crypto correctness.
On the other hand, if you use closed-source software like 1Password, you cannot discover crypto mistakes regardless of your level of crypto expertise.
Once we start making crypto choices based on tptacek's, schneier's, or anyone else's feelings about someone seeming to know what they are doing and getting a 'good vibe', the dark age of crypto will truly be upon us. Many folks trust & use PasswordSafe not because Schneier wrote it (I hope) but because it is open-sourced. Many folks trust & use Tarsnap not because Percival wrote it, but because the client is open-sourced.
I rely on a large amount of closed-source software for a great many things in my life. I'm not sure why my password manager is notably different than any other software that manages particularly important information.
> Many folks trust & use PasswordSafe not because Schneier wrote it (I hope) but because it is open-sourced.
Virtually nobody that uses it is qualified to actually judge whether it's secure. At some point you have to put your trust in some person to tell you whether or not it's secure. In the case of a fully-audited open-source solution, you're putting your trust in the auditor to have done a good job. In the case of an open-source solution that was audited at one point but has continued development since then, you're putting your trust in a combination of the auditor to have done a good job and the original developer to have maintained the quality level of the software during subsequent development. In the case of an open-source solution that has not been audited at all, you're putting your trust in the developers, and in the anonymous collection of other people that may or may not have actually examined the source in any meaningful fashion. And in a closed-source solution, you're putting your trust in the developers.
The biggest problem I have with your position is you're making the implicit assumption that, just because open-source software makes its source available to the world, this means enough anonymous other people have independently audited the software in order to feel reasonably secure. But this assumption is flawed, for several reasons. First, just because the source is available doesn't mean anyone's actually bothered to read it, and even very popular projects can suffer from this problem if the project isn't particularly accessible to contributors (case in point, AIUI the OpenSSL source is pretty hard to grok, and historically has had very few contributors, which led to issues like Heartbleed). Second, if people do read through the source, this doesn't in any way mean that anyone who's sufficiently qualified to judge the crypto has done so. Thirdly, even if someone who is sufficiently qualified has read through the source, it doesn't mean they've done so in a rigorous-enough fashion to really qualify as an audit.
In the end, unless you personally are sufficiently qualified to perform an independent audit of the open-source software, and unless you personally have actually performed said audit, then you are ultimately just trusting people. Which is exactly the same situation you have with closed-source software.
In fact, I've never seen more crypto bs than in OSS. I'm not beating the OSS drum for the "good people of the world". OSS is a crypto requirement for me, personally, to make intelligent risk decisions.
Uneducated people have no choice but to trust someone. Educated people (ex. tptacek) should have the capability to discover crypto mistakes to make their own decisions against their own risk tolerance equation. Absence of mistakes doesn't prove anything, but their presence speaks volumes.
[1] https://discussions.agilebits.com/discussion/comment/127847/...
One thing, I never liked about the 1Password file format was it's insistence on leaving certain fields unencrypted in order to allow the app to search using those fields. I've pushed for a "high security" preference option were all fields are encrypted to not avail.
I'm willing to trade off the search convenience but that's a choice that Agilebits should allow me to make.
I didn't think v5 was still in beta as I've been happily using 1Password 5.
A more precise way to state my preferences:
I trust _crypto_ from Microsoft, Apple, or (especially) Google more than I trust _crypto_ from a developer I've never heard of before. I do not as a rule trust rando closed-source projects.
We determine how much we trust a piece of software based on countless different social/technical factors. Being open-source is definitely a positive trust factor, but some people may place more weight on other factors such as pedigree of the developers, availability of corporate backing/funding (guaranteed continued development/support), or maturity/stability of the software itself.
I personally consider being open-source paramount when it comes to security/privacy software (and am one of those people who tend to dismiss anything privacy/security related that's not open-source, although I don't usually feel the urge to broadcast my dismissal to the world), but I respect that other people may not share the same set of priorities.
Given the type and link to 'hamsterporn.net' I can guess you are a user of some site which may be embarrassing if exposed.
i.e. ass, poorly implemented, bad
But couldn't the implementation of parts of the service being flawed? (and you cannot know as it is closed source)
Edit: The reason I asked is because I wanted to see if 1Password can be more secure than LastPass. However, if you're using 1Password with Dropbox, I'd say this combination doesn't feel any more secure than LastPass. Other more secure options like WiFi sync aren't convenient enough. So, it appears there's no strong reason for me to consider switching from LastPass.
With 1Password+Dropbox, Dropbox doesn't know your master password. It only ever sees the encrypted vault, and doesn't have any opportunity to intercept any plaintext. (If your password is strong enough, you could probably even get away with posting your vault on a public website.)
And if I think about "What is harder for hackers to get to: My encrypted password file on Dropbox or my encrypted passwords on LastPass," I feel I'll have more confidence in LastPass.
Anything very obviously wrong with this thinking?
The problem is not open-source/closed-source so much as it is that convenient, centralized, web-based crypto tools are virtually never safe, and that's the problem LastPass has chosen to try to crack.
If 1Password was compromised, on the other hand, they'd have to wait until you upgrade the client to the bugged version. As far as I can tell, they don't even have a web interface for you to log in.
Dropbox doesn't even come into the equation since it's just dumb storage. Someone who compromises Dropbox will only see a useless blob. The attacker would have to compromise both 1Password and Dropbox, as well as get you to install a compromised 1Password client, in order to get your encrypted passwords.