Using keepassxc-cli password in shell script

[jagrg]

Hello, I'm wanting to use keepassxc-cli in a shell script, and I'm wondering if there are any drawbacks to using a password file. For example:

PASSWORD=$(gpg --decrypt $HOME/.passfile.gpg 2> /dev/null)
echo "$PASSWORD" | keepassxc-cli ls -q -R -f /path/to/db -k /path/to/keyfile | fzf

And is it safe/safer to use read with the -s (no echo) option instead? For example:

IFS= read -s -p "Password: " PASSWORD
echo "$PASSWORD" | keepassxc-cli ls -q -R -f /path/to/db -k /path/to/keyfile | fzf

Or is there some other way of doing this? This would make it easy to fuzzy find entries and assign keys to run keepassxc-cli commands from the fzf menu. Thanks for the guidance.

[Inesgor]

I like this idea. How about using gpg to make it (probably) even more secure?
Something like: echo "$(gpg -d /path/to/pass.gpg)" | keepassxc-cli ls -q -R -f
Additionally one can use pinentry-curses in gpg.conf to not leave the console.

[gnrlus]

I second the OP's idea. It's important to be able to decrypt the database from command line in the event the application is unavailable. For example, the application gets corrupted and the network is down due to cyberattacks or ehem, UNUSUAL but 100% indisputably, perfectly natural weather, shall we say.

I once switched my passwords to a pgp-encrypted database until I lost the ability to decrypt when gpg-agent got corrupted and I had to re-install it. I don't like that gpg-agent has to be running and that it launches windows for password prompts that steal 100% focus and control, and it requires going into the Linux backend to force it use terminal only (the pinentry setting) and there are some instances where that will cause an application to fail if it doesn't have a terminal running to collect the password.

I like that openssl is a simple tool that requires nothing else (AFAIK). Perhaps AES-256-GCM with 12 rounds + salt? However, I noticed when upgrading operating systems openssl was upgraded and my files would not decrypt. If I had not saved my old OS I would be screwed...

I had to decrypt everything, upgrade my OS, and then re-encrypt everything with the new version. I think PGP also could be expected to do something similar. Backward compatibility doesn't seem to be a priority and that's concerning. Each new release of openssl/pgp ought to be equipped with a migration tool that up-converts all previous versions. Am I the only one finding themselves locked out of encrypted files upon upgrades?

So I ended up sticking with openssl. So far it poses the least problems and so long as the command is well crafted, I think it's cryptographically strong. AFAIK most attacks on encryption, whether side channel or brute force, seem to only work on weaker passwords or smaller numbers of rounds or when using 128-bit instead of 256. Because 256-bit will full rounds already puts it in the category of billions of suns energy to power a brute force attack, using a 4096-bit GPG key doesn't seem to help a whole lot more unless we're dealing with advanced aliens who have figured out how to harness and control the power of stars and blackholes to crunch math on that scale. lol

But definitely KeepassXC should have everything command line available. Very important.

[gnrlus]

Is there anyone who has the skills to go into the source code and figure out what commands are being run in the application to perform encryption and decryption? Perhaps we can extract that portion of the code and just build a simple tool to at least encrypt and decrypt from command line. That would be a worthwhile project. If I knew how to do that, I'd be on it.

I tried to contact the devs via chat but it required me to create a Nickserv account and it had this TL;DR kind of web site, so I gave up.

[phoerious]

There is much more to KeePassXC than just encryption and decryption. We support a full file format specification for secure password storage. keepassxc-cli is the way to go if you want to do things from the commands line.

Because 256-bit will full rounds already puts it in the category of billions of suns energy to power a brute force attack,

Do not confuse the AES key schedule with a proper password transformation. Unless your password is a fully random bit stream the length of an AES key, use a strong and memory-safe password hashing function. KeePassXC uses Argon2 for transforming passwords. OpenSSL doesn't give you that, so it's a bad choice. There are also a lot more security considerations that went into making handling passwords with KeePassXC safe. There is way too much that can go wrong accidentally if you try to do all that by yourself with encrypted plaintext files, hence I cannot recommend manually encrypted plaintext files as a password manager replacement at all.

[gnrlus]

All correct. I use strong passwords and all the securest parameters and should not assume everyone else does.

I'm not going to pretend to understand how Argon2 helps but it seems if you use AES-256-CBC/GCM with full rounds and salt it's not going to be cracked AFAIK. I think even Bruce Schneier said AES is still safe. Not sure if Argon2 hashing will help but I'm not a crypto expert.

"Too much that can go wrong..."
Well, I've been using my own software for years to encrypt/decrypt passes and no problems so far. Would love to hear your criticisms, and I do trust you as a data scientist on the dev team would know infinitely more about this than I would.

But at the end of the day I insist on the ability to decrypt the password database in the command line one way or another. I will check out keepassxc-cli for sure! Thanks... So I tried it. It extracts the database alright and you can go right to specific entries. Ok then! LOL Awesome.

[gnrlus]

This might be a rare catastrophe, but let's say I'm setting up a new desktop machine, and zap, all the power to most of the city's houses goes out for a whole week. I need to recover passwords to buy groceries on my debit card that I haven't used in ages, but KeepassXC is not installed and I have no way of downloading it and because everyone's busy dealing with the power outage there's no one to help, and my passwords aren't decryptable. Can you help us locate the code the KeepassXC application uses to decrypt so that we can perform it manually without the application? The application being a dependency to decryption is basically the one caveat that could potentially make me avoid switching to KeepassXC from my own tool.

