I don't know that an HN thread is the best venue to discuss crypto design flaws (you might be better off writing a POC of some kind and then publishing that), but yes, it is a little disquieting to see a sensitive application using AES without an authenticator.
To the many readers of this thread who believe they don't care about the integrity of their password vault, just its confidentiality:
The problem is you can't necessarily have confidentiality without integrity.
Sound cryptosystems that provide integrity checking rule out chosen ciphertext attacks against the cipher: in order to submit a ciphertext to such a system, you have to get past a cryptographically secure integrity check.
Without that check, attackers can feed a victim systematically corrupted ciphertexts, which the victim will dutifully decrypt, and observe the behavior of the victim in handling them. This is the basis for a whole family of "error oracle" side channel attacks.
You generally don't want to trust the confidentiality of a cryptosystem that doesn't check ciphertext integrity and rule out manipulated ciphertexts.
As the poster points out: this might matter a lot less for a system that runs purely offline. Or it might not. I lean towards "not a super plausible attack vector". But who knows? Why be OK with bad crypto?
I agree with your first sentence. But, regarding the rest of your comment:
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.
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.
Fair enough. I do note that the very blog you linked mentions that there are two 1Password formats:
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...
If there was a password storage tool designed from the jump by a full-time cryptographic engineer, that'd be the one I'd talk about. Let me know if you find one?
Password Safe [1] was designed by Bruce Schneier, that could fit the bill. It seems to have done quite well in the paper cited by xenophonf in [2], too.
Looking the C++ code for this project, this appears to be unauthenticated TwoFish in ECB mode.
(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...
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.
Yes, @tehjh on Twitter pointed this out. The CBC code is in Util.cpp, _readcbc; it appears to be length-delimited instead of padded, so there's probably another error oracle in the decoding of the length/type block.
Also: in PWSfileV3.cpp, are they HMAC'ing the IV?
This is interesting; we might be able to make an exercise out of it.
Just to note, in the 1Password 4 Cloud Keychain design page[1], he specifically says
> 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.
Can you help me understand what your fundamental argument is here? It seems pretty straightforward that the old, unauthenticated format is bad. Clearly, they didn't take crypto design very seriously when they shipped a product based on it. Is there some deeper subtext here?
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.
"Clearly, they didn't take crypto design very seriously when they shipped a product based on it." - spot on. There is no deeper subtext. Not sure what you found weird - eridius got my point perfectly and countered well.
Right, where I'm confused is, you seem comfortable using and endorsing something that by all accounts takes crypto design even less seriously than AgileBits did years ago. I'm not trying to needle you, I just don't follow where you're going with this.
I never claimed or implied that latest design of 1Pass repository is worse or even security-equivalent to KeePass. I simply pointed out that 1Pass team has made their share of mistakes (plural), so I have as much trust in their competence as, likely, in KeePass team.
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.
You start out in a reasonable place but then rhetorically overplay your hand: I'm pretty sure they do HMAC their IV, (a) because they say they do and (b) because there are open source implementations of their file format that (i) do the HMAC verification and (ii) would not work properly if they weren't HMAC'ing their IV. You can check right now: it took 2 minutes to find the Python code that computes the HMAC.
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!
Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your private data to the mothership when internet is available/stars align, creating plaintext temporary files in %temp% folder (accessible by all other apps), etc, etc. Ie. there is a myriad of things the implementation could get seriously wrong, even though the repository itself is encrypted securely.
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.
Some of the things you've mentioned here you actually can test for even on closed-source implementations. It's pretty easy to trace the activity of the app to see if it creates temporary files or does network activity so you can you investigate that stuff.
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)
You can't expect a closed-source crypto software vendor to hand the source to a 3rd party, but you have no problems handing that vendor's software the keys to your life. I'm not going to debate the merits of that decision, but it's a choice you make based on your individual, hard-to-quantify perception of 'trust'.
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.
> you have no problems handing that vendor's software the keys to your life.
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 my argument I never make a leap from "OSS allows discovery of crypto mistakes" to "OSS must be higher quality" or "OSS is better for the masses than closed-source".
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.
The Agile Keychain format has a field called "contentsHash" (which looks to contain 32 bits of data). I'm assuming that's some sort of hash (perhaps crc32) of the encrypted contents, used to protect against corruption (but not against malicious attackers).
I like and use 1Password too. But maybe someone smarter than I can explain what Goldberg is trying to say re 1Password and the paper "On the Security of Password Manager Database Formats" [1]
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 don't know. I skimmed Gasti & Rasmussen 2012, and reread Goldberg's comment; unfortunately, I also just skimmed the source for for PasswordSafe V3, the "only one" that achieved "MAL-CDBA"; it appears to be cryptographically unsound (MAC-then-encrypt of an idiosyncratic AES-CBC).
Their newer format 'opvault' claims to address it as well as authentication - you're probably best off just googling 'opvault' for the various forum and blog posts about it. You can enable opvault in almost all the platform/sync combinations if you download the current v5 beta.
Just to be clear this is not directed at you tptacek. However, I am genuinely confused at HN, whenever it comes to security/privacy most yell "Open Source Only" and yet a good chuck of them use 1Password, which I believe is closed source. It really doesn't make any sense. Why trust one over all the others? Obviously given that open source does not equate to security and closed source does not equate to vulnerabilities. It make it even more disconcerting when you see a security or privacy related "Show HN:" being immediately dismissed for choosing closed source.
In the end, choosing software for privacy/security is a matter of trust: How much do you trust a piece of software to protect your privacy/security?
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.
Why? Interested in your reasons. One plausible one is that trusting an author you know can be more practical than examining every line of a massive open source code base. Could that be a reason? Others?
Shotgun blast: open source software is easier to read. Is the quality higher? Depends: there are some terrible vendors, and there are some very shoddy open source security projects. Open source software, with a couple of exceptions, are rarely audited professionally. Widely used open source projects get shaken out for memory corruption and XSS. They do not as a rule get thoroughly evaluated for cryptographic flaws.
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.
The same reason many of us use Windows. All other things being equal, open source is better than closed source, but all other things are not equal. In the end, getting shit done is more important than open source. Unless you are RMS.
User of 1password here too.
One thing I don't like with it is the cleartext metadata. You may not see the secrets, but you can see the category/type of the secret. And things like the URL to where the secret may be used.
Given the type and link to 'hamsterporn.net' I can guess you are a user of some site which may be embarrassing if exposed.
And how do you save and sync the passwords across various machines?
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 LastPass, your account password is your master password. Its hash is stored on their servers, and they have an opportunity to intercept the plaintext whenever you log in.
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.)
I use 2-step auth with LastPass. Although passwords are encrypted on client-side for LastPass too, I understand that if LastPass wants, they can get the master password or password for any specific site. All they need to do is change their client. However, considering 1Password is closed-sourced, if they want, they can do so too. Right?
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.
You log in every day to LastPass, giving them a lot more opportunity to intercept your password without changing anything on the client side. LastPass also has a web interface where you can log in, and you often need to log in there in order to make changes to your account. This can act as an additional attack vector if they were compromised.
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.
There is no straightforward way for AgileBits to quietly steal credentials from a specific target --- they'd have to publish an update that did that to their whole userbase, hope the target actually updates, and they would get caught. It is on the other hand trivial for LastPass to do that, for most of their users, because there is a normal usage flow for that product that involves typing a master password into an HTML PASSWORD input.
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.
To the many readers of this thread who believe they don't care about the integrity of their password vault, just its confidentiality:
The problem is you can't necessarily have confidentiality without integrity.
Sound cryptosystems that provide integrity checking rule out chosen ciphertext attacks against the cipher: in order to submit a ciphertext to such a system, you have to get past a cryptographically secure integrity check.
Without that check, attackers can feed a victim systematically corrupted ciphertexts, which the victim will dutifully decrypt, and observe the behavior of the victim in handling them. This is the basis for a whole family of "error oracle" side channel attacks.
You generally don't want to trust the confidentiality of a cryptosystem that doesn't check ciphertext integrity and rule out manipulated ciphertexts.
As the poster points out: this might matter a lot less for a system that runs purely offline. Or it might not. I lean towards "not a super plausible attack vector". But who knows? Why be OK with bad crypto?