Hacker News new | past | comments | ask | show | jobs | submit login
KeePass – questionable security
366 points by sdrapkin on June 16, 2015 | hide | past | favorite | 221 comments
I've been a long-time user of KeePass. I inspected its 2.x .NET source code today and quickly noticed the following issues which I find quite concerning:

The kdbx database is encrypted with AES in CBC/PKCS7 mode without proper authentication. HMAC is nowhere to be found in the code, other than when used for sha1-totp. There are SHA2 hashes that seem to guard the integrity of ciphertext, while these might catch a typical file corruption they will not prevent malicious tampering. Even if the hashes are used prior to encryption, that's still MtE - not EtM.

KeePass likely does not have an online threat model, so attacks like Padding-Oracle might not be applicable, but a lack of AEAD is IMHO highly concerning because it indicates that the author(s) are winging it when it comes to doing crypto right.

Byte array comparisons are done with this function from MemUtil.cs:

		public static bool ArraysEqual(byte[] x, byte[] y)
		{
			// Return false if one of them is null (not comparable)!
			if((x == null) || (y == null)) { Debug.Assert(false); return false; }

			if(x.Length != y.Length) return false;

			for(int i = 0; i < x.Length; ++i)
			{
				if(x[i] != y[i]) return false;
			}

			return true;
		}
There are many other questionable patterns, code smells, and "I-invented-it" approaches that indicate a non-expert .NET programming skill. They can't even implement a Singleton correctly (see CryptoRandom.cs).

Has anyone ever done a security audit of KeePass 2.x or does everyone just believe that it's "good enough"?

P.S. None of this detracts from the fact that KeePass is a very useful, free utility with a lot of effort put into it. I thank all contributors for making/improving it over the years.




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?


Considering your background and experience, do you have a recommendation for personal level password management?


I use and like 1Password.


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.


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.

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.


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.

[1] http://passwordsafe.sourceforge.net/

[2] https://news.ycombinator.com/item?id=9727522


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


You need to look at the PasswordSafe file format. It can be found here (among other places):

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.


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.

[1]: https://learn2.agilebits.com/1Password4/Security/keychain-de...


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.


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]

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


Everything I've found so far says that opvault is still buggy.

I didn't think v5 was still in beta as I've been happily using 1Password 5.


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.


I like open source but certainly do not believe that it is always the best choice when it comes to security.


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.


What do you think about pass [1]?

[1] - http://www.passwordstore.org/


This one looks really great. Properly following the UNIX philosophy, at last.


Too bad the only way to use 1Password with linux or a BSD is some jaxy browser extension.


Windows version works perfectly well under Wine, though you won't get official browser extension to work for autofill.


jaxy?


http://www.letters4words.com/jaxy.htm

i.e. ass, poorly implemented, bad


Is that open source too or how would you know about their security? Cannot find it: https://github.com/AgileBits


When you went looking for it, did you try Googling for [1password file format]?


No, didn't know that looking just at the file format is sufficient. BTW: I'm no security specialist so excuse me any stupidity here ;)

But couldn't the implementation of parts of the service being flawed? (and you cannot know as it is closed source)


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.

Anything very obviously wrong with this thinking?


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.


With the 1Password syncing feature.


BTSync + 1Password works fine.


I tend to use Dropbox. But there are a multitude of options available to users.


