sdrapkin

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.

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.

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.

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.

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

I don't buy this "explanation" for the following reason:

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.

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

You store u/p to your Lawyer's website, which has a copy of your Will. You die and the Executor of your Estate tries to access the Lawyer's website, only to be met with "invalid password".

It turns out that the kdbx on your private server got silently corrupted (ex. fs corruption) ~5 years prior to your death. However, your Dropbox backups only have 30 days of previous kdbx versions.

Can your Executor handle the disappointment?

I believe this issue is grave enough.

Please remember that just because tptacek likes and uses something, do not mean that it has great security.

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.

To those who don't see a problem with leaking timing data:

KeePass goes to great lengths to do in-memory encryption of data. I'm not saying these attempts are properly done, but there is certainly no lack of trying.

The only reason to even bother is assume that this memory can be accessed by an attacker. So either you subscribe to that attack vector and thus must also accept the necessity of avoiding timing attacks, or you reject this threat vector and must question why KeePass engages in all kinds of memory-obfuscation security circus/theater.

1. It would be nice if someone like CodesInChaos (ie. someone with both crypto and .NET expertise) were to casually audit the KeePass 2.x codebase and do a write-up.

2. It would be nice to create a kdbx 3.0 (ix. next-gen) storage format, which does proper AEAD.

I have verified that the CryptoRandom class is part of a standalone library with (1) should be thread-safe since it cannot dictate how it will be used by callers; (2) the authors clearly intended this library to be thread-safe (based on "thread-safe" comments in its source code).

And in all likelihood it is thread-safe - but that's due to being lucky - not competent.

The larger issue is that we have a widely-used crypto software which is clearly (1) not designed well; (2) not implemented well.

How much trust one is willing to place into current and future versions by the same author(s) is up to you.

Step-1: open the above PDF. Step-2: search for "HMAC". Step-3: note which application uses HMAC. Step-4: you should prefer (3) to all others.

Wrong.

Because the main login is HTTPS-secure (I would hope - for a bank), but the change-password feature is not.

Philbarr is correct. The pattern they are using is fundamentally supposed to provide a thread-safe Singleton, and it fails to do that. Is that a security problem in this specific context? No.

But it's a "No" because the authors are lucky in this case - not because they are competent.

Now, that's just one instance of poor skill. There are many more. Are you sure none of them have security implications?

Any takers on that question?

I notice that the "change-password" function of yourbank.com is accidentally being served over HTTP instead of HTTPS. I just need to trick you into changing your password.

I have access to your kdbx db (ex. you sync to Dropbox and I'm Dropbox employee). I can alter the kdbx file to change your password so that it is no longer valid. KeePass doesn't complain at all.

You have a WTF moment and try to change your password over HTTP, while I inspect network packets and grab your new password.

You say "this is far-fetched, non-realistic scenario". I say "this is poor crypto design".

There are 2 problems here. (1) The c# .NET implementation is lacking; (2) the fundamental crypto design of the kdbx database (which is shared by all implementations, in any language) is lacking.