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