5 ms·
Curious, who is "compiling KeePassX for Linux themselves" when it's in the Ubuntu and Debian repos? I haven't checked Arch or other distros but KeePassX is a wi
by tombrossman 10y ago
Curious, who is "compiling KeePassX for Linux themselves" when it's in the Ubuntu and Debian repos? I haven't checked Arch or other distros but KeePassX is a widely used and active project, and I suspect it is available in many package managers. I wasn't aware that people were having to compile it from source (and I agree this would be more intimidating to new users).
- nikcub 10y ago> Curious, who is "compiling KeePassX for Linux themselves" when it's in the Ubuntu and Debian repos? It's in the OP: "I highly recommend using KeepassX as a password manager, secured using a key file and not a password. Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions, you CANNOT afford a vulnerability inside the password manager."
- tombrossman 10y agoThanks, I saw that but was hoping people would not actually bother - that's deep into 'tinfoil-hat' territory. If you are already running a Linux distro and trusting the repos for OS updates, it isn't a big stretch to assume their build of the password manager is exactly as safe as the OS updates, and trusting one but not the other is pure folly.
- wallace_f 10y agoThis is also exactly my intuition here, but I'm hoping for others to comment here as well.
- slavik81 10y agoKeypassX 2.0 was in alpha for years (though I never noticed a bug). I don't think it was available in distribution packages until quite recently. That being said, I'm decent with C++, and yet auditing its code is a little daunting.
- fauigerzigerk 10y agoWhy is it a good idea to use a key file instead of a password? Any malware I catch could use the key file to access all my passwords or is there something I'm not understanding?
- giancarlostoro 10y agoI would personally use a combination of both. If you keep the key file on a USB thumb drive that you only insert when you need to unlock your files I guess it works out well then.
- fauigerzigerk 10y agoThat sounds like a better idea, but I still don't really see the upside as compared to remembering one long passphrase.
- jwives 10y agoI use a combination of password and key file so that I can worry less about someone shoulder surfing or otherwise observing the input of my password. My password database is stored on a USB key that I carry with me, with a regular copy made and securely stored. Key file is stored on devices I use, in a directory restricted to my own access and on a drive which is encrypted. An encrypted copy is also stored on the USB key with the password database; this can be decrypted using a GPG, key stored on a yubikey and also carried; if a device can be trusted enough, this is how I move the key file around. Access to the database requires 3 things rather than two. A long passphrase could be recorded by an observer, who could then take my USB key. The key file ensures that they still do not have all that they need.
- giancarlostoro 10y agoThe idea is, if the <attacker> doesn't have the key file, it doesn't matter what password they try, they wont get in.
- ahartman00 10y agoI'd recommend both, keepass supports that. Keepass supports using a secure desktop to prevent keyloggers[1], but you never know with some of the usb keyboard exploits[2], and good old fashioned looking over your shoulder. While keepass has protection against dictionary attacks[3], why not use a keyfile? you can put it on a flash drive, and now noone can access your passwords without that usb key. (obviously make sure you have multiple copies of your keyfile :) 1. http://keepass.info/help/base/security.html#secdesktop http://keepass.info/help/base/security.html#secdesktop 2. http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/ http://arstechnica.com/security/2014/07/this-thumbdrive-hack... 3. http://keepass.info/help/base/security.html#secdictprotect http://keepass.info/help/base/security.html#secdictprotect
- elcapitan 10y ago> always look over the source code for rogue functions I don't really understand the reasoning behind that - so rather than trusting a proven OS and its packages with lots of eyes on the critical code, I should rather read the code of a cryptographic product and then make a decision based on that? Common advice is not to write crypto code yourself, but reading it and deciding that there might be a backdoor based on gut feeling is right? And having identified some stuff I don't understand, then decide for another program that is goofy but easier to read, and compromise security?
- maglavaitss 10y agoIt's more about looking over the source code of the KeepassX app and just that (not all applications you use, of course we have to trust some of them), the code changes are (when there are changes) ~10 lines a month, not a huge amount to check.
- elcapitan 10y agoWhat about all its dependencies? What if someone made some unsuspicious changes in a UI library that it uses that have a side effect on the security of KeepassX?
- maglavaitss 10y agohttps://github.com/keepassx/keepassx https://github.com/keepassx/keepassx If libgcrypt, QT, zlib get compromised I guess it's game over, but it's a long way to go, it will get noticed.
- elcapitan 10y agoBut that's the same argument that I was making about KeepassX itself before. So if I'm trusting for the dependencies to get watched well for not being compromised, why then look into KeepassX itself, wouldn't that apply for the app itself as well?
- maglavaitss 10y agoOnly got in the Ubuntu repos lately and not everybody uses Debian and derivatives.