"On The Security of Password Manager Database Formats" (https://www.cs.ox.ac.uk/files/6487/pwvault.pdf) was a good review of KeePass, Password Safe, and others. As I understood it, only Password Safe provided both secrecy and data authenticity.


If only I had heard of this article earlier. I actually downloaded the source code to a bunch of these tools to see if they properly implemented their crypto...

That said, even PassWord safe has some issues. As the article points out, it computes an HMAC over the unencripted contents instead of over the encrypted ones. Encrypt-and-MAC isn't broken like MAC-then-encrypt but its still not as ideal as Encrypt-then-MAC.


"Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the IV, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly."

http://crypto.stackexchange.com/a/224


I think Ferguson and Schneier got this wrong. Here's a useful table from Bellare & Namprempre:

https://www.dropbox.com/s/f4gpc7shjal1nta/Screenshot%202015-...

https://cseweb.ucsd.edu/~mihir/papers/oem.pdf

You generally have two options when it comes to authenticated encryption: use a specialized AEAD mode, in which the details of authentication are settled by the mode itself, or use "generic composition" --- encrypt securely, MAC securely, and safely combine the two operations. Specialized AEAD modes are preferable. But if you're going to do generic composition, the best current practice is encrypt-then-MAC.

Even if you encrypt-then-MAC, you can still forget to authenticate parameters (a good reason not to use generic composition). But if you MAC and then encrypt, you concede to attackers the ability to target the cipher's decryption operation directly with chosen-ciphertext attacks. Those attacks are powerful and have repeatedly broken TLS; they're also the most common form of attack on other cryptosystems (every padding oracle attack is a variant of them).

I wrote a bunch about this here:

http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp...


I'm not saying Schneier is right. More to illustrate his previous thoughts on this.


Interesting, I'm using KeePassX and I've seen the corruption issue; some of the fields are duplicated to other fields in other password entries. It's a little disturbing that this is an issue but I've been using the same KDB file for the last 5? years and it hasn't been completely corrupted.


Thank you! Also, I found a slightly better link, not directly to the PDF but to a page with the abstract and other info:

http://www.cs.ox.ac.uk/publications/publication7166-abstract...


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.


A note to other 1Password users like myself, per the linked PDF 1Password does not use HMAC.


According to [0], it does:

"The OPVault format uses Encrypt-then-MAC for authenticated encryption with AES-CBC-256 for encryption and HMAC-SHA256 for Message Authentication. Key derivation uses PBKDF2-HMAC-SHA512"

[0] https://support.1password.com/encryption/


I suppose some of the results are obsolete. For example, 1P is now already at version 5. Version 2 was about 5 years ago.


Linux support seems to be BETA.


Where did you get that information?


http://passwordsafe.sourceforge.net/news.shtml

Under 28 Dec 2014 it mentions 0.95, but there is a 0.96 from 12 June of 2015 available at

http://sourceforge.net/projects/passwordsafe/files/Linux-BET...


I agree completely.


Password Safe seems interesting. Too bad it's hosted on Source Forge.


What about pass (http://www.passwordstore.org/)? No "funky file formats" -- just GPG and a convenient CLI.


There are two things that bug me about pass:

* Website names are stored in plaintext filenames and directory hierarchies. No confidentiality and no integrity guarantees for those.

* It uses GPG's public-key encryption instead of symmetric-key encription. This integrates well with gpg-agent but it means that you need to carry a gpg private-key file around with you instead of just remembering a passphrase.


May I politely point out https://github.com/catch22/pw, which solves the first issue by using a single password database instead of a subdirectory (for the reason that you mention).


> carry a gpg private-key file around

You could get a yubikey (or other gpg smartcard) ;)


May I offer my very recent blogpost on pass + yubikey neo https://drupalwatchdog.com/blog/2015/6/yubikey-neo-and-bette...


"It's capable of temporarily putting passwords on your clipboard and tracking password changes using git."

Holy moly, thats awesome. I think I'm gonna drop keepass for that.


Been using it for a month now, it's fantastic.


Do you use any syncing mechanism, eg syncing to a repo on Github ? The format should lend to using some remote git repo, but I'm still afraid of the implications of having my passwords in the wild, even encrypted with GPG.


I push it up to an encrypted disk on my VPS behind an ssh connection.

the only people with access to the host are trusted people.

The only way ssh access works without a key is from certain trusted networks. (over a vpn only)


I'm using pass, and like it.


started using pass a few months ago, never looked back


What about KeePassX? That's what I've been using for a long time now. It's not written in C#, but C++

EDIT: source: https://github.com/keepassx/keepassx


KeePassX uses an older database format (KDB) than KeePass 2.x (KDBX4). It also lacks AEAD and is actually less secure than KDBX4 according to the analyses I've read.


Just a general info: KeePassX can read and write the KeePass2 file format, but you have to checkout the git repo manually. It works for me since at least one year.

The problem is the current maintainer, it seems that he has no interest in releasing a new version :(


I don't know about AEAD, but my copy of KeePassX 2.0 alpha 6 seems to work just fine with .kdbx files.

Edit: it is available as a Mac binary on the KeePassX site.


I've looked through the source of KeePassX and it doesn't look complicated, but it requires a crypto expert to say something valuable about it's crypto. Would someone qualified mind sparing some time? I found a port of KeePassX 2 from gcrypt to openSSL ›› https://github.com/WhiteDawn/keepassbb10

Personally I didn't like KeePass 2, so I moved back to KeePassX. You can use ›› https://github.com/dvorka/keepass2-to-keepassx

Here's an awesome QML UI for KeePassX made for Jolla OS, I'm not sure how much work is required to get that to work on Android though. https://openrepos.net/content/jobe/ownkeepass

There is a ›› Python module to read KeePass 1.x/KeePassX (v3) and KeePass 2.x (v4) files – https://github.com/phpwutz/libkeepass

EDIT: TRESOR is an algorithm that runs AES Encryption Securely Outside RAM ›› https://www1.cs.fau.de/tresor ›› https://github.com/ischlecken/TresorLibrary


Well, the language isn't really in question here -- it's the crypto used for the database files themselves.

KeePassX is the old database format and KeePass 2.x+ uses a newer one. I don't know if the database format also resulted in any crypto changes.


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.


Yes, but since this isn't some networked service I'm not as concerned about the general quality of the code. Offline attacks really have to focus on the encrypted password database. If an attacker has local access you're already owned -- they could just modify the application to do whatever they want... or keylog you, etc.

The safety of your database in a world where your keepass database is leaked due to a Dropbox attack or something is what really matters here, IMO.

Did they screw up the crypto so offline attacks are easier?


It's not 100% offline. As you said, if they manage to access your Dropbox, they could theoretically sync an altered database back to you. If the application leaks some information while attempting to open the database or can be made to leak information, that would be bad.


Sync it in an encfs encrypted folder, and it should be fine!


Yea, that's what I've been using for the past 2 or 3 years, I think.


These has been a security audit, ordered by the french ANSSI (French government IT Security agency). This audit resulted in a "CSPN" certificate, which basically means that 35 days were spent by a competent auditor (Thales), and no important vulnerabilities were found in KeePass 2.0 Portable.

Report: http://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-cspn_2010-07fr...


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.


An attacker may be able to read the unencrypted swap space on disk. In this scenario it makes sense to encrypt passwords in memory and store the key in a locked page.


Much like 4th page retractions on stories in newspapers, headlines will always win out in terms of the influence on the readers.

That said, the author of KeePass responded to all the discussions here over on the project forum at SourceForge.

Since a lot of people aren't willing to even visit SF anymore, his notable responses were:

The header validation was fixed as of 2.20 in 2012

The singleton safety he was aware of, and it was only instanced prior to any threading of the application, so there could never be a thread safety issue. He has fixed this anyhow as the performance impact was minimal as of 2.30

The installers available via SF mirroring are signed by the author, so SF can not ever mess with them. They have no concerns about SF doing anything to their project.


Ok, your password database was affected by malicious modification. So what? How it can break the confidentiality of your data? Update: By the way, what's wrong with the bytearray compare code snippet?


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


If you're able to inspect the network packets and the page is over HTTP, then KeePass doesn't even matter at that point. It's game over right there.


Wait, you just inserted an invalid password in my database, how do I change my password? Hell, the only way I'll even realize something's wrong is by trying to log in in the first place, and, if you can see my connection, why would you have me enter a wrong password, rather than the right one?


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


Oh, you mean the account recovery page, not one that requires the old password to change to a new one. I see.


I think he's suggesting that you happen to actually know the right password, and will attempt to enter it after the failed keepass attempt? But then, if you know the right password, you could also visually inspect the keepass data to know it was wrong.


> I can alter the kdbx file to change your password so that it is no longer valid.

How are you generating a kdbx file that has the record where they think it is? The entire file is encrypted en-mass except the header.

You can certainly make a kdbx file that KeePass will open, but it is impossible to make one that will fool the user without more than enough information to just compromise the database.


I have a private server in a datacenter that I put together myself. I use sftp to download/upload my keepass file, I also use a keyfile that stays local and a password for auth. What is the attack vector there?


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.


How are they cracking the 40+ char random alpha numeric password on my box? With fail2ban in place, and it's on a random port.


That answer does not inspire confidence.

1) Random port is not helping against a specific attacker. Get a real firewall 2) Fail2ban is not a real firewall 3) Keys only, no passwords. 40chars is nothing compared to a strong rsa key with a 40char password on it


