Anything like Split GPG for Keepass?

[Eric Shelton]

I am curious how people are making effective use of Keepass in a vault domain.  It seems like with a browser plugin, you might be able to take a Split GPG type of approach, and avoid all of the cutting and pasting across domains.  Any comments or suggestions?

- Eric

[Marek Marczykowski-Górecki]

Personally I use manually Ctrl-C + Ctrl-Shift-C, then Ctrl-Shift-V +
Ctrl-V. After some time it is very fast in practice.

Using some Split GPG approach would require either:
a) some policy which VM can get which password - this can be somehow
complex and error-prone in more advanced setups
b) separate vault VM for each browser VM; which is almost the same as
simply password stored in that browser

Note that, unlike GPG case, when you give a VM access to some password,
it can freely stole it and send wherever it wants.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Joanna Rutkowska]

On 01/08/15 01:33, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 07, 2015 at 04:00:30PM -0800, Eric Shelton wrote:
>> I am curious how people are making effective use of Keepass in a vault
>> domain. It seems like with a browser plugin, you might be able to take a
>> Split GPG type of approach, and avoid all of the cutting and pasting across
>> domains. Any comments or suggestions?
>
> Personally I use manually Ctrl-C + Ctrl-Shift-C, then Ctrl-Shift-V +
> Ctrl-V. After some time it is very fast in practice.
>
> Using some Split GPG approach would require either:
> a) some policy which VM can get which password - this can be somehow
> complex and error-prone in more advanced setups
> b) separate vault VM for each browser VM; which is almost the same as
> simply password stored in that browser
>
> Note that, unlike GPG case, when you give a VM access to some password,
> it can freely stole it and send wherever it wants.
>

Yeah, I don't see much benefit in using the split model for something
like passwords. It really makes sense for asymmetric crypto or other
challange-response protocols.

joanna.

[marc...@gmail.com]

I think it would be not very practical to have keepass database in the vault and it should be secure to keep it together with the browser if you encrypt it with a keyfile and a password. On the other hand, the keyfile should be in a secure place and then maybe it would make sense to have something like GPG split.

What do you guys think? Does this make sense to you?

Márcio

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Please don't top-post.]

On 2017-01-26 20:21, marc...@gmail.com wrote:
> I think it would be not very practical to have keepass database in
> the vault

I disagree. I've personally found it extremely practical after years
of daily use.

> and it should be secure to keep it together with the browser if you
> encrypt it with a keyfile and a password. On the other hand, the
> keyfile should be in a secure place and then maybe it would make
> sense to have something like GPG split.
>

No, because if that BrowserVM is ever compromised, then the next time
you supply your password+keyfile, it has permanent access to the
entire database. This also limits the database to that single BrowserVM.

> What do you guys think? Does this make sense to you?
>

I agree with Marek and Joanna. The standard model of having a
password manager in a VaultVM and using the inter-VM clipboard is
superior. It allows you to selectively expose individual passphrases
to particular VMs of your choosing without ever having to expose the
whole database. It's time-tested and works well.

> Em quinta-feira, 8 de janeiro de 2015 07:27:04 UTC-2, Joanna
> Rutkowska escreveu:
>> On 01/08/15 01:33, Marek Marczykowski-Górecki wrote:
>>> On Wed, Jan 07, 2015 at 04:00:30PM -0800, Eric Shelton wrote:
>>>> I am curious how people are making effective use of Keepass
>>>> in a vault domain. It seems like with a browser plugin, you
>>>> might be able to take a Split GPG type of approach, and avoid
>>>> all of the cutting and pasting across domains. Any comments
>>>> or suggestions?
>>>
>>> Personally I use manually Ctrl-C + Ctrl-Shift-C, then
>>> Ctrl-Shift-V + Ctrl-V. After some time it is very fast in
>>> practice.
>>>
>>> Using some Split GPG approach would require either: a) some
>>> policy which VM can get which password - this can be somehow
>>> complex and error-prone in more advanced setups b) separate
>>> vault VM for each browser VM; which is almost the same as
>>> simply password stored in that browser
>>>
>>> Note that, unlike GPG case, when you give a VM access to some
>>> password, it can freely stole it and send wherever it wants.
>>>
>>
>> Yeah, I don't see much benefit in using the split model for
>> something like passwords. It really makes sense for asymmetric
>> crypto or other challange-response protocols.
>>
>> joanna.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYiwMBAAoJENtN07w5UDAwkGIP/R4gfILPg55fXmEHnROPy3Hs
drTxBAirdSe/+PuPjuSYUXdiKgVJd7ggTrW/PPIBZxcYFP2fk/EOdUn91VdQPZa1
NjrgakD2AULG1m6keHmSnr6SA1YRq8LFJwIKvanhqtIVMUxD3HIh2oZ65O6Z9fDY
nEQlEXTj1yfwfWRYsc4JORL1y3ESmOTEQJjmpswm5QuFpU/w7PUvg1Id2xg0P3Zy
j7YK/LiEBUxZdSG8bxYsu/4zvomPXoYTX3xyfQcWY4ZYiVltoR9sYhjJzGxMvwlv
SDkO2B+t8B3tSmju7xCR3evRn4NCLiWL4+WNj2tCj+d1L8swCzKNRGryjCctn2Rn
qlslhcdBFq/WIKAl/OX0anR4Wmq5pa2lsPB+XYLRtrx6oyuBLyVAd9z/omGQlP9V
n9ZAIbzCDbfJNLVXLWXK+2xNZK7+QuipGjem7rzeLGN/S1wiP0weueFlR1hoXtJq
/n6alYvX2Nw+S0jKveVTLNco8AhTL9xGnFaFKiJ2zRQSXC/fJWRkR4d4Eo7zh2nn
WPjM0V3r7HrHjzFHReywrxhqkJVo4pzOiW32tsiZkfZaPUmPORkJiqE6pRudw90Y
O/7m8GNNR3EvzjrwP28z9slT0IDf5H27tbDd8UMJBrvbTJkABOSFOlM7IrJrSKp7
LZRKIwr3+0IV59lwpn3m
=k7qw
-----END PGP SIGNATURE-----

