I'm quite surprised to see this on HN homepage, I mean this is such a great and popular tool that I would expect everyone to know about it and find it just an obvious link not to upvote.
Does anyone know if there is a lib to read and write into keepass archives programmatically, e.g. from a C# app? that would be quite useful to manage in an automated way some credentials for production systems, sharing tha archive via versioning repos in a team.
The first link in that link describes a flexible command line you can use for a number of operations. The second describes how you can write c# like script files that will be loaded. Both require the KPScript extension. Why not just bundle/reference keepass.exe since its a .net executable? see http://stackoverflow.com/a/9028433/259130 . Also if you haven't tried it yet you might want to try messing about with https://www.linqpad.net/ (run c# as script file/interactively) like he did.
The dependencies for this seem more appealing than KeePass but unless my searching skills are not up to par there don't appear to be any browser autocompletion plugins.
In fact, I usually just copy the password with Ctrl-C and the username with Ctrl-B. You can configure a secure clipboard erase after n seconds.
One thing I really wish had better support is ssh-based entry-level sync of databases[1]. Keepass has a plugin for it but I don't know the status for KeepassX 2 (currently in a non-stable release state). If I could point KeepassX at an SSH remote path and have it transparently sync at the entry level it'd be almost perfect.
I've used autotype before and it works fantastic, but you have to be super careful with it. It basically switches back to the last window you had open and immediately types your username and password in. It is very easy for this to type your credentials into the wrong window. When using it (I used it a lot for vmware sessions through an rpd connection), I would find myself clicking back and forth from the target window to keepass a couple times to ensure I was going to hit the right window.
What are the differences? I'm using 1.x and haven't found it lacking yet. I tried 2.x for a work password db and didn't find anything that really stuck out from my casual usage of it.
One difference I immediately see is 2.x doesn't use lock files. If you sync password DB's using Dropbox, all you need to do is relaunch the software to open the updated DB.
I love this product. I found it via a stackoverflow question about how to store credentials safely. I started using it over a month ago because I have just stored everything in text files (ips, usernames, pass, secure urls, etc...) and wanted to be more organized and secure.
It is GPL and you have the control over your keyfile(s). A browser plugin for the commercial services could any time sneak evil bits in, so you might feel less safe with them (they could upload your masterkey or your decrypted keyfile, when asked by the NSA).
Evil bits could just as easily sneak into Keepass if the author wanted to. It would require someone else constantly auditing all commits along with verifying binary builds posted on the website match the current source's compiled output.
Edit: my above comment is just to prove a point. We put trust in a lot of the software we run. Software being open source does provide some safety, but very very few people will go through the effort to make that verification.
I've been using both for a while and can say that they seem fairly equivalent. KeePass by default doesn't exit after a timeout which is something I don't enjoy remembering to configure on install.
It is convenient enough - and when it comes to such sensitive digital areas, then I defenitely prefer to take a conservative position over cloud based and client side encrypted solutions.
I put a tiny Truecrypt container on my file hoster (HiDrive, Skydrive, Dropbox, etc.) in which I store the KeePass keystore. The keystore itself can't get decrypted, but in case AES has weaknesses one first needs to crack the triple encryption of AES+Serpent+Twofish of the Truecrypt container.
You've added another dependency into the mix here.
I've been comfortable storing my database in Dropbox, with a decent length master password (15char+) on the assumption that it uses a high quality hash that would make bruteforcing the encryption impractical, without having to add another layer of encryption above it. Curious if others feel this is a reasonable assumption?
Great! What I did was download Lastpass Portable Version and then exported it as a CSV and imported it into KeePass. KeePass already seems more ideal than LastPass.
That was my biggest issue with switching as I have hundreds of entries in LastPass. I spent a few hours moving over my most important/frequently used entries. For the "leftovers", I simply move 'em from LastPass to KeePassX as I need/use them.
Just make sure you don't have some sort of system-wide backup in-place that's going to backup the CSV file, in clear-text, on your disk during the migration.
Looks like the menu widget and icons are not using GTK for whatever reason. It may be worth pinging the KeePass developers with a screenshot showing that the GTK theme is not being respected properly when rendering the menu - the menu even looks odd using a light-colored theme like Clearlooks because it doesn't match the theme.
I recommend OneShallPass (http://oneshallpass.com) over KeePass. It's open source and auditable like KeePass, but:
1) It doesn't have to be compiled or installed, since it's just a monolithic HTML page with all JS/CSS inline.
2) It has a free, optional hosted service that stores encrypted passwords with pure client-side decryption, so you can get your passwords from any web-enabled device without having to trust the host.
Additional features:
- It works offline.
- You can import or export your passwords in CSV form.
- If you choose to delete your account, it is immediately and irrevocably destroyed.
> 2) It has a free, optional hosted service that stores encrypted passwords with pure client-side decryption, so you can get your passwords from any web-enabled device without having to trust the host.
This is an unbelievably audacious security shell game; I can't really believe this nonsense idea has somehow managed to gain traction.
The server is ephemerally delivering the code that supposedly encrypts your content securely.
By saving the HTML file and opening your local copy. You can audit the code and verify yourself that nothing will go over the wire unencrypted to their servers, so you get the benefit of them hosting the encrypted passes without having to trust them with your data. If you want it available anywhere, you don't want to save the file locally, and you don't trust the host, just host it yourself or grab it from Github.
> And hoping it includes all the java it needs, and doesn't go out and pick up some 3rd party library?
What Java? It's a self-contained, monolithic HTML file with JS and CSS inline. What dependency are you imagining you're not going to have?
> You would have to audit it to ensure it never includes everything else, or posts anything externally with every release.
Exactly as you would with KeePass, or any other conceivable solution. If you don't want to audit future releases, save the last one you audited and use that.
Don't forget to audit your browser (the thing without a version number anymore and with various metatemplates and it dynamically downloads on every load) and it's implementation of ECMAScript. But everyone already knew that.
By that logic, you can't know KeePass is safe without auditing Mono, your compiler, your checksum tool, the editor you used for the audit, the logic gates of your CPU, etc. Auditing anything is impossible.
If you can't get a copy of Firefox that you trust hasn't been altered as part of a conspiracy to make you believe OneShallPass is a legit password manager, you've got bigger problems.
1) It doesn't have to be compiled or installed, since it's just a monolithic HTML page with all JS/CSS inline.
The obvious and huge difference then would be that KeePass requires a password or key file to open but an HTML page requires only a browser or text editor. Major, major difference to me.
> The obvious and huge difference then would be that KeePass requires a password or key file to open but an HTML page requires only a browser or text editor. Major, major difference to me.
Did you spend even two seconds looking at OneShallPass? Literally the second thing on the page is a field asking for a passphrase, and yet you came here to complain that it doesn't require a passphrase.
The passwords are encrypted. The fact you can read the decryption algorithm in your text editor doesn't let anyone know your passwords, any more than you being able to download and read the source of KeePass lets you read other people's KeePass passwords.
I've been having it on my various systems (Windows, Linux, Android) in the sidelines for a couple months, and after initial fiddling, still haven't actually started using it.
This is mostly because I don't want to have to deal with copy-pasting my password between the KeePass app and the browser (where most of my passwords are needed). Luckily, there are autofill plugins that exist for Chrome [1], Firefox [2], and Android [3].
However:
- said plugins work with KeePass2 which on Linux the GUI theme to the point of being almost unusable (as a C# app using WinForms, it doesn't respect GTK/Qt themeing well).
- getting the KeePass2 plugin needed for the browser plugins requires jumping through hoops on Linux and I haven't gotten it to work (yet?).
- I'm sharing my KeePass database on DropBox (with its own security considerations...) to synchronise between the different systems and...
- The Android app just won't open the shared database.
So it feels like I'm 60% of the way there, but I still don't have a usable system. Hints appreciated.
For personal use, I've been using LastPass for a few years but have been slowly migrating away from it in recent months. I'm switching to KeePassX which I already use for $work-related data. (I have intentionally avoided the Mono-based applications.)
KeePassX has similar "auto-fill" functionality as well. It's not as perfect or as seamless as LastPass but it is definitely usable (after a bit of one-time per-site tweaking in some cases). Having recently decided that using LastPass presents a non-zero risk, the extra effort I have to spend w/ KeePassX is certainly worth it, IMO.
Although I don't do it now, I have in the past kept my password databases in Dropbox. With Dropbox also installed on my iPhone, I am able to access my password databases use "MiniKeePass" on iOS without any issues.
In addition, there are Windows, Linux, and OS X versions of KeePassX and all of them can open up my .kdb files without any issues.
I have the LastPass plugin installed in Firefox, which I use 95% of the time. I also have the mobile app installed on my iPhone.
Why the switch? Recent revelations WRT NSA & the iPhone, recent reports of other plugin developers selling their plugins to shady actors, and my general belief that the most sensitive credentials I have are safer on machines under my control instead of "in the cloud".
I work for an ISP and also manage systems and networks for schools, government organizations, health care facilities, investment firms, law offices, you name it. If someone were to gain access to all of my stored credentials, they could do a LOT of damage -- to myself as well as many, many others.
While I have no reason to believe that there's anything wrong with LastPass (from a security point of view), I am certain that the level of risk is lower with, i.e., KeePassX.
As others have said, why migrating away from LastPass? They definitely seem to be doing things properly in terms of security and I've been very happy with the security, as well as the ease of use when I set it up on a new machine.
The problem with in-browser password management is that the attacker does not need to escape the browser. Code injection (via XSS or a browser exploit) into a running extension is likely easier than defeating the seccomp-IPC implementation or the AppArmor/SELinux profiles which protect the system. Addons like LastPass are mainly concerned with remote server weaknesses, but nothing will protect the browser from itself.
Another opinion: It's weird loading a browser+environment for non-browser passwords (SSH, HTTP/WebDAV, etc), and it's equally weird managing the passwords separately.
I have the LastPass plugin installed in Firefox, which I use 95% of the time. I also have the mobile app installed on my iPhone.
Why the switch? Recent revelations WRT NSA & the iPhone, recent reports of other plugin developers selling their plugins to shady actors, and my general belief that the most sensitive credentials I have are safer on machines under my control instead of "in the cloud".
I work for an ISP and also manage systems and networks for schools, government organizations, health care facilities, investment firms, law offices, you name it. If someone were to gain access to all of my stored credentials, they could do a LOT of damage -- to myself as well as many, many others.
While I have no reason to believe that there's anything wrong with LastPass (from a security point of view), I am certain that the level of risk is lower with, i.e., KeePassX.
I looked into LastPass last week. It looked great on desktops, but on Android it's basically a separate browser. That's a no-go for me, I'd rather stick with Chrome
Keepass proper has a global Ctrl+Alt+A shortcut that automatically types in your username and password into the form: I've found it works fine on the majority of sites (almost everyone uses username-tab-password-enter, but for the few that don't, you can specify a custom auto type format in keepass. It even has an option to obfuscate the typing to trick keyloggers).
For android, I recommend Keypass2Android: it comes with a custom keyboard you can enable temporarily, which inputs your password without going through the android clipboard. I use it with the dropbox app as well, I'm not sure why it's not working for you.
KeePassDroid is another good one for Android. It does use the clipboard though by giving you two notifications to click on. One for the username, and one for the password of the chosen credentials.
I've been using Keepass2 for several years and I couldn't be happier. Although its slightly buggy at times on Linux and getting it running on Mac can be a bit difficult.
The only problems I have with KeePass are it is Windows-first (though I know there are third part native clients for Linux, OS X, Android etc) and that browser integration is not comparable to something like LastPass. I do want to get away from LastPass as my trust in the cloud (especially US based cloud services) took a dive after Snowdon.
For those looking for something ultra lightweight, I highly recommend pwdhash (http://pwdhash.com). It's not a password manager, it's just an open source hashing algorithm that protects you from sites storing your password poorly. Instead of depending on them to store your password in a one-way hash, it does it on your end before sending the password to the site.
The algorithm is very roughly base64encode(hash(password + domain)), and then truncated to match your original password length.
The form on the site is just a demo (and backup if you need to use it outside of your own browser). What you really want is the extension (for most major browsers). You can type in the same strong password to every site and the extension will always hash it to the site specific password so you don't have to worry about them storing it poorly. You can also use unique master passwords for certain sites, if you so choose.
Oh nice, I've been thinking about something like this a lot lately. I don't really like the idea of truncating the generated password, though. I'd rather it use a proper KDF and fill the password field to its limit.
I think the reason they did it is because a lot of sites have maximum password lengths that would prevent the full output. Those are exactly the type of sites that you want to be using something like this on.
Sure, but as long as the site actually sets the password length limit on the field it shouldn't matter. It will obviously be truncated a lot of the time, but I'd rather it be truncated at thelongestpossible point.
From looking around it seems like the reason is that they wanted the visual representation of typing the password to reflect the number of characters you actually typed as you type them. I'm not sure if this comes out true, though, as I can't actually get it to work in chrome.
The chrome extensions requires putting '@@' at the start of the password field. This turns it yellow to indicate it is now active for that field.
>Sure, but as long as the site actually sets the password length limit on the field it shouldn't matter.
Yes, but in my experience sites rarely implement this. If they do, it's probably inconsistent (i.e. different limits on the login field, create account, and reset password fields).
Yep, tried that. Just doesn't do anything at all as far as I can tell. Maybe it has issues with linux chromium? I dunno.
Re password lengths, my experience is that they usually truncate on the server side at that point, rendering it pretty moot. But yes, I do see this problem. I'm just not sure you're not going to run into it either way if you're practicing good password hygiene. I'd still prefer it make an attempt at adding as much difficulty to the password as possible, though.
I built something like this a while back* but with a slightly more complex algorithm to make it more difficult to find the master password from a set of hashes. I ended up ditching it in favor of KeePass mostly because if a site is hacked and your plaintext hash is compromised there isn't a clean way to generate a new password every time.
A while back I set off half a day to setup KeePass, not that setting up KeePass takes that long - but generating random passwords for all the sites that I use did. KeePass is great, there's an app for Windows Phone that is great and there is a third party plugin for Chrome that will both enter and help me save passwords when the vault is open.
Great software, everyone should be using password vaults.
Does anyone know a way to read usernames/passwords from a KDBX file hosted on Dropbox/Google Drive (similar to 1passwordAnywhere)? That way, if I'm at a new computer, I do not need to download KeePass to open my KDBX.
137 comments
[ 3.3 ms ] story [ 180 ms ] threadDoes anyone know if there is a lib to read and write into keepass archives programmatically, e.g. from a C# app? that would be quite useful to manage in an automated way some credentials for production systems, sharing tha archive via versioning repos in a team.
Although since I am studying C#, VB and Java I would be interested to find out the answer to that.
[1]https://www.keepassx.org/
In fact, I usually just copy the password with Ctrl-C and the username with Ctrl-B. You can configure a secure clipboard erase after n seconds.
One thing I really wish had better support is ssh-based entry-level sync of databases[1]. Keepass has a plugin for it but I don't know the status for KeepassX 2 (currently in a non-stable release state). If I could point KeepassX at an SSH remote path and have it transparently sync at the entry level it'd be almost perfect.
[1]: http://keepass.info/help/v2/sync.html
The source[1] is also on GitHub too. As a non-c++ programmer, I found it pretty easy to follow along.
[1]: https://github.com/keepassx/keepassx
I use 1.x mostly as a backup.
Very happy with the combination.
Edit: my above comment is just to prove a point. We put trust in a lot of the software we run. Software being open source does provide some safety, but very very few people will go through the effort to make that verification.
https://www.schneier.com/passsafe.html
It is convenient enough - and when it comes to such sensitive digital areas, then I defenitely prefer to take a conservative position over cloud based and client side encrypted solutions.
I've been comfortable storing my database in Dropbox, with a decent length master password (15char+) on the assumption that it uses a high quality hash that would make bruteforcing the encryption impractical, without having to add another layer of encryption above it. Curious if others feel this is a reasonable assumption?
http://i.imgur.com/NQYDBQ8.png
I like how it [the .kdb file, really] can be accessed//written_to in both Linux and Windows, and that it has a usb-portable version.
1) It doesn't have to be compiled or installed, since it's just a monolithic HTML page with all JS/CSS inline.
2) It has a free, optional hosted service that stores encrypted passwords with pure client-side decryption, so you can get your passwords from any web-enabled device without having to trust the host.
Additional features: - It works offline. - You can import or export your passwords in CSV form. - If you choose to delete your account, it is immediately and irrevocably destroyed.
This is an unbelievably audacious security shell game; I can't really believe this nonsense idea has somehow managed to gain traction.
The server is ephemerally delivering the code that supposedly encrypts your content securely.
How do you not have to trust the host?
By saving the HTML file and opening your local copy. You can audit the code and verify yourself that nothing will go over the wire unencrypted to their servers, so you get the benefit of them hosting the encrypted passes without having to trust them with your data. If you want it available anywhere, you don't want to save the file locally, and you don't trust the host, just host it yourself or grab it from Github.
You would have to audit it to ensure it never includes everything else, or posts anything externally with every release.
Not my cup of tea, personally.
What Java? It's a self-contained, monolithic HTML file with JS and CSS inline. What dependency are you imagining you're not going to have?
> You would have to audit it to ensure it never includes everything else, or posts anything externally with every release.
Exactly as you would with KeePass, or any other conceivable solution. If you don't want to audit future releases, save the last one you audited and use that.
Really, auditing this is impossible.
If you can't get a copy of Firefox that you trust hasn't been altered as part of a conspiracy to make you believe OneShallPass is a legit password manager, you've got bigger problems.
The obvious and huge difference then would be that KeePass requires a password or key file to open but an HTML page requires only a browser or text editor. Major, major difference to me.
Did you spend even two seconds looking at OneShallPass? Literally the second thing on the page is a field asking for a passphrase, and yet you came here to complain that it doesn't require a passphrase.
The passwords are encrypted. The fact you can read the decryption algorithm in your text editor doesn't let anyone know your passwords, any more than you being able to download and read the source of KeePass lets you read other people's KeePass passwords.
I wouldn't recommend using it yet, but any feedback would be super helpful.
This is mostly because I don't want to have to deal with copy-pasting my password between the KeePass app and the browser (where most of my passwords are needed). Luckily, there are autofill plugins that exist for Chrome [1], Firefox [2], and Android [3].
However:
- said plugins work with KeePass2 which on Linux the GUI theme to the point of being almost unusable (as a C# app using WinForms, it doesn't respect GTK/Qt themeing well).
- getting the KeePass2 plugin needed for the browser plugins requires jumping through hoops on Linux and I haven't gotten it to work (yet?).
- I'm sharing my KeePass database on DropBox (with its own security considerations...) to synchronise between the different systems and...
- The Android app just won't open the shared database.
So it feels like I'm 60% of the way there, but I still don't have a usable system. Hints appreciated.
[1] https://chrome.google.com/webstore/detail/chromeipass/ompiai... [2] https://addons.mozilla.org/EN-us/firefox/addon/passifox/ [3] https://play.google.com/store/apps/details?id=com.hanhuy.and...
Personally, I don't like the idea of browser plugins and I'm perfectly happy using copy and paste.
[1]https://play.google.com/store/apps/details?id=com.android.ke...
KeePassX has similar "auto-fill" functionality as well. It's not as perfect or as seamless as LastPass but it is definitely usable (after a bit of one-time per-site tweaking in some cases). Having recently decided that using LastPass presents a non-zero risk, the extra effort I have to spend w/ KeePassX is certainly worth it, IMO.
Although I don't do it now, I have in the past kept my password databases in Dropbox. With Dropbox also installed on my iPhone, I am able to access my password databases use "MiniKeePass" on iOS without any issues.
In addition, there are Windows, Linux, and OS X versions of KeePassX and all of them can open up my .kdb files without any issues.
LastPass user here, wondering why?
Plus I wouldn't trust any browser plugin with passwords
I have the LastPass plugin installed in Firefox, which I use 95% of the time. I also have the mobile app installed on my iPhone.
Why the switch? Recent revelations WRT NSA & the iPhone, recent reports of other plugin developers selling their plugins to shady actors, and my general belief that the most sensitive credentials I have are safer on machines under my control instead of "in the cloud".
I work for an ISP and also manage systems and networks for schools, government organizations, health care facilities, investment firms, law offices, you name it. If someone were to gain access to all of my stored credentials, they could do a LOT of damage -- to myself as well as many, many others.
While I have no reason to believe that there's anything wrong with LastPass (from a security point of view), I am certain that the level of risk is lower with, i.e., KeePassX.
Another opinion: It's weird loading a browser+environment for non-browser passwords (SSH, HTTP/WebDAV, etc), and it's equally weird managing the passwords separately.
Why the switch? Recent revelations WRT NSA & the iPhone, recent reports of other plugin developers selling their plugins to shady actors, and my general belief that the most sensitive credentials I have are safer on machines under my control instead of "in the cloud".
I work for an ISP and also manage systems and networks for schools, government organizations, health care facilities, investment firms, law offices, you name it. If someone were to gain access to all of my stored credentials, they could do a LOT of damage -- to myself as well as many, many others.
While I have no reason to believe that there's anything wrong with LastPass (from a security point of view), I am certain that the level of risk is lower with, i.e., KeePassX.
For android, I recommend Keypass2Android: it comes with a custom keyboard you can enable temporarily, which inputs your password without going through the android clipboard. I use it with the dropbox app as well, I'm not sure why it's not working for you.
I need to give KeePass2Android a try.
http://www.techdirt.com/articles/20130620/15390323549/nsa-ha...
The algorithm is very roughly base64encode(hash(password + domain)), and then truncated to match your original password length.
The form on the site is just a demo (and backup if you need to use it outside of your own browser). What you really want is the extension (for most major browsers). You can type in the same strong password to every site and the extension will always hash it to the site specific password so you don't have to worry about them storing it poorly. You can also use unique master passwords for certain sites, if you so choose.
From looking around it seems like the reason is that they wanted the visual representation of typing the password to reflect the number of characters you actually typed as you type them. I'm not sure if this comes out true, though, as I can't actually get it to work in chrome.
>Sure, but as long as the site actually sets the password length limit on the field it shouldn't matter.
Yes, but in my experience sites rarely implement this. If they do, it's probably inconsistent (i.e. different limits on the login field, create account, and reset password fields).
Re password lengths, my experience is that they usually truncate on the server side at that point, rendering it pretty moot. But yes, I do see this problem. I'm just not sure you're not going to run into it either way if you're practicing good password hygiene. I'd still prefer it make an attempt at adding as much difficulty to the password as possible, though.
* https://github.com/goatslacker/hash
* A site may be able to compromise the browser extension.
* You have to memorize several passwords because sites require different length passwords.
* The code has been reviewed less.
* A key-store like KeePass can store many original passwords, not just one hashed password.
* It doesn't have a non-browser app, so I had to copy paste passwords from the browser, while KeePass has Alt-Ctrl-A.
Great software, everyone should be using password vaults.