Keepass Best Practices
Natalie Omahony
What is the best practice for installing and using Keepass w/ Qubes OS ?
Which VM type, can vault be used, will need usb access for key file, should it be on a standalone vm?
Please let me know a good way to proceed. Thanks.
In terms of securing your usage of Keepass2 or KeepassXC, I would recommend the most important step is creating a separate TemplateVM and only using your keepass app of choice from AppVMs derived from that TemplateVM.
As others mentioned, AppVMs you run any keepass-related application in do not need a network connection so remove that, and clipboard is sufficient for moving secrets out to other qubes for most usage.
Keepass itself is actually an open standard if I understand correctly, so the database files have fairly good interoperability between applications. However, you will find that different applications have introduced extensions and nonstandard behavior that is not interoperable, so it would be beneficial to make note of what application you actually used and make sure you can always have access to it as well.
These applications are also open source as well, so it is unlikely that they would vanish off the face of the earth, but backing up your TemplateVM is a good idea if you want to explore the model of what could go wrong with mismanagement of your secrets.
I had mentioned backups before, but it is also worth mentioning that there can be a risk of corrupting your keepass database file! You need to consider backup strategies very very carefully for a keepass database because a naive approach will lead to over confidence and a lack of awareness of how much actual risk you have!
Furthermore, in the event of an actual database file corruption, the exact nature of the damage to the file matters as the file can possibly be recovered without having to risk data loss by rolling back to an outdated backup.
An example that happened to me was that, while using Keepass2, Keepass2 had a fault of some sort and subsequently refused to open the database file, which was a problem because any rollback to an outdated backup would not bring back what I was losing.
However, KeepassXC was able and willing to open the database file, and, though I forget the particulars, after saving the file with KeepassXC, keepass2 was again able to open the database file and no data was lost as far as I could tell.
What level of CVE on openssh does one need to witness to understand the benefit of keeping ssh identity agents fully isolated not just for their own safety, but also for the safety of everything else, and in this case, of the keepass database file?
Agree, but I have already 20+ AppVM in my list and I prefer to have all my secrets in my secrets AppVM. This is a good compromise imo, therefore it is my best practice. As usual everyone has her/his personal view on this - his/her best Qubes setup.
When you say you have 20+ AppVMs in your list, you mean running concurrently?
And if so this is your compromise on conserving system resource consumption then?
Or do you mean menu space and just have a reluctance to create additional AppVMs?
Assuming you meant running concurrently, have you considered alternatives along the lines that normally split-ssh and split-gpg do not need to be up and running 24/7 and could feasibly be isolated into disposable templates and run from disposables with lifetimes tied to the qrexec requests that call for them?
If you want to call that reasonably secure in the disclaimer, I would suggest you find new personal best practices for the term reasonably secure, as in the case of SSH, that is not reasonably secure by any means.
@leo one could read the original post in the thread to remind themselves of the scope of the advice requested instead of pretending the world is ineffable and full of convenient face-saving ambiguity.
It should be materially obvious from what has been discussed that advising all new users of Qubes OS to add split-ssh and split-gpg qrexec services to their keepass AppVMs is not a best practice for Qubes OS.
@anon9706954 's recommendation is: Do not use any qrexec in your AppVM which stores your KeePassXC database since qrexec is a security threat - at least it increases the theoretical attack surface. Which is a fair statement and fine for me. If you are looking for ways to increase the security of your passwords it is always a good practice to try to limit everything to the minimum.*
* I have seen a guy who stores all his passwords in dom0 since it has the smallest attack surface. You can guess, this is not nice to use, manage, backup and restore but I wanted to share this as an extreme example. If you have a high threat model this looks like a good - secure - solution.
@whoami what ___ possesses you to believe you speak on my behalf, and incorrectly at that? qubes.Filecopy is a qrexec service, so stop making up ___ what I have or have not recommended in this thread. Anyone may bother to read my posts, and you may quote them ___, though an astute reader will not find any ___ sweeping claim as you have ___.
I take particular offense to you treating as a footnote that you seemingly ascribe to me or my recommendation to store stuff in dom0, ___. ___.
@whoami you are the poster that introduced the discussion of split-ssh and split-gpg into a thread whose original scope did not include them or request them or need them, and you have not made any representation but grudgingly that lumping those two qrexec services together with a keepass database file has security implications for that keepass database file until I pointed it out. What ___ is your problem in foisting split-ssh and split-gpg on this matter? You are, if anything, off topic, and at worst, creating confusion that would leave systematic vulnerabilities linked to ssh in the qubes of people that followed your advice in this thread.
@whoami what the fuck possesses you to believe you speak on my behalf, and incorrectly at that? qubes.Filecopy is a qrexec service, so stop making up bullshit about what I have or have not recommended in this thread.
Ok, agree this makes no sense to not continue like this.
I will flag this for mods. @mods please summarize what is relevant for " Keepass best practices? " that we can close this question. Thank you
This post points out why that is insecure and requests that post be edited so that people are aware of the risks they take when they introduce split-ssh or anything into their setups.
Our increasingly interconnected digital world makes security an essential and common discussion topic. We hear about data breaches with alarming regularity and are often on our own to make informed decisions about how to use technology securely. Although security is a deep and nuanced topic, there are some easy daily habits you can keep to reduce your attack surface.
Securing passwords and account information is something that affects anyone today. Technologies like OAuth help make our lives simpler by reducing the number of accounts we need to create, but we are still left with a staggering number of places where we need new, unique information to keep our records secure. An easy way to deal with the increased mental load of organizing all this sensitive information is to use a password manager like KeePassX.
In this article, I will explain the importance of keeping your password information secure and offer suggestions for getting the most out of KeePassX. For an introduction to KeePassX and its features, I highly recommend Ricardo Frydman's article "Managing passwords in Linux with KeePassX."
Using a different password for each account is the first step in ensuring that your accounts are not vulnerable to shared information leaks. Generating new credentials for every account is time-consuming, and it is extremely common for people to fall into the trap of using the same password on several accounts. The main problem with reusing passwords is that you increase the number of accounts an attacker could access if one of them experiences a credential breach.
It may seem like a burden to create new credentials for each account, but the few minutes you spend creating and recording this information will pay for itself many times over in the event of a data breach. This is where password management tools like KeePassX are invaluable for providing convenience and reliability in securing your logins.
I have been using KeePassX to manage my password information for many years, and it has become a primary resource in my digital toolbox. Overall, it's fairly simple to use, but there are a few best practices I've learned that I think are worth highlighting.
Turn on automatic database locking. In the Application Settings under the Tools menu, there is an option to lock the database after a period of inactivity. Enabling this option is a good common-sense measure, similar to enabling a password-protected screen lock, that will help ensure your password database is not left open and unprotected if someone else gains access to your computer.
93ddb68554