Inspired by split-GPG, split-pass would be a split-password manager.
Let’s say your adversary has the power to pwn your password manager: boo!
split-pass would make it far more difficult - split-pass would make passwords truly multifactor.
How:
you could store a load of garbage in keepass, and have a dedicated VM or external device to turn it not into garbage - hence split-pass. This is good for really very sensitive info and those who need deniability in hostile environments.
As this is rather simple to PoC, I can probably get something on github in the next few weeks (currently backlogged with flexi-chains). I would first like to know the appetite for this, hence this survey:
It is simply another layer.
It is not a marvel, it is not urgent, it is not a giant leap in the advancement of qubes security.
It is however very simple to setup and some people may be interested in it.
There are many attackers who may have access to your password manager, you have perhaps assumed that all such attackers can also gain access to a second VM which could be a unikernel (for example) dedicated to work with keepass.
Again, given that mirage has made things easy for unikernel apps, even a unikernel enhanced version really isn’t that difficult to do.
It’s simply another layer, but I’m repeating myself now.
Sorry if this comes across as blunt, I’m juggling a couple of projects around in prep. for flexi-chains.
In your (I infer) assumed threat-case you would perhaps benefit from a browser plugin which further degarbled the data, in the form of a disposableVM and which self-destructed after-wards. Again, this is another layer in the defense.
I’m genuinely not meaning to be rude, I just sometimes write things in this way when I’m busy. I’m trying to contribute more to the community.
Maybe I’m misunderstanding the issue here, but as I understand it, split-pass would still need to have a client component in a less trusted VM (e.g. personal). How do you enforce that the personal VM can’t access the passwords of other VMs?
Also: a cool thing to do perhaps would be for split-pass to create split-gpg and split-ssh “child” vms on demand. It would create a disposable VM with your ssh key and allow you to login via it until it is shut down.
You can have more identities in the password manager and you can change relative easy between them, when you change all the others are close and encrypted so you only need one vault
Qtpass (gui frontend to unix pass) running on offline appvm (qtpass)
qtpass is using split-pgp
On my vault appvm, pgp keys are actually used via OpenPGP smartcard
I’m also using split-ssh setup, authentication key coming off the same smartcard!
Really handy setup. I really should document this, maybe some day I get the time and energy to do it.
When I went to unix pass couple of years ago, I never looked back. Compared to “monolithic” password managers this solution is so simple and logical it still makes me smile every time.
I can see one advantage of having a password manager agent running in the target appVM: clearing the password from the clipboard automatically after a while. It is a rather old issue that I have documented here.
Technically speaking, and very specific to Qubes environment, not much. That sort of password store is simple and working in this specific context.
But for me the password management must be compatible also with whatever future environments. I was running my gpg-smartcard based rig long time before Qubes, and I will be running it long time after Qubes as well. OS is just a tool that changes over time. Luckily, my smartcard setup was very easy to adapt to Qubes, it is very flexible system.
other than multi factor authentication,
imo, the best way, to store or generate strong password, is by using air-gapped computer,
if not mistaken, i read somewhere, this is how they manage password for cryptocurrency.
because, our mind maybe cannot remember many strong password,
also storing password into any electronic devices maybe risky,
then maybe can install password manager, or password generator, or maybe create one,
into the air-gapped computer, then apply double blind strong password,
then manage and generate from the air-gapped computer,
and type them into the online one.
i remember, last time i created simple mini project,
to generate strong password, from several random garbage keyword,
my mistake is, i used the online laptop, that has been being targeted,
from creating the project, until generating the password,
therefore the random garbage keyword leak out.
anyone has experience with air-gapping a computer ?
please kindly share in another thread.
I’ve looked into this and I will probably implement it when I have the time. The idea is to take advantage of the protocol that is already implemented in KeypassXC and is used by the browser plugin.
With very little work it’ll work just like split-gpg, but in this case it’s the browser plugin which requests the password for a given site from the vault vm. The user would have to approve the password being sent to the browser before anything is actually transmitted.
All the infrastructure is there, aandrthere is very little code that needs to be written to get it to work.
My current scheme, which I guess I like, is as follows:
pass is an AppVM with no networking which contains a copy of my .password_store.
I use a YubiKey, per the DrDuh setup, to access the passwords.
I have a script in dom0 to assign the YubiKey to the pass VM.
# cat ~user/bin/pass-up
#!/bin/bash
#
# Bring up the pass VM
#
set -o errexit
set -o nounset
vm="pass"
reader=$(qvm-usb list | grep "_Yubikey_4_" | awk '{ print $1; }')
qvm-start --skip-if-running $vm
qvm-usb attach $vm $reader
qvm-run $vm xterm
The resulting xterm window, I pin to all work-spaces.
So if i want a password, I do (in the passxterm window):
% pass -c SecretStuff
which pops up a dialog asking me to input the pin to unlock the Yubikey (once), and then flashes the LED on the YubiKey. After I touch the key, the password is placed in the clip.
Ctl-Shift-C / Ctl-Shift-V / Ctl-V brings it to the desired VM.
The benefit of this approach is that the password is normally only present in the cut buffer, not present on the screen.
I keep my passwords synced via KeyBase, as KeyBase provides git storage.
So if i need to update the copy of the .password-store, I spin up the dedicated KeyBase AppVM, which has network access, run:
% pass git pull
and then qvm-copy ~/.password-store to the pass vm.
The copy is considered a read-only clone, but i could go the other way if i wanted.
I use this mainly to access my “global” passwords, to import them into the qubes system. I tend to store them locally in whatever AppVM I need them on an ad-hoc basis.
I implemented such a scheme for the Rudd-O pass stuff. here
I ended up not using this approach. Can’t remember why. I think it was because I had to dork with files in dom0 granting various permissions and I did not understand the full ramifications of what I was doing, so I opted for a more Pooh-brained approach.
Anyway, the clip management (do_clip at line 187) with timeout should still work.
The qubes-pass thing I wrote now has support for xclip in the master branch, as well as support for generating QR codes, and it has better compatibility with the pass command line interface.