Thanks so much! That had me really confused. I will give it a go in the morning and see how I make out. cheers
Mixed success. I’m very happy to report, that removing KeepassXC from my lower security domains and adding it to only my vault domain has worked. I’m successfully logged back into this forum using the
“Highlight entry in keepassxc, ctrl-c, ctrl-shift-c, switch to AppVM, clt-shift-v, ctrl-v” method. But is there a way to copy both the username and password in one step? I generally have very strong passwords, but in some instances I have usernames, which are specified by some sites, which I cannot change and are too long/too complex to remember and manually enter from memory. So I’m needing to do the 4-step copy and paste method above for first the username and then again for the password. Is there a way to copy and paste both at the same time? Thanks
As I mentioned, if it is a frequently-used login, you could save both username and password in the browser, avoiding all copy-pasting.
For a middle ground, you might be able to auto-fill just the account name in the browser, so you only have to copy-paste the password.
For Firefox, I guess you can save an account login with a dummy password.
1 Like
Thanks so much. I’d mark this thread solved, but I don’t see a way to do that yet. cheers
Hi @Qubesquark. This was under the category General Discussion. But only threads under User Support can be marked as solved. I’ve moved it there now. Feel free to mark the answer that helped the most as the solution. (or mesage me if you have any issue).
IMHO the cut’n’paste “solution” is IMHO not right, and it is wrong to advertise it.
KeepassXC has features to provide the credentials to a browser plugin, and to auomatically enter credentials for you in apps not featuring a keypass plugin. Going back to cut-n-paste is a clear regression for several reasons:
- it is more tedious, thus error-prone, thus “paste into wrong window” happens every once in a while (possibly even “paste to wrong domain” but when you’re copying across domains you’re already supposed to know to be careful)
- once you hit ctrl-shit-v OK your password is not in the Qubes clipboard any more, but it stays in your domain’s clipboard, where any X11 app from that domain can request it (try
xsel -b -oif you want to see it with your own eyes).
Now we could argue that QubesOS allows you to separate apps by domain, and that any malicious app in a given domain already taints that domain, so avoiding the paste buffer and using a different channel would not do much, and could even give a false sense of security. But still, my first argument would remain.
Has anyone found a way or package that can program extra mouse buttons to handle the Qubes Clipboard copy/paste?
Hm, I have the feeling you want that just as much as a mouse shortcut calling sudo for you…
Specific shortcuts are there so you are aware of information going from one domain to another, moving this to mouse buttons is likely calling for trouble 
How is a button programmed ctrl + shift + c less secure than pressing ctrl + shift + c? Shortcut keys are currently available now in Qubes.
Well, don’t you think it’s easier to press a mouse button by mistake ?
It’s more about safety than about security, really.
Nope. Buttons on the side rarely gets used. They’re not in direct contact with the thumb and you have to reach and press them.
1 Like
You’re free to do your own risk assessment. I wouldn’t myself recommend doing that to anyone.
Although complete Qubes nebwie, I absolutely agree with this. So, is there a way to use KeePas from the vault, as for example I use it on my Windows host machine: I am in the virtualbox vm, I press let’s say Ctrl+Alt+A, Keepass from the host is called and offers a list of all the password defined for that vm window, I choose the desired entry by mouse and thus apply it to the vm window/form-in-it.
If not and considering that copy/pasting from higher security to a less security domain is recommended unlike vice versa, does it sound reasonable to suggest such an option exclusively for the vault cube to be developed? It is hard to imagine whole sequence CTRl+ALT+A and then mouse click unintentionally to happen. Also, not all forms are in browsers, thus not al of them offers roboforms - on the contrary.
Thanks in advance for your thoughts and suggestions.
Bump?
You may want to look at this thread for ideas:
I very much agree with those who are warning against using a clipboard to copy passwords between qubes. That seems like a really bad idea.
@yann (and others)… how are you setting up a single isolated KeepassXC backend to secure multiple VM browsers without using the clipboard to populate browser login fields?
@necker, I did not take the time yet to do any better than copying, I was waiting with hope for @arkenoi’s results, I must say.
One way to do automated logins from passwords stored in the vault VM is to collect browser password files, each containing a single login, in vault. When you need to login, have a script in vault start a dispvm, then populate the browser profile in the dispvm with the appropriate password file, then launch the browser in that dispvm.
For example, firefox credentials are stored in $profile/logins.json and $profile/key4.db. Assuming they contain the login for mywebsite.com and are tar-ed to mywebsite.com.tar, then the following, when run from vault, will open a browser in a dispvm (based on debian-11-dvm) containing just that login, ready to auto-fill:
qvm-run-vm \$dispvm:debian-11-dvm \
'profile=/home/user/.mozilla/firefox/*.default
( cd "$profile" || exit 1; tar -x )
firefox mywebsite.com >/dev/null
' < mywebsite.com.tar
How to collect the credential files inside vault? One way (that doesn’t involve copying external data into the vault VM) is: start an offline firefox in vault with a fresh browser profile, go to about:logins, manually enter a single login, shutdown firefox, tar the generated credential files in $profile, and then delete $profile. Repeat for each login.
Something like the above is great for a few high-security but often-visited sites.
3 Likes
@airelemental That’s not a bad idea. Though I am now realizing that I have relatively few high security accounts (email, encrypted storage, etc). I could create a separate dispVM for each account with a unique installation of KeepassXC that only stores a single login credential in the database. I could also create unique firewalls for each VM that limit traffic those services. As long as I don’t use the browser to access other sites and services, the VM is disposable and there are no other passwords stored in the local database, that should give me the security I want.
1 Like
If you go the one VM per account way, then maybe using KeepassXC in the same VM does not add much security: if the VM gets compromised, “they” just have to install a keylogger to gain access to your keepass db. That does not seem to be much better than “save password in browser” - which may be fine for some cases, but does not match my perception of “high security account”.
@airelemental’s solution is interesting - with the usual caveat with non-encrypted sensible material, that backups will need to be protected strongly enough.