Wfc.help go ahead and try.


The array comparison? It's literally the textbook example of a timing sidechannel.

Though I won't speculate if it's a real problem here, since I have no idea what data is being compared.


I must admit, I can't immediately see the problem with leaking timing data.

The client (that decrypts the password database) runs on your local computer, and typically places clear-text-passwords into the clipboard during normal use. So if your local computer is compromised you have way bigger problems than timing attacks.


Me neither, I just tried to explain what the other poster /probably/ meant.


It does have a mode that allows you to avoid clipboard sniffers if the program you are targeting supports it.

However most attack vectors on the local machine can usually get a hold of both keyboard and clipboard data making it impossible to prevent sniffing, but that does assume a sophisticated sniffer.


The vast majority of modern malware no longer monitors either the clipboard OR keyboard. It hooks right into the browser or sometimes network stack.

So when you submit a form the malware records what was in the form and just as important where that form was submitted to (i.e. what URL).

Without context (the where) the information (the what) is near worthless. Aside from toy malware nobody actually logs keys anymore, the term "keylogger" is just a word, it isn't literal.

Source: I have looked at the leaked source of commercial (in the black market) malware. A core part of this malware is automation for resale, nobody is going to read through hundreds of pages of someone's clipboard and keystrokes to figure out what page they're on, and it is by far a more difficult route than just breaking into the browser, hooking Win32 functions, or hooking into the network stack before encryption occurs.


Do you care about that kind of side channel for an offline vault?

If your adversaries are on your box while you operate your vault, then you have already lost because they will also have keyloggers, strace, etc.


What if they hack your dropbox account and get a copy of the vault that way? They're not on your box, but now they can try to break into your vault.


Well, the decryption code is open source. And they have the ciphertext. So what does a timing attack give the attacker?

If keeppass removes the possible timing attack, the attacker could just add it back in and use their own client, if they have a copy of your database.


Then a timing side channel is not relevant, because they won't be watching you operate the vault. Right?


Why be OK with bad crypto?


Even if it's the password, it's not a server/client scenario, or interactive authentication, so why would we care about a timing attack?


The problem is that it's usually not true that you can have confidentiality without integrity, because of chosen ciphertext attacks.