[droidmonkey]

How is your computer still working in this case? You need the application to open the file. You can use the android app as well. Your question doesn't lead to a solution to the problem set.

[phoerious]

KDBX is a complex file format specification. There is no simple way to "manually decrypt" it. The application being a "dependency" to it is absolutely working as intended and no caveat. KDBX is way more than just a dumb AES-encrypted plaintext file and KeePassXC is way more than encrypted Notepad. Read the KDBX spec if you need to do it without KeePassXC.

[gnrlus]

"How is your computer still working in this case?" I was going just going to edit my post to clarify. So either I'm using a desktop with battery backup or a laptop on battery, but the internet supply is unpowered.

"You can use the android app as well." Smart phone security blows compared to Linux on a PC correct? I would prefer not to access passwords on them, and I prefer not to even own phones, which I understand tend to be a lot more vulnerable.

"The application being a "dependency" to it is absolutely working as intended and no caveat." Well it doesn't come installed by default, whereas openssl does. Let's say I just finished installing Linux and that's all I got done before losing internet. I will examine the KDBX spec and see if that's something I can do... I couldn't find "KDBX spec". I skimmed through the Wiki and the User Guide. Do you mean this? https://keepass.info/help/kb/kdbx_4.html -- I don't see any mention of tools or commands I could use.

[gnrlus]

The second most important thing is backward/cross compatibility. So if I create my database with whatever version of KeepassXC my distro providers, I need that to work with any version I download from git.

The foremost important thing to me is having the means of practically decrypting the databse using the KDBX spec--however that works (I can't find it)-- is the most important thing to me, and if this problem is solved, then I'll feel a lot better and that second most important thing is not as important.

I mean, you know, credentials are your life, so you really don't want to risk any possible scenario where you might fail to decrypt them at the critical moment.

[droidmonkey]

We have all released versions of KeePassXC available for download. We only guarantee compatibility to the specific kdbx spec version and major releases. If you use an ancient version (say 2.3.0) then you can re download that if it is incompatibile with our latest release (2.7.0).

Bottom line is that YOU are responsible for disaster recovery. How you implement that is totally up to you. Export your credentials to HTML and print them out. Store your db with keepassxc portable on a USB stick. Export to csv and place ib a USB stick. We offer all these options and we don't care what you decide to do or not do.

[gnrlus]

"We have all released versions...you can re download..." [thumbs up]

"Bottom line..."
I already understand it's my responsibility, which is why I'm here dialoguing to learn (and hoping to be accommodated if I run into any snags and there is enough interest to implement such accommodations). You have an expectation that the user master disaster recovery, but as phoerious says, "KDBX is way more than just a dumb AES-encrypted plaintext file and KeePassXC is way more than encrypted Notepad." which leads me to my next question, which is, what kinds of disaster recovery solutions would compromise the security that KDBX provides? Is the KDBX protocol needed because there are security blunders that happen due to accessing keys frequently using other methods, or is it fundamentally more secure than a "dumb AES-encrypted plaintext file" that can't be brute forced or side-channeled in a billion years? I certainly don't want to bypass any protections of KDBX in choosing my disaster recovery solution. It seems like exporting to csv and AES-encrypting that, and storing that blob in a file and on paper would be the way to go. Though, paper recovery would require solid OCR software and manual blob re-assembly. lol...Anyway, if you assume that it's not safe to have plaintext credentials on a file on the computer or on paper, then I wonder what most of your users' preferred disaster recovery solutions end up being.

[droidmonkey]

I listed them in my response.

[gnrlus]

To clarify, I mean if one had to be picked that was "THE best" lol, granted everyone will have different needs, so by "best" I mean best balance of security and convenience. If I had to guess, I'd say just export as cvs, independently encrypt, and store that in a file and print out the blob as well.

[jagrg]

Keepassxc is free software so I wouldn't be worried about compatibility. What you could do is run incremental backups of your db locally and offsite. Remember to use a strong password and test you backups and you should be fine. You may also want to waterproof and fireproof local copies of your backups and keep them in a safe in case you're worried about theft.

[gnrlus]

Does Keepassxc include all dependencies? I have experienced being locked out of encrypted files due to changes in new versions of Openssl and GPG. If I had not kept my old OS and manually converted them to cleartext and then to the new version I would still be locked out. I could not install the new version on the old OS or the old version on the new OS. I see that Keepassxc download is offered as a .AppImage, which sounds encouraging in this regard. Thank you.

[jagrg]

Hello again. I wrote a wrapper around keepassxc-cli using fzf. I'll leave the link here in case it's useful. Please let me know your comments. I found #6752 and #7462 useful.

[kamazee]

What do you think about integrating terminal emulator in the same way as browser integration works?
This looks to me like a more secure option than working with cli version because the integration won't get the credentials of the keepass; the specifics of putting a password into the terminal seems to me pretty much the same as when filing a form in a browser.

While I don't really know the specifics of the protocol, I assume that it can be relatively easily implemented in a terminal emulator; however, I see a list of browsers in the keepassxc and wonder why it's there along with the path to the browser configuration. I assume that "pairing" with another application whether it is a terminal emulator or a browser only includes key exchange without any specifics of the keepassxc side; is the browser name used merely to match the key? If I'm correct in this assumption, then doing what I think of implies turning browser integration into broader integration with turning a list of checkboxes into a list of key names that a user can append something to.

@droidmonkey what do you think about it?

[droidmonkey]

Anyone can write an interface with the browser interface. There are ones already written in Python for example. Have at it!