Live data from Hacker News

KeePass – questionable security

news.ycombinator.com

181–190 of 231 posts

Re: KeePass – questionable security

#181
post #28

Earlier quoted context omitted.

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.

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

Re: KeePass – questionable security

#182
post #178

Earlier quoted context omitted.

>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 t…

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 vulnerabili…

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

Re: KeePass – questionable security

#183

Earlier quoted context omitted.

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 cu…

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

Re: KeePass – questionable security

#184

Earlier quoted context omitted.

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 t…

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…

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.

Re: KeePass – questionable security

#185
post #176
post #94

Earlier quoted context omitted.

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…

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 pos…

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?

Re: KeePass – questionable security

#186
post #146

Earlier quoted context omitted.

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.

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

Re: KeePass – questionable security

#187

Earlier quoted context omitted.

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 cry…

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.

Re: KeePass – questionable security

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

Re: KeePass – questionable security

#189

Earlier quoted context omitted.

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

Re: KeePass – questionable security

#190
post #187

Earlier quoted context omitted.

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 so…

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.
Post reply on HN