Confidentiality isn't your only concern. You should also be worried about integrity and availability. From "On The Security of Password Manager Database Formats":

  Unfortunately, [KDBX4] introduces new vulnerabilities.
  Similarly to KDB, the main problem of this format is
  the lack of authentication of *hdr*. As such, is it
  susceptible to modifications... This modification is
  not detectable by the password manager... if a user
  alters, and then saves, a corrupted database, all
  passwords previously affected by the attack are lost
  forever.

  This attack highlights a remarkable design flaw. Even
  an accidental bit-flip in the *pskey* field, e.g., due
  to a transmission error, cannot be detected, and leads
  to complete corruption of the database. Such
  corruption is unlikely to be immediately detected by
  users, who may subsequently add new entries. Over time,
  the database will be composed of both correct and
  corrupted entries, making it difficult to reconstruct
  the damaged records from a backup.
Which reminds me - I need to migrate back to Password Safe as soon as possible.


Confidentiality is my only concern in the case of malicious modification. Remember, that availability and integrity of your database can be broken without an attacker, just due to hardware problem, for example. So it is up to you to have a cold backup for such a critical asset.


May I emphasize this sentence?

  Over time, the database will be composed of both
  correct and corrupted entries, making it difficult
  to reconstruct the damaged records from a backup.
I don't know enough about cryptography to be able to say whether it's possible to break a particular cryptographic protocol by blindly altering the ciphertext, but I do know plenty about human nature and backups. It's _highly_ unlikely that normal people keep more than a handful of backups. My own personal backup retention limit is on the order of 30 days, and that's with careful planning. Silent, on-going data corruption happening to a password database seems like a very reasonable thing to concern oneself with, especially if one's expectation was that the password manager would throw some kind of data integrity error whenever said database was accessed.


How will you do that? It looks tricky to say the least: http://sourceforge.net/p/passwordsafe/discussion/134801/thre...

EDIT: It looks like you can clear out all the comments and other stuff in the db and export to Keepass v1 CSV and you should be able to import from that.


Hey, thanks a ton for the clue!


This isn't true anymore.

Newer versions store a SHA-256 hash of the header inside the encrypted XML.

At least KeePass >= 2.20 and KeePassX 2.0 >= alpha3 support this. I haven't checked other implementations.


I broke into your e-mail and need to get you to force a password reset on some other account, so I maliciously modify to give you an invalid stored password.


If the attacker already has control of the email address, they can reset the account without going to such lengths--just visit the site and request a password reset.


Could you please provide more details on suggested attack?


KeePass from version 1.24 & 2.20 (in 2012) use header authentication to prevent data corruption attacks. http://keepass.info/help/kb/sec_issues.html

cheers, Paul


Apparently someone reported this thread to the author. You might want to follow the SourceForge issue: http://sourceforge.net/p/keepass/discussion/329220/thread/2e...


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.


Additional evidence of inadequate .NET implementation:

There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory compromise" threat vector is taken very seriously by the authors.

Here's a KeePass function that generates a key: https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...

Does anyone see what the problem is? Hint: disposing "ms" in addition to closing will not fix the problem.

There are ~ 59 instances of this mistake in the codebase. The author(s) seem to come from c/c++ background, and make all kinds of assumptions about how .NET works - except that .NET doesn't work the way they think it works.

The generation of the Master Key: https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...

Note that "pbNewKey" can be sitting in memory forever.

TL/DR: KeePass memory protection is completely ineffective (I only speak for .NET implementation).


Would be interesting to compare the .NET implementation to the "legacy" c version, Keepass 1.x.

https://github.com/joshuadugie/KeePass-1.x


Thanks for your remarks on KeePass; I have at times been a heavy user. I've often wondered about its security (especially the security of its ports) but I don't have the expertise to evaluate it myself. I'm not aware of any audits or systematic analyses as it hasn't received the attention that mobile password managers have.

The truly paranoid keep their KeePass database in an encrypted volume used solely for that purpose.


Answering on whether somebody did an audit for KeePass http://keepass.info/ratings.html I'm not sure but one may look at https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_download... and http://www.ssi.gouv.fr/entreprise/certification_cspn/keepass...


The author is commenting on this thread here: http://sourceforge.net/p/keepass/discussion/329220/thread/2e...

The issues raised in the thread are documented on his webpage here: http://keepass.info/help/base/security.html http://keepass.info/help/kb/sec_issues.html


For anyone who has wanted to switch to KeePassX (to avoid mono dependencies, for instance), but needed the integration with keepasshttp, this project is active: https://github.com/Ivan0xFF/keepassx

