
KeePass – questionable security - sdrapkin
I&#x27;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:<p>The kdbx database is encrypted with AES in CBC&#x2F;PKCS7 mode <i>without</i> 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&#x27;s still MtE - not EtM.<p>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.<p>Byte array comparisons are done with this function from MemUtil.cs:<p><pre><code>		public static bool ArraysEqual(byte[] x, byte[] y)
		{
			&#x2F;&#x2F; 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 &lt; x.Length; ++i)
			{
				if(x[i] != y[i]) return false;
			}

			return true;
		}
</code></pre>
There are many other questionable patterns, code smells, and &quot;I-invented-it&quot; approaches that indicate a non-expert .NET programming skill. They can&#x27;t even implement a Singleton correctly (see CryptoRandom.cs).<p>Has anyone ever done a security audit of KeePass 2.x or does everyone just believe that it&#x27;s &quot;good enough&quot;?<p>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&#x2F;improving it over the years.
======
tptacek
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?

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

~~~
tptacek
I use and like 1Password.

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

~~~
kijin
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.)

~~~
sinatra
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?

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

------
xenophonf
"On The Security of Password Manager Database Formats"
([https://www.cs.ox.ac.uk/files/6487/pwvault.pdf](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.

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

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

~~~
mscrivo
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/](https://support.1password.com/encryption/)

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

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

~~~
tokenizerrr
> carry a gpg private-key file around

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

~~~
chx
May I offer my very recent blogpost on pass + yubikey neo
[https://drupalwatchdog.com/blog/2015/6/yubikey-neo-and-
bette...](https://drupalwatchdog.com/blog/2015/6/yubikey-neo-and-better-
password-manager-pass)

------
FractalNerve
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](https://github.com/keepassx/keepassx)

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

~~~
jfreax
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 :(

------
orahlu
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...](http://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-
cspn_2010-07fr.pdf)

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

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

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

------
negus
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?

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

~~~
StavrosK
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?

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

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

------
yc_Paul
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](http://keepass.info/help/kb/sec_issues.html)

cheers, Paul

------
TimWolla
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...](http://sourceforge.net/p/keepass/discussion/329220/thread/2eac8c83/)

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

------
sdrapkin
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/...](https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L155)

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/...](https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L243)

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

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

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

[https://github.com/joshuadugie/KeePass-1.x](https://github.com/joshuadugie/KeePass-1.x)

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

------
negus
Answering on whether somebody did an audit for KeePass
[http://keepass.info/ratings.html](http://keepass.info/ratings.html) I'm not
sure but one may look at [https://www.allianz-fuer-
cybersicherheit.de/ACS/DE/_download...](https://www.allianz-fuer-
cybersicherheit.de/ACS/DE/_downloads/anwender/software/BSI-CS_003.html) and
[http://www.ssi.gouv.fr/entreprise/certification_cspn/keepass...](http://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-
version-2-10-portable/)

------
hansimglueck
The author is commenting on this thread here:
[http://sourceforge.net/p/keepass/discussion/329220/thread/2e...](http://sourceforge.net/p/keepass/discussion/329220/thread/2eac8c83/)

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

------
vixsomnis
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](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.

~~~
emsy
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).

------
anewhnaccount
[http://www.passwordstore.org/](http://www.passwordstore.org/)

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

~~~
tetraodonpuffer
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

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

~~~
tetraodonpuffer
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)

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

------
Globz
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!

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

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

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

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

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

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

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

------
indutny
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/derivepass) * [https://github.com/indutny/scrypt](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!

------
benkibbey
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/](http://sourceforge.net/projects/pwmd/).

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

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

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

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

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

------
clark800
Open source, open standard, generative password manager with "two-factor"
security using both a passphrase and a private key file:
[http://rampantlogic.com/entropass/](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.

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

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

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

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

------
littlestitious
what is the problem with the singleton?

~~~
sdrapkin
Any takers on that question?

~~~
philbarr
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;
    			}
    		}

~~~
sdrapkin
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?

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

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

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

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

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

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

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

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

------
RRRA
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?

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

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

------
kevinSuttle
Maybe ping the EFF? [https://ssd.eff.org/en/module/how-use-
keepassx](https://ssd.eff.org/en/module/how-use-keepassx)

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

------
AlfaWolph
Any opinion on Mitro?

[https://www.mitro.co/](https://www.mitro.co/)

------
rhaps0dy
And I thought I was safe using Keepass on Dropbox.

Any recommendations for password managing?

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

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

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

------
orblivion
> online threat model

Unless you keep your encrypted password database on Dropbox.

------
voltagex_
Wargh, I use KeePass.

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