[anoa]

I'm also looking for something like this, at least a more general approach.

I have a keepassx database I sync with owncloud for all of my devices.
I'd like to keep the database in the vault vm, however this VM doesn't
have any internet access, and thus cannot sync automatically after every
change.

What would be nice, although a security risk but one could put several
restrictions on it, would be a shared folder that the vault and a
specified sync-VM for the keepassx file could access. That way the
internet-connected sync-vm could keep the file up-to-date and the vault
vm could carry the keyfile needed to open the database.

That and the ability to auto-type into VMs would be awesome as well, but
one step at a time :)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

My partial solution to this is to use scripts to (mostly) automate
qvm-backup[-restore]. This doesn't automatically sync after every
KeePassX change. It's just something I have to manually run. Still, it
takes a lot of the work out of keeping a set of VMs synced across
physical Qubes machines. Here's an example of doing this with Dropbox:

https://gist.github.com/andrewdavidwong/2279186286e3822eb4376e5ac35c3c81

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYjAwdAAoJENtN07w5UDAwLmAP/0RwVg/v9R9sJW1mAxpQGf1R
vRqTuBHh6Od1LOo03uKprG1ujj5oQEtwifX/JlXLJnK3tzjJ8HgcqqS1Sjo5IDGD
aW+tGOkjH0Q4r/eaB1vYvQPHHotJPQ/uFxQg5RG744NG68BcgE5St2gKW8WtNKya
AOXhiIdud2z9qg+Ae/WaYFIaKM4z4CBnNCaXhL7TKj0jCbClRx2ma6ghf3RYET5e
9EFt+2S+itpkXvv/9cUl1F8+fOBOTGqYiPehEdywhBeEUb78qNUYNh5XXe+s05k1
yX6emFQKTtmEza5iAMJYneYg1HBgEXmf3FCTQ9xLTiXorXXNOOFxjKLeZqYDz5Hl
Mgyec2iqu50jOl0w1rgRJWosQRWV/u9DTxcPW6a3pCdUXip0f/c4Hge3xsdEYYTN
N+lsT/TbRgvaxLvFychGBHUkzLhxdtT9kuog05OpIbqXmpPlNze1XDnELdHe0ddp
dxoSvRx54b4+/oWmiHHxZqD3m6sT2A+mLj0zJHPhdD9SSfi7tmYzraPpwO2Avcq1
jOk6q3kGjhFN7ziI85av/TTWZg7seC3dh41EcKKhqa1NG28+zOLuyszFJQFJcQu5
nyErPbe3GqjF/9pw3HGvihHStfUnfFW6u/kQWm63xZBPXQS8UU9VzB+juzI0OlaU
vO87uSGZCQdjOetGDMzf
=vIK7
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Eric Shelton:

An inter-VM password manager for Qubes OS based on pass (
https://www.passwordstore.org/ )

https://github.com/Rudd-O/qubes-pass

https://groups.google.com/forum/#!topic/qubes-users/amry7Shb94o

(Adding this here since search for "Keepass" "Qubes" leads to this old
thread which claims there is no solution at all.)

[rysiek]

Dnia Monday, November 13, 2017 2:04:00 AM CET Patrick Schleizer pisze:

> Eric Shelton:
> > I am curious how people are making effective use of Keepass in a vault
> > domain. It seems like with a browser plugin, you might be able to take a
> > Split GPG type of approach, and avoid all of the cutting and pasting
> > across
> > domains. Any comments or suggestions?
> >
> > - Eric
>
> An inter-VM password manager for Qubes OS based on pass

Should also be possible with Keyringer:
https://keyringer.pw

--
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

[Yuraeitha]

Doesn't this automation increase possible surface attacks on the keys themselves though? Even if using existing Qubes tools, not re-inventing the wheel, and keeping Qubes itself safe as it was before using the tool, but the automated policy can still be tricked into giving over the password though?

If true, then manual copy/paste between Qubes is supposedly more safe? Because the initiation is started from the isolated dom0 ps/2 keyboard (or USB qubed keyboard), and not initiated from within the internet exposed Qube itself.

I imagine this might be good for less important passwords, daily ones that can be annoying to type in, but also aren't too important. But regarding important passwords, perhaps use the manual method instead?

Having to use manual password copy/paste is a bit slow, takes up at the very least several seconds, if not half a minute, to open it up and navigate to find your password, and then copy/paste it over.

So it becomes a question between speed/convenience/insecure vs. slow/inconvenience/secure?

Maybe we can make a hybrid here? Like for example have a hardware key, requiring you to press it before it accepts the automated process. Or even just a popup from the isolated offline password-manager VM, before proceeding. It's not fully automated, but it's also not as intensively manual either.

Maybe the inter-VM password manager for Qubes already does something akin to requiring a single quick action from inside the offline isolated password manager VM before fulfulling the request of the online VM. If I missed it, then I apolgize, but I can't see it anywhere.

Thoughts on using a hybrid method though?