I haven't switched yet to Ivan0xFF's port yet (I've been using the auto-type based on window title). I may not actually switch, as the Pass project some others have posted here looks very good as a cross-platform solution (e.g., there is an android app and Firefox plugin) and there are scripts for converting existing databases to the new keystore.


I love KeepassX, but the time it takes to add features and make releases is disencouraging. I don't like that I have to use a fork for months or years because the author is to proud to let in other main contributors (this concerns open source in general, but KeepassX is a great example for this).


http://www.passwordstore.org/


This stuck out to me:

> With pass, each password lives inside of a gpg encrypted file whose filename is the title of the website or resource that requires the password.

What the password goes to can potentially be _very_ sensitive. One of my side projects is a keyring manager; similarly, it feeds the data through GPG. However, the keyring is one file (i.e., all the stuff is rolled together). I also disagree with the design choice of taking the names of the objects on the keyring as a command line argument: they end up in history files. (This is the same argument, really; if you consider the name of the object on the keyring to be sensitive, then you don't want it as a filename (it's not encrypted) or as an arg (it's in a history file… not encrypted).)


It may not be as polished as some of the other options out there, but it is what I use. I am mostly happy with it.

I just wish there was a built in way to encrypt the folder structure to hide what sites I have credentials for.


not built in but if you're on linux you can always overlay ecryptfs on your password safe directory, or just have your passwords in a separate vm entirely that is used only for that


Good points. I've just been too lazy to encrypt the directory myself.

Running a separate vm is an interesting idea that I had not thought of.


I don't have it running yet but I am planning to write something where you have a vm you can connect to with the same/similar command syntax and it would pop up a window of some sort saying 'I received a request for password xyz, yes/no' this way you can have your main system and/or other vms have access to the password store in a controlled manner.

If you have this vm running an FDE install then it would make it also super easy to backup all your passwords, just shutdown the vm and copy the vdi, would only be a few gigs (don't need too much software in this install, just the base system, gpg and whatever ncurses daemon to listen for password requests)


ecryptfs doesn't obfuscate filenames (it is a "stacked" filesystem) so that's not going to do any good. You'll need block-level encryption such as LUKS and a loopback mount if you want to keep that hidden, at least when that partition isn't mounted.


are you sure? The manpage discusses ecryptfs_enable_filename_crypto and ecryptfs_fnek_sig


Uses well-audited GPG, high level crypto functions which makes it difficult for the developer to get the crypto wrong.


Well it sounds like you just did a security audit of KeePass, albeit an incomplete and cursory one. But as a small open-source project, that's probably better than they have now.

Have you considered submitting this analysis to the KeePass team? Or even better, analysis plus suggested code to fix the problems? As a user of KeePass this would be in your interest.

(And as a user of KeePass myself, it is in my interest to encourage experts to help that project out.)


I have been a KeePass user for many years and I always used this in conjunction with a TrueCrypt container meaning that I keep my kdbx file inside the container.

Yes TrueCrypt isn't "safe" but at this point it will take one highly motivated attacker to steal my "important" passwords.

Sadly I am not aware of any audits related to KeePass but I would be happy to read one!


Why do you say TrueCrypt isn't safe? I only skimmed the audit, but it seemed to have an overall positive impression, no?


Well I believe it is safe for my personal purpose but if you read the note the author left on Truecrypt website/software you can clearly read :

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

If I recall the audit was positive but who knows why this message was plastered everywhere when "they" decided to call it quits.


>who knows why this message was plastered everywhere when "they" decided to call it quits.

Because "they" are no longer updating it and at some point there will be security issues that will go unfixed.

Same thing with Windows XP. It didn't immediately fall apart when support ended, but we were pushing so hard for it to go away because it would never see another security update. It's just really, really bad practice to use something that will never be updated, especially a security product.


Windows XP was not audited, and it's been full of bugs since day one, with new vulnerabilities every month, year after year. And it has a huge attack surface. That's hardly comparable to TrueCrypt.

TrueCrypt WAS audited and yes there is a risk of some serious vulnerability being found in the future, but at least we know there's none known for now (not publicly, at least).

That same risk, that some serious vulnerability could be found in the future, also affects all other existing encryption products, since none have been formally demonstrated to be secure.

If I can migrate today to a different product, then I can just prepare to migrate in the future but stay with TrueCrypt until such vulnerability is found, if it ever is. There is, after all, the possibility that none will be found, and it's more likely that none will be found in TrueCrypt than it is in other non-audited products. Why should I switch now?

And why would it be better today to use a product that has not been audited so far but is supposedly still being supported, instead of using one that HAS been audited even if it has been abandoned? Furthermore, currently supported products could be abandoned tomorrow too, or worse: their support could be deficient in the future.

I acknowledge that your argument has some well known heavyweights backing it. Bruce Schneier mentioned this risk about TrueCrypt recently, and then he went to recommend some closed-source solution based on its creator's good vibes. Tom Ptacek also resorted to this newfangled "vibe" method in one of his comments in this very thread. I fail to see the point in all this. Maybe I'm missing something, but I find such reasonings specious.

Edit: grammar.


I never said "don't use TrueCrypt". I'm just explaining why they posted that message. They said "this product will likely have unpatched vulnerabilities in the future" because it will likely have unpatched vulnerabilities in the future. It's unsupported, and using unsupported security software is really bad practice.

Use TrueCrypt, it's probably pretty secure still. A year from now, I might not be able to say the same thing. Two years from now will be even worse. It will get harder and harder to keep recommending it as time goes on and it hasn't been updated. But if anyone is wondering why they posted that message, it's not cryptic. It's just forward-compatibility. Eventually there will be a vulnerability, and it will not be patched.


Repeating a flawed argument does not make it more logical. See my comment above, repeat as necessary.


What do you mean a flawed argument? I'm not arguing anything. I'm explaining why they posted that message. If you want it to be easier to understand, imagine they said "It might not be 2015 anymore". "It's not 2015" is not a true statement, but in a matter of time it will be true. They literally never need to update that text. It's either still 2015 or it is not 2015 anymore. TrueCrypt is either still secure or it is not secure anymore. Either way, the statement "TrueCrypt may not be secure anymore" will always be valid.

If you think TrueCrypt will remain secure forever just because it's been verified as secure in the past, remember that there was a time when computers could not crack a MD5 code. When SHA-1 was considered secure.

I'm not arguing anything, just pointing out the obvious. Secure software today does not mean secure software tomorrow, especially if the software is not getting regular security updates. There is objectively no flaw in that statement.


I just couldn't bring myself to use close source drive encryption software.


Because it's the responsible thing to do. If you are going to stop development, that means outstanding issues will not be fixed.


> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

That did really look the like maintainers flipping the table over and walking away.


TrueCrypt and most other disk encryption software suffer from the same problem mentioned by the OP: lack of integrity protection and thus vulnerable to chosen ciphertext attack. I wrote a transparent encryption filesystem (https://github.com/netheril96/securefs) specifically to address this issue.


Hello!

Nothing about KeePass, but recently I was wondering if I could write a software for deriving the keys from the master secret and seed (i.e. domain name or whatever).

Here is what I have came with:

* https://github.com/indutny/derivepass * https://github.com/indutny/scrypt

It is using dump scrypt implementation (see the second link), and should be pretty easy to verify by cross-reading the source and the spec. Also, there is a boilerplate iOS application which is using `derivepass`'s derivation function and `scrypt` too.

Please let me know if you have any questions!


I've been working on a password manager for a while now. It's been a learning experience in practically every way. I'm not a cryptographer but needed a couple features that the other password managers dont have, and would be too difficult to patch, so I wrote my own. KeePass is really good and user friendly, but like I said, is missing some things I need.

It's hosted on sourceforge which I don't plan on changing since they seem to have wisened up. If you want to try it out or help with development the project page is at http://sourceforge.net/projects/pwmd/.


This is why for work at least, I've kept to a spreadsheet on my workstation, the workstation uses full disk encryption, so I feel this is reasonably secure. For home, I'm nearly 100% apple, so I'm using keychain.


It's better than nothing and likely better than something without source.

Using the CLR which has no guaranteed memory zeroing and has immutable strings and GC and an exposed profiler and debugging APi is a larger concern IMHO.


> It's better than nothing

There are real issues with a false sense of security that you're glossing over here...


I didn't check but I assume they use SecureString.


I'd be surprised if they did and don't forget that it's serialized/deserialized from something which will be hanging around in the GC in the form of a memory backed stream or something too.


> the CLR which has no guaranteed memory zeroing

That's interesting. Can you elaborate?

> and has immutable strings and GC

Immutable strings is a pretty standard feature for a language, right?


Basically, when an object goes out of scope, it isn't de-allocated instantly.

Immutable strings aren't standard; they're an implementation choice.


I suppose that using a random Android Keypass app is just asking for trouble.


Open source, open standard, generative password manager with "two-factor" security using both a passphrase and a private key file: http://rampantlogic.com/entropass/

It only uses the industry standard pbkdf2-sha512 hashing algorithm, with no encrypted database, so it is much simpler and isn't susceptible to these kinds of issues.


It looks like its mainly used for storing site login/passwords. I like to store other things too in password files like credit card numbers, notes ,etc.


Keepass was never meant for corporate use, that much I am positive about. So personally I use gpg through the pass(1) script.

However, for corporate use I must recommend siptrack, a Django-based webbapp, with a xmlrpc api, that tries not so much to replace keepass but rather racktables and keepass.

So it's much more than password management but it uses pycrypto and doesn't try to re-invent encryption. Future plans have it moving to pynacl too.


If you are such a great expert .NET programmer what sees others errors, stop complaining and help him. You have his git and you can pull request.


From my point of view, an authenticator (e.g. HMAC) is only necessary in case of a protocol-based transmission. -> And no, I don't mean to put the file (that is completly read first) on the dropbox. An authentication between the main memory and the CPU is obviously not required.


what is the problem with the singleton?


As noted by other commenters, it's not threadsafe in that two different threads might initialize the class at the same time. However, I don't see that anyone bothered to ask "So what?"

If two threads initialize it at once, they'll each create an instance. One will live for the life of the AppDomain. The other will get used briefly, then thrown away. It's a little messy, but will it cause any actual problems?

It's not holding any important state that must not be lost, and it's not holding on to any resources that might be leaked. The worst case is just that you initialize two RNGs instead of one, so you might get slightly different random numbers than you would otherwise get. But they're supposed to be crypto-secure numbers, not "repeatable random" like you might want for a saved game seed, so that seems like it should be acceptable. Unless there's some deep crypto reason that such a thing would be bad?

The two things that might actually matter are that the GeneratedBytesCount might be wrong, and if someone registered an event handler for the GenerateRandom256Pre event it might get lost. Neither of those things are actually used anywhere in the code, but it is possible that client code could use them.

Bottom line I'd say it's not great, but in the code that they actually have it will not cause any problems.

Aside: technically the class is not marked as threadsafe, but since it's a singleton it should probably be threadsafe anyway.


Any takers on that question?


Well, it's not thread safe but they might not think that's an issue. It looks like this:

		private static CryptoRandom m_pInstance = null;
		public static CryptoRandom Instance
		{
			get
			{
				if(m_pInstance != null) return m_pInstance;

				m_pInstance = new CryptoRandom();
				return m_pInstance;
			}
		}


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?


That's quite harsh. I guess you verified that there are actually different threads able to access this code before making such a statement? For instance, if I make a single-threaded application in the first place then I don't care about thread-safety at all. Because I am not going to need it.


The odds of an singleton being called for the first time simultaneously is abysmal. Usually you even call a singleton first in your own initialization code making errors impossible.

I do agree that technically you are correct and you should wear belt and suspenders, especially if it's a library for third-party consumption and labeled as thread-safe... but still... its pretty esoteric, and only used by the author (I assume) who knows its not thread-safe. Locking isn't exactly without its performance implications either and even though that is neglible it feels unecessary if a race condition is de facto near impossible.


Later on in the class I notice they have this:

		public ulong GeneratedBytesCount
		{
			get
			{
				ulong u;
				lock(m_oSyncRoot) { u = m_uGeneratedBytesCount; }
				return u;
			}
		}
...so if you care about thread safety at some point in your class, then you should care about it during it's initialisation.


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.


Well, "(1) should be thread-safe since it cannot dictate how it will be used by callers" doesn't hold. For instance most of .NET classes are not thread-safe because thread-safety has a cost. So it's a question of documentation (it's well documented in .NET).

But "(2) the authors clearly intended this library to be thread-safe" means that piece of code is bad. So you have a point here.


To be a little more specific, the class itself is not marked as thread-safe. Only the AddEntropy() and GetRandomBytes() methods are so marked. So it would technically be permissible for any other part of the class to not be thread-safe.

But since it's a singleton, having a non-thread-safe initializer is cutting that distinction a little fine.


Given the discussion expressed in this chain and the fact that this is a reasonably small open source project. How many times could a solution have been submitted to the project for this and other noticed issues in the time it was discussed?

I'm sure the author would be very happy to see a sudden influx of contributions to the project, and we'd all have a better product in the end too.

Seems odd the spirit of open source in this respect tends to be more about pointing out the failures of the author than to collectively improve the actual product.


That's a fair point. If this was on Github I might take that to heart and submit a PR. Since it's hosted on Sourceforge, which I don't have an account on and don't want to given their recent behavior, I'm not going to.


That should be a perfectly usable Singleton, if you just stay on one thread? Is the application using multiple threads? Should it be?

Most UI applications sooner or later need at least some basic background processing but if I was writing a simple password manager, I'd most likely just do everything blocking on the UI thread.

That said: for simple patterns like singleton, there is really no reason not to use the builtin and recommended way which is the Lazy<T>.


Here's Jon Skeet's writeup of why this is bad and what you should be doing:

http://csharpindepth.com/Articles/General/Singleton.aspx

Note that using the last example isn't necessarily "the best", it really depends on your requirements.

Nonetheless, a very interesting read.


I assume that they are implying that the code is not constant time. In this snippet, the code bails as soon as a deviation is detected. This can, in theory, allow an attacker to determine the desired value by measuring the time taken to reject incorrect options. I haven't reviewed the code to see if this is actually a problem, but that's my guess for why it was highlighted.


I took it to mean they should use the Linq `x.SequenceEqual(y)` instead (assuming .NET 3.5+) (and x isn't null...).


Wrong.


Honest question. What's wrong with the function? I have a similar function to ironically enough compare Hmacs in an encryption program I wrote in Java and C# When I release the source code for the java version I replaced my function with java's own Arrays.equals though


Timing attacks.

It's not a valid concern in this context, however, because an attacker attempting to bruteforce it can simply code the more efficient comparison and use it.

Timing attacks are a concern on network applications or when considering a block-box type attack.


Don't they also generally depend on the attacker either having access to a steady stream of crypto-events, or being able to cause them? i.e. you either watch a loaded system doing encryption, or create some load and time it yourself.

Neither of which would be relevant to an offline file format.


What about KeePass 1.x?

And considering you can freely copy the database and someone corrupting your own is "only" going to result in you not being able to login, is that really a threat model that is more important with just encrypting everything so they can't be read?


What are the alternatives really? I'd love to get rid of KeePass, it's GUI is awful, it really doesn't support OS X (unless some really technical person installs it). I'm unwilling to use commercial closed, cloud based password databases.


In regards to OSX, Kypass is usable, but it's not great, or free!


Maybe ping the EFF? https://ssd.eff.org/en/module/how-use-keepassx


Does this affect the older version of the format and KeePassX?


Any opinion on Mitro?

https://www.mitro.co/


And I thought I was safe using Keepass on Dropbox.

Any recommendations for password managing?


Well LastPass has had a breach now twice but the integrity of their password database is still holding strong. If you're using Dropbox to share your password database, LastPass having a breach shouldn't be of any concern. I'm fairly certain Dropbox has been broken into more times than LastPass ever will be.

As someone who works in the security industry, I use LastPass and recommend it to everyone. It's no less safe than anything else + Dropbox (I really recommend against using Dropbox... use something like SpiderOak. Dropbox is not meant to be a secure file store) and the convenience is outstanding. Convenient security that everyone uses is much better than inconvenient security that no one uses. And something + Dropbox is pretty inconvenient once you're used to LastPass.


"I'm fairly certain Dropbox has been broken into more times than LastPass ever will be."

Really? Why is that?


Well for one, they already have been broken into. Also they have a member of the board who strongly supports the NSA wiretap program and has very close ties to the highest levels of government.

https://en.wikipedia.org/wiki/Condoleezza_Rice#Criticism_of_...


They way I see it, the downside of LastPass is that it's online, so they could at request of some government or in case of a hack change the code that you execute to capture your master password or do whatever.

This obviously can be done with offline software too, but it's much harder/slower process.

Also I don't quite understand the point of encrypting your database in Dropbox. It's already encrypted. The problem is that someone could monitor how your encrypted file is changing and that way simplify decryption. And that doesn't change even if you encfs. Unless the point of it is to hide that you have password db in Dropbox.


How would that happen with 2FA set up? Even if they have your master password, how do they copy your Authenticator code or YubiKey or whatever else you might use?

I see people struggle with offline password managers to the point where they never use them or they get burned once because they're somewhere without access to their database and they stop using them. LastPass alleviates all of that. People make the same claims about TouchID (it's not secure, look at these theoretical bypasses, etc) but the fact is (which I thought I pointed out earlier) that convenient security is better than no security and no security is what you're going to get.

You think the government can't download things from your Dropbox and you think they can't decrypt your database? We know better now. The fear of "what if the government does" is completely gone. Even if they can't get to your password, they'll just go straight to Google or worst case scenario, straight to AT&T. The difference between encrypting like SpiderOak vs uploading an encrypted file like DropBox is that DropBox can hand over your password database to anyone they want to give it to. SpiderOak can't. You don't need to try to hide the fact that you have a password database, no one can tell in the first place. Security through obscurity isn't no security, it's just poor security and poor security is better than nothing (and far better when combined with good security).

You're using a password manager to keep your accounts safe from petty criminals and identity thieves, not from APTs or shady governments. And if you're using DropBox, the government probably already has it. I guess you'd have to ask Condoleezza Rice about that.

Use whatever you want, everyone has different needs and opinions. But I will continue recommending LastPass (and at the very least, strongly recommending against whatever + DropBox). Like I said, it's no less secure than whatever + DropBox. But it's a heck of a lot more convenient.


I am less worried about NSA attacks on my lastpass. To be honest they could get somebody into my house and attack my computer directly.

If the NSA wanted info from you they have out of channel attacks that can get things more directly. I may have a 20 character password on my gmail but google can hand all that data over.


Well dropbox is excellent and secure in combination with Encfs.


Encfs didn't survive its security audit very well: https://defuse.ca/audits/encfs.htm (I don't know how much has it improved since then, though)


Pass uses GPG and txt files in a directory. http://www.passwordstore.org/

It is basically a set of shell scripts on top of gpg, simple and very easy to back up using Dropbox/Bittorrent Sync.

You can also copy just one website over to a new computer easily since each website is a single plaintext file in your ~/.password-store directory.


Password Safe is supposed to be the strongest. I like KeePass 2's user interface a _lot_ better, which is why I'd originally migrated away from Password Safe. However, due to KDBX4's inability to detect data corruption, I plan to migrate back to Password Safe in the very near future.


More about password safe: https://www.schneier.com/passsafe.html


Too bad it is hosted on SourceForge.


Password Gorilla is compatible with the PasswordSafe DB v3 file format, and is not hosted on SourceForge:

https://github.com/zdia/gorilla


Oh man, I'd forgotten about that. :(


Be sure to 2fa Dropbox too. Excluding hackers getting in to the server, it'll prevent people from being able to login as you.


> online threat model

Unless you keep your encrypted password database on Dropbox.


Wargh, I use KeePass.


It is so annoying. It must be something you know (Passcode), you are (Iris) or something you have (Key).

In case of Passwords, it is something you know. With limitations to the site (at least X Characters, small and capital, one number but not at the beginning, no number at the end, at least one special...). Some Banking sites even only allow a scary limited amount of characters (I think Schwab allows only 7 and no special characters).

Regarding a PW Manager: I found them all annoying and one has corrupted the PW database several times, resulting in a loss of the passwords.

My solution: A plain textfile with all my passwords. (I use Linux with an encrypted partition). If this is not secure enough for you, encrypt it with GPG.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: