You can use text file in VeraCrypt partition.
And you can make backups of this, just copies of this text file.
Need to remove cash of text editor.
You can use text file in VeraCrypt partition.
The password manager is a newer ending story…
gnupg does not allow pasting of passwords into the pinentry field. There was a work around in FPM up until the last update, but it no longer works.
Given that I generate long random passwords this is a deal killer for me and FPM.
Keepassx has an autotype function that allows you to fill the pinentry field. You can also specifty how long clipboard contents remain in memory.
My thanks to the Whonix team for a great product! Love you guys…
This is a deprecated design feature of pinentry, and not a limitation of gpg. Whonix ships with Debian Jessie’s
0.8.3). If you upgrade the package using jessie-backports (currently version
0.9.7), then clipboard functionality is restored while the pinentry window is active. Both FPM & Keepassx should paste without any issues.
pass is a filesystem based password manager that encrypts each entry using gpg. Customizable fields; same security as gpg; reliability of text - no complex corruptible formats; git-friendly. (Also integrates well with Qubes since single entries can be exposed without risking the whole database.) Default is CLI but 3rd-party GUIs and plugins also exist.
That worked! Spent hours searching for a solution. Took the whonix team to solve a non-whonix problem. Will check out pass as well. Thank you!
(Found this earlier. No endorsement. Looks reasonable review to audit even by less technical people. Very few lines of code.)
Would pass-qubes have any benefit if your pass Vault AppVM was network isolated. I can understand you would not want to expose your GPG keys to a networked AppVM (i.e. user wants to sync with git). Am I missing something?
Non-networked is always nice just to limit the attack surface of it.
But Qubes split password manager has limitations indeed either way. Since the password requesting AppVM can request passwords from the vault VM and see them in cleartext. And what if you wanted to split passwords for multiple AppVMs, separate for example for banking, shopping, social and so forth? Are you going to use several separate vault VMs or could we invent a mechanism…?
The same issue goes for Qubes split-gpg to a lesser degree. It’s nice that the keys won’t be leaked. So once it is known that the AppVM was compromised, it can be shut down, therefore no longer sign malicious contents. But while the AppVM is compromised, it will always decrypt and sign everything. A cool feature for split-gpg would be
WYSIWYS (while the view-before-you-sign-it-viewer of course runs in the vault or a separate DispVM).
I wrote about that idea before I knew these terms.
I need to take a closer look at https://github.com/Rudd-O/qubes-pass. It may already do what I describe.
Here is how I envision password retrieval on Qubes:
- appVM sends request to dom0 for lookup of password with $keyword. request can be made via cli command or a keyboard shortcut (that could parse torbrowser window title for a keyword).
- dom0 forwards request to offline passVM.
- passVM validates request, performs lookup. if multiple matches, error. decrypt if necessary (using whatever, ie split-gpg or even none).
return cleartext password to dom0prompt dom0 for permission to allow password for $entry to be sent to appVM
dom0 prompts user for permission to allow password for $entry to be sent to appVM
- if permission granted, paste password to appVM clipboard.
- appVM has no access to decryption method
- appVM has no access to password db for enumeration, etc.
- appVM can request any password, but user must authorize each returned password
The whole point of this is simply convenience. Keepassx with ctrl-c, ctrl-shift-c, ctrl-shift-v, ctrl-v works fine but requires manual lookup and finger gymnastics.
Too much dom0 complexity. This is better done from within vault VM.
In light of the recent revelations of the Meltdown and Spectra CPU flaws I though there would be more interest in using
pass (password manager) along with the
pass-qubes (Split-GPG extension ) since the Qubes Security Bulletin mentioned using
Split-GPG as an extra layer of security with Qubes OS.
EDIT It should be noted that
split-gpg will offer an extra layer of security in general bu it does not offer protection against these CPU bugs as noted in the next post by HulaHoop’
They were mentioned previously in this thread but for ease of locating here are the links.
One of the reasons for this post is there may be users like myself that installed
pass and had it working properly but where unable to get
pass-qubes extension functioning. I haven’t figured out what is wrong, but I’m guessing it has something to do with the way the package manager installs
apt-get install pass
git clone, make install
Fortunately there is a easy workaround to get
pass-qubes extension working and as I’m sure you have guessed it only involves installing
pass manually. This can be accomplished as per the instructions on the
pass home page.
Also if you’re getting this error message after configuring everything properly it may indicate a manual install is necessary:
Error: qubes is not in the password store
It may be helpful when troubleshooting to know that this issue/bug may not be isolated to the
pass-qubes extensions. A Qubes user had a similar problem when trying to install two other
pass extensions. Not only that but a Fedora based VM was used so its not isolated to Debian either.
If any Qubes users are interested in step by step install instructions let me know and I will post them for you.
With these CPU bugs nothing can save your passwords or data from snooping. VM isolation becomes a fictitious line in the sand.
That makes sense. The CPU would have access to the VM regardless if it was network isolated or not. I misinterpreted
split-gpg, which in general is an extra layer of security (for your gpg keys) for an extra layer of protection against those bugs. Thanks for the info, my post has been corrected.