Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KeePass – questionable security

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 231 posts

Re: KeePass – questionable security

#101

Post by breischl »

sdrapkin wrote: post #55
ifdefdebug wrote: post #43

Earlier quoted context omitted.

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.

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.

Re: KeePass – questionable security

#102

Post by sdrapkin »

tptacek wrote: post #91
sdrapkin wrote: post #83

Earlier quoted context omitted.

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/yo…

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

Re: KeePass – questionable security

#103

Post by tetraodonpuffer »

jgrowl wrote: post #79
tetraodonpuffer wrote: post #77

Earlier quoted context omitted.

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)

Re: KeePass – questionable security

#104

Post by FractalNerve »

FractalNerve wrote: post #2

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

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

Re: KeePass – questionable security

#105

Post by rogeryu »

Locke1689 wrote: post #23
feld wrote: post #15

Earlier quoted context omitted.

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

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!

Re: KeePass – questionable security

#106

Post by rogeryu »

freehunter wrote: post #57
rhaps0dy wrote: post #26

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

Well dropbox is excellent and secure in combination with Encfs.

Re: KeePass – questionable security

#107

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

Re: KeePass – questionable security

#108

Post by tptacek »

sdrapkin wrote: post #102
tptacek wrote: post #91

Earlier quoted context omitted.

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/yo…

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

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?

Re: KeePass – questionable security

#109

Post by [deleted] »

philbarr wrote: post #49
ifdefdebug wrote: post #43

Earlier quoted context omitted.

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.

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.

[deleted]

Re: KeePass – questionable security

#110

Post by alkonaut »

philbarr wrote: post #19
sdrapkin wrote: post #16

Earlier quoted context omitted.

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

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.

Post reply on HN