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 Sign-What-You-See / 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.
See also.
I need to take a closer look at GitHub - Rudd-O/qubes-pass: An inter-VM password manager for Qubes OS. 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.
https://github.com/kulinacs/pass-qubes
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 pass:
apt-get install pass
vs
Installing manually:
Downloading the tar file,decompressing, make install
or 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.
sudo apt install keepassxc -t stretch-backportsI have always frowned upon using some specific software (especially GUI software) for managing passwords, what exactly is escaping me? I always used a plain text file to store passwords, which I encrypt using gpg. I have seen pass mentioned a few times in the news (and in this thread), but there’s one feature of it that totally put me off and killed my desire to consider it. AFAIK pass advertises to store per-site passwords in GPG encrypted files, but names those files with site names. To me this is a giant flaw since it leaks the names of the sites one has accounts for.
KeePassXC has a plethora of features that make it much more useful than a text file.
In a kdbx database, I can store the password to my bitcoin wallet. I can store the seed. I can store the master public key, I can store the master private keys. (extended too). I can store a CVS file of all public keys for all addresses. Also a CVS file of payment addresses.
I can store URLs (encrypted), notes, and all kinds of other things. It has a password generator for secure random passwords.
It has YubiKey support. And KeyFile support.
I could not live without KeePassXC.
The only thing that I don’t like is that every time you save a new password, or change the database in any way, the entire database needs to be re-uploaded to the cloud.
So if I have a database that has a lot of large files attached, every time I edit anything in the database, the whole 400mb database has to be re-uploaded to my cloud storage provider. But this is a minor gripe.
wait what? my preciousss passwords never leave storage media I own
I’m sorry that you feel you need to limit your mobility in this way.
Cryptomator + Nextcloud is your friend.
(Although Cryptomator not really necessary since kdbx is already encrypted with AES)
How does pass leak site names? In Qube-Whonix an AppVM which has networking disabled can be used for a password vault. Regardless if Qubes is used or not. I don’t see how site names in cleartext matters. If an adversary can see those files he/she likely has access to your system. All that they would have to do is wait until you entered your vault password and log the password.
That is were they should stay. Security and Anonymity should be your number 1 priority when selecting a password manager. Features that could possibly degrade security and anonymity should not be used.
@LakeMonster May I ask you what Cryptomator version do you use ? Do you connect to a cloud using Whonix or another system ?
LessPass is an interesting password manager because it deterministically generates the same password for the same logins no matter what device you use it from without needing to sync the databases. This is possible because it generates these passphrases based on site, login and a master password.
https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4
Not packaged yet for Debian because it has non-packaged dependency:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843779
LessPass:
Any opinion?
Good find! Arcieri knows his stuff and it’s good to see a knowledgeable analysis about this family of pw managers. According to this new info we should actively discourage stateless managers on the wiki, citing the main argument headings. These ar core design flaws and can’t really be fixed.
Yes it’s the only m well known major option