ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

Building on the excellent pass (https://passwordstore.org), it gives me
great pleasure to announce the initial release of qubes-pass — an
inter-VM password manager and store for Qubes OS.

Check it out here!

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

--
Rudd-O
http://rudd-o.com/

[nick...@kulinacs.com]

What benefit does this have over simply ysing qubes-split-gpg-client-wrapper, like done here:
https://github.com/kulinacs/pass-qubes
It seems like a lot of overhead for not a lot of gain.

On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)" <rud...@rudd-o.com> wrote:

Building on the excellent pass (https://passwordstore.org), it gives me
great pleasure to announce the initial release of qubes-pass — an
inter-VM password manager and store for Qubes OS.

Check it out here!

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

--

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Andrew David Wong]

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

On 2017-05-07 10:10, nick...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here:
> https://github.com/kulinacs/pass-qubes It seems like a lot of
> overhead for not a lot of gain.
>
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> <rud...@rudd-o.com> wrote:
>> Building on the excellent pass (https://passwordstore.org), it
>> gives me great pleasure to announce the initial release of
>> qubes-pass — an inter-VM password manager and store for Qubes
>> OS.
>>
>> Check it out here!
>>
>> https://github.com/Rudd-O/qubes-pass
>>

What are the advantages of either of these over the traditional Qubes
model of having a normal password manager in a vault VM and using the
inter-VM clipboard to copy/paste passwords out of it?

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

iQIcBAEBCgAGBQJZDzwAAAoJENtN07w5UDAwPwYP/A1L6MTJWkSTAkopSLUFQnbg
bL0/6/YxjMNG7YBRSDhB0k5hAD70WOnHt/W2AyEkr6ihhVDkflmeAkBuc7tZgZNa
Us/9q3X3bgN/loQ/nCgAlVN+E5EqdzJyo1y94fSF9hrKKXCKPF1/nK+GxweGJl+N
PLd+oq1XjhQ8YVSI1z2yZhfO0ro5j85YhE3F/btLbNpyjVEu41JVtgdamYmHrz2O
C72llnuLedHoYJ7uTtw1inurkenndnHnGrRw8QdJFy9l8Lq8o30dOTS2/zqZriig
NF+LVlwDzJ5kostP1Rx8f/80RGhjqtqsalT+WGbgcSC/mOBzoPxKMi48tiD5BGxx
wb6hezl0fcl/JKep7DfwZm+LGmEXO/S1KLEyGhACSkiIGmEaKDnzPq3q/nq8DKRj
7ZDUjp2+chXdK0OxgGuc6/NpQkSrT0fqe3wawH/JZmg8rYi49mMxWMVNfc3Rvfvl
3d093U+2voFmlr3uyO/3q9TeMV/fRJY9ft+ygXwrMie9zCBLHfKS5bACldzCeaW5
JXqbkNuSmw48+f/QmS0EeRCPDCtv6cXB2vTN4rzxgKee7ww4p5JV6mqQi7RLA00Y
bJ7xP9BZb8R8eSXtLbsCmGpkSXMnyPl5NGgrkrFaktz4pYpH7+HGYXVOfvHxJkLG
I0EO4GdyH2SaXrj9OXke
=FKB/
-----END PGP SIGNATURE-----

[nick...@kulinacs.com]

I prefer Pass because it uses GPG for encryption, meaning I can manage fewer secrets over all (as it backends into my normal GPG key) and then track my password files in git. To do this with the traditional Keepass method, you either need to back up the password database somewhere secure or remember another password for it.

---
kulinacs

[Andrew David Wong]

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

On 2017-05-07 10:32, nick...@kulinacs.com wrote:
> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong

> <a...@qubes-os.org> wrote: On 2017-05-07 10:10,

> nick...@kulinacs.com wrote:
>>>> What benefit does this have over simply ysing
>>>> qubes-split-gpg-client-wrapper, like done here:
>>>> https://github.com/kulinacs/pass-qubes It seems like a lot
>>>> of overhead for not a lot of gain.
>>>>
>>>> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
>>>> <rud...@rudd-o.com> wrote:
>>>>> Building on the excellent pass (https://passwordstore.org),
>>>>> it gives me great pleasure to announce the initial release
>>>>> of qubes-pass — an inter-VM password manager and store for
>>>>> Qubes OS.
>>>>>
>>>>> Check it out here!
>>>>>
>>>>> https://github.com/Rudd-O/qubes-pass
>>>>>
>
> What are the advantages of either of these over the traditional
> Qubes model of having a normal password manager in a vault VM and
> using the inter-VM clipboard to copy/paste passwords out of it?
>
>

> I prefer Pass because it uses GPG for encryption, meaning I can
> manage fewer secrets over all (as it backends into my normal GPG
> key) and then track my password files in git. To do this with the
> traditional Keepass method, you either need to back up the password
> database somewhere secure or remember another password for it.
>

Why not just back up the entire vault with qvm-backup?

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

iQIcBAEBCgAGBQJZDz+kAAoJENtN07w5UDAwVdEQAKyEUNffYrCLsTK8TyRvWnyi
3dz15oDFHAL/PXkUHptcn4NJfU3BrmPBcf8DaBM2ROlXVJQayYZq9QwE1wlftxjr
+ZblvNOuYbc/+FGxGNpqimc7jSC5TSaaduMW47THp66xemYH55pVChD2WT3X/dk4
gn51SLYKE7tixnsOaqNEQSawpwbDsVaL4hLDgV4NLDKeZTbhLLxLbFlvikoMsUxY
BXj19mfje2oJrDAXEDUtDK9qq8tOjttK4EomVG0HQVinyhpKiLn/Nil91xQnKvES
H8QG9sEUUEGs0/GsYsXIkb3VJqRdkns5A1Cp5FR3/WTiIxBARfewXY3klQKO0UFj
zTovVZ3OgjuqmqDlkLLGRI5bn1NHZ2k9IFly4+8VUYXPOVBNdkKmIpqS3x0EPhuO
rFZmg/1OYHeT3FLt6WwDJilNGzN2I/FByx7AbwiEHGgspQYVviDRha2n6eCDGh0R
uIZ3/8iYj+QA+glXZFGj5ghIKjBiA6rcn7vTh7/r+9rGaOCCDCGY6L4ZrgL8Ao76
VOw1MnnzVHIOGjGQ0RacDN9qZ8D/YTy2BqZVUdF1RXoBb77LQgAfVfVAeIjzuWg7
KIlXI9ScIFqEbbcxC7w4SC1LHbEcET81q5B0tNzJUJ+QL0/CZQ9avrPHBOq9kVRs
NK8zRvknFnPargpog2UK
=vzjL
-----END PGP SIGNATURE-----

[nick...@kulinacs.com]

Git has less storage overhead (as you're backing up a bunch of text files, not an entire VM), allows proper versioning, so it is trivial to see your passwords at a point in time, and can be used cross platform if you chose to keep your GPG key on another system.

[Andrew David Wong]

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

On 2017-05-07 11:33, nick...@kulinacs.com wrote:
> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong

> <a...@qubes-os.org> wrote: On 2017-05-07 10:32,

> Git has less storage overhead (as you're backing up a bunch of text
> files, not an entire VM), allows proper versioning, so it is
> trivial to see your passwords at a point in time, and can be used
> cross platform if you chose to keep your GPG key on another
> system.
>

I prefer the security of qvm-backup[-restore], since it allows me to
keep the vault and its contents permanently offline. The entire VM is
BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
integrity verification, authentication, and decryption all happen at
the dom0 level. The backup is tiny, so the storage overhead is
inconsequential, and there's no need to worry about file-level
metadata leakage or the backup file itself being used as an attack
vector. KeePassX has sufficient built-in versioning for me, and it's
easy enough to sync Qubes backups across machines with simple scripts.

With this setup, considerations like "managing fewer secrets" seem out
of place. I only have to manage three secrets:

1. LUKS passphrase
2. Backup passphrase
3. Screen locker passphrase

Managing these three allows me to have an arbitrary number of
additional secrets in VMs without having to remember anything else. I
can't replace 1, 2, or 3 with my PGP key(s), because my PGP key(s) are
inside my PGP VM, which I can't access except via 1, 2, or 3. But
that's by design. I wouldn't want to make that replacement even if I
could, since I wouldn't want an attacker who gains access to my (one
of my) PGP (sub)key(s) to have access equivalent to 1, 2, or 3. I also
wouldn't want to use my (import) PGP keys on any non-Qubes systems,
since that would likely defeat the purpose of protecting them via
Split GPG.

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

iQIcBAEBCgAGBQJZD1gbAAoJENtN07w5UDAwu14P/2ZzxA5RM4QS/F+GhyafenJM
rQmgmxpZbDIENeiwCrxQGkPxO5vZjGXcIKsACekLlTVeWwNvmRtfOnQa5vvhBDyS
1WGoHYOnuODM7EVe2GZhA4gngRWiJ+iLFvvtRcApG6hMA7BwGqxsLUhl1XbQL3XA
EVYEIfkLZ8CffIe2QuXAwFMMc6uBYMHunTSeZPZHuy7DmGLEHacHuuJvUadxzHqF
r3zncyZeCwrFwUrJFgDE8UTXcrv5azuih4Pr1GN1G3HgsvpjfMTtyYZlfYJX1agQ
JonOQ//N6Fv8B2Fn5tFEGCHJN9hddfc1YW0xMvgHc8AbiBEGN4aUzb+pd+EprL8j
7uEsFnYy/zBs/TXMaQaAecQYIGOln76IDtUMNQhTmBTHdltJoe3yE0RdCP3T2zJj
d5dtP09imbNx2GFoac/6gA3HnmP/4rPeK6qnad7i0y1OyuMl4zTrU2AdqwcG4+S8
N0XGywpBlr+bDUCEuxtGO13pDPomgQXuPoOgZPmJORF/4T/KxEBMKEBEPVs1K81E
nblCCG6n80STe48a4Vk0Gv4IFw9Or/kFYR5M4B4UvnmJCoMaWj1a92VBC/8z8KCG
ck0MkR2y6KbA1wI3CUAF8GkjlIfEE2ewaU8BQcEQqKplL7gNV4NqfRbpMuvLe1LW
TK/sqfLYBdq0r/UsYQ+p
=dZn6
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

I should add that using the same passphrase for (some subset of) 1, 2,
and 3 would arguably be a very reasonable trade-off between security and
convenience for most users (i.e., a likely negligible drop in security
for a significant gain in the form of having to remember fewer things).

> Managing these three allows me to have an arbitrary number of
> additional secrets in VMs without having to remember anything else. I
> can't replace 1, 2, or 3 with my PGP key(s), because my PGP key(s) are
> inside my PGP VM, which I can't access except via 1, 2, or 3. But
> that's by design. I wouldn't want to make that replacement even if I
> could, since I wouldn't want an attacker who gains access to my (one
> of my) PGP (sub)key(s) to have access equivalent to 1, 2, or 3. I also
> wouldn't want to use my (import) PGP keys on any non-Qubes systems,
> since that would likely defeat the purpose of protecting them via
> Split GPG.

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

iQIcBAEBCgAGBQJZD1vAAAoJENtN07w5UDAw0PgP/jZwC1XYgGbXn6Oja5IkDKuF
09sfEZVlWsfUgWB+rT6X6sOX2cpUrxKSL/7e2Zb/YuebCDawwSycZxi1XVsOGP2y
sTxD8fi3k/t86i1LvgVFi7TbwKBjqwzvbP1en575iMrbTa8ye48Vg1tpaLmnt82/
GrDneJNgnQDw79bbjK0GO4Ak/Y3kAhZm9QRvaHNM4rKrdyI0fobDq18TXmaAIKi+
pIJ+fsO+CAemS2pfKuKjaCgzc3dEprzWqOpQgbcOq96dQZ/8t1QPoQqJirpBJ7Tn
Nj06YELPm+IgzPF+9KYRW/EiFJYF2gNBFpA4SNoj4R0fs2nuK2hRb4QCvsiIXGoR
8Bn7Ri5ns4B3Ky8prUWvvnOyXb83XxBe3nZ6q1SaKn4iKKoOYOYEn4KSzDOfH8hL
8edVCWuHNagJS3xXt3j7+xMNBFsYmdYFyuqpiJqq/cgqmiWJnmOp7h4M6y2CZ/9m
CPut/OUw4CFe8zHg7dUDA8Ihc5YGB2Ssegk0hGA3NhpamM3sOsTJ+hDPI/Uq7o1l
8LI4nRhpwC1gLXWKw++X0oPp2wZIYHY/ufB6cgqVnFlZjRhr3FHSpXom8yUOYWGk
dMvWUZM0oJ/Smq6aP4JobX0wBsC5lMhmCVxOf9jQCKh3aoA43Sapm46ekdDDItoP
kszj1eCEzqCrKNMRKki4
=J4QR
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 05/07/2017 03:10 PM, nick...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here:
> https://github.com/kulinacs/pass-qubes
> It seems like a lot of overhead for not a lot of gain.

1. The actual store is stored in a separate VM. It is never decrypted
in the VM you manage the passwords from.
2. You do not need to set up your own GPG key, as `qvm-pass init` does
it for you.
3. There are two different services — one for read-only access and one
for read-write.
4. There is a get-or-generate feature which is useful for stuff like
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins

>
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> <rud...@rudd-o.com> wrote:
>
> Building on the excellent pass (https://passwordstore.org), it gives me
> great pleasure to announce the initial release of qubes-pass — an
> inter-VM password manager and store for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass
>
>
> --

> Sent from my Android device with K-9 Mail. Please excuse my brevity. --
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com
> <https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 05/07/2017 03:23 PM, Andrew David Wong wrote:
> On 2017-05-07 10:10, nick...@kulinacs.com wrote:
> > What benefit does this have over simply ysing
> > qubes-split-gpg-client-wrapper, like done here:
> > https://github.com/kulinacs/pass-qubes It seems like a lot of
> > overhead for not a lot of gain.
>
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> > <rud...@rudd-o.com> wrote:
> >> Building on the excellent pass (https://passwordstore.org), it
> >> gives me great pleasure to announce the initial release of
> >> qubes-pass — an inter-VM password manager and store for Qubes
> >> OS.
> >>
> >> Check it out here!
> >>
> >> https://github.com/Rudd-O/qubes-pass
> >>
>
> What are the advantages of either of these over the traditional Qubes
> model of having a normal password manager in a vault VM and using the
> inter-VM clipboard to copy/paste passwords out of it?
>

These programs do not require user interaction as long as the policies
are properly configured. Thus, they are extremely useful for batch
processes or system orchestration purposes.

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 05/07/2017 05:23 PM, Andrew David Wong wrote:
>
> I prefer the security of qvm-backup[-restore], since it allows me to
> keep the vault and its contents permanently offline. The entire VM is
> BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
> integrity verification, authentication, and decryption all happen at
> the dom0 level. The backup is tiny, so the storage overhead is
> inconsequential, and there's no need to worry about file-level
> metadata leakage or the backup file itself being used as an attack
> vector. KeePassX has sufficient built-in versioning for me, and it's
> easy enough to sync Qubes backups across machines with simple scripts.

Git push takes 5 seconds.

qvm-backup requires anywhere between minutes and many hours.
Additionally, it requires the target VM be off.

Weekly backups are served okay by qvm-backup (I say "okay" because I
have a borg backup setup on my Qubes OS system, and it's far more usable
and performant than qvm-backup). Git push is much better suited to,
say, syncing your keyring to other systems.

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

Building on https://github.com/Rudd-O/qubes-pass, the new Ansible Qubes
Pass lookup plugin allows you to create Ansible playbooks and roles that
integrate seamlessly with your Qubes OS pass store.

Check it out at
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins

Enjoy!

--
Rudd-O
http://rudd-o.com/

[cooloutac]

I just back up the database file. its encrypted.

[cooloutac]

I don't think backing up the whole vault is a good idea if you don't have to.

[Andrew David Wong]

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

>>> Git has less storage overhead (as you're backing up a bunch of
>>> text files, not an entire VM), allows proper versioning, so it
>>> is trivial to see your passwords at a point in time, and can be
>>> used cross platform if you chose to keep your GPG key on
>>> another system.
>>
>> I just back up the database file. its encrypted.
>
> I don't think backing up the whole vault is a good idea if you
> don't have to.
>

Why? No need to encrypt the database file if the whole VM is
encrypted. Also, if your database file doesn't use authenticated
encryption, that's another thing to worry about. You may also worry
about file-level metadata leakage.

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

iQIcBAEBCgAGBQJZEVYkAAoJENtN07w5UDAwuAUQAMxJvs6Z5SK+2jJ7AaKPUnSQ
9sj2z7S4XzteTNRmV6e3c8MIiMuVUuO491B9/1p+s3ndsIZjQV2bK8gKwhsEvcJQ
/jGoRpq+cTsYN7PCup17oP+hXqZMO6w23ehgJa5KTDnHl8DzQWoaG3QqCmkFSPL3
W2QdJ2wYgH14xlIwwqsDdsawZsjHs18OLO8u5tsaUqYZZDkhKN9SIABXjCfm+4bN
za2xxcQlXX0HLEtGqHSRlBt36AKM0IYjQDh8ArM109E58uf+QWI/rXYe0U1bIRxR
7VyDSnNIH9qJ5GP25ZnTUu0czPTA3sh6Dr0y2gLfbvoEUmZfNRDX7IrSyVsG7q6P
+GKrr10Cawym8tLr/v3pSZ2DLRG+3Am/zsEOyGUY3Cg5xUG0lSyVJp8WIb2xGtND
o9mkaMaFV+iFFIxPzld5Wc9nwy7h+d3eF0b/fX32PsI+CpIVudOOpwibtPh1pte6
VMgclD00eQnabTjT3Egw6+8EvBsvDJc4smCJ/blWWRWgirRgdPwATlJ7CwxEICtW
8bwJTMXQsIeHqduEcBZO1qnI+sqaUF86KME2p6leD51qb+BUC/463l5En8terTe+
auIKVGdzcF5QRXihEMdJSDGrUgTsSUxoAdLFDEZGLWa1po62++3C0225DVvgOpp+
03AmrJMi0eyaJ0ndGJG+
=soty
-----END PGP SIGNATURE-----

[cooloutac]

the database file is automatically encrypted. I just feel like vault more likely compromised then the file if something is. but I could be wrong. plus way less space.

I think when we have paranoid mode it will be better.

[Manuel Amador (Rudd-O)]

On 05/09/2017 07:54 PM, cooloutac wrote:
> On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong wrote:
>
> Why? No need to encrypt the database file if the whole VM is
> encrypted. Also, if your database file doesn't use authenticated
> encryption, that's another thing to worry about. You may also worry
> about file-level metadata leakage.
>

> > the database file is automatically encrypted. I just feel like vault
more likely compromised then the file if something is. but I could be
wrong. plus way less space. > > I think when we have paranoid mode it
will be better. >

Backing up using anything like qvm-backup is always going to be much
slower — and require the VM to be off —than any file-level alternative.
Plus, if you need to sync your keyring between different devices, that
eliminates the possibility of using qvm-backup in any efficient way.

--
Rudd-O
http://rudd-o.com/

[Holger Levsen]

On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
> 1. LUKS passphrase
> 2. Backup passphrase
> 3. Screen locker passphrase
> Managing these three allows me to have an arbitrary number of
> additional secrets in VMs without having to remember anything else.

you really dont protect your gpg key with a passphrase??

and I assume you dont change the backup passphrase, because it needs to be high
entropy, despite being visible with "ps fax"…

I'm really not convinced this is a good setup, though of cause everything
depends on the thread model! :-)


--
cheers,
Holger

[Tom Hutchinson]

Thanks for the contribution Manuel. I'll check it out.

I can't wait for us all to get rid of passwords. They are garbage
technology and garbage security. I don't know - maybe that's just me.

Cheers,

Tom

> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170512115330.GC27029%40layer-acht.org.

[cooloutac]

I assume his Gpg key would be in one of those 3. Its all we got We basically have no choice.

[cooloutac]

Yes I agree.

[Manuel Amador (Rudd-O)]

On 05/12/2017 11:53 AM, Holger Levsen wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
>> 1. LUKS passphrase
>> 2. Backup passphrase
>> 3. Screen locker passphrase
>> Managing these three allows me to have an arbitrary number of
>> additional secrets in VMs without having to remember anything else.
> you really dont protect your gpg key with a passphrase??

qubes-pass will prompt you for your GPG key passphrase using the GPG
agent, just as you'd expect it.

>
> and I assume you dont change the backup passphrase, because it needs to be high
> entropy, despite being visible with "ps fax"…
>
> I'm really not convinced this is a good setup, though of cause everything
> depends on the thread model! :-)

Do please present an attack model and I can then reason with you whether
it is covered by the setup or not.

Note that the qubes-pass setup is *exactly the same* as the Qubes GPG
model, and intended to protect against the same attacks.

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 05/12/2017 03:02 PM, Tom Hutchinson wrote:
> Thanks for the contribution Manuel. I'll check it out.

My pleasure :-)

Agreed about the passwords thing!

--
Rudd-O
http://rudd-o.com/

[Andrew David Wong]

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

On 2017-05-09 14:54, cooloutac wrote:
> On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong

> the database file is automatically encrypted. I just feel like
> vault more likely compromised then the file if something is. but
> I could be wrong. plus way less space.
>

I don't see any basis for that reasoning. The files in an AppVM are
only as safe as the AppVM itself, unless the VM is used only for
storage or something.

If the vault VM is compromised, then the encrypted database file in
the vault is only safe as long as it remains encrypted. An attacker
who can compromise your vault can set a trigger that waits for you to
decrypt the database the next time you want to use it, then grab the
passphrase, decryption key, or the whole decrypted database.

> I think when we have paranoid mode it will be better.
>

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

iQIcBAEBCgAGBQJZF2N9AAoJENtN07w5UDAw8goP/itJWd/QiGchOPYmavzXB+AS
HKycQy2y4lvqHjl1cltPXP0unThvoK8BSgCWdm2wRbj7T/Lc5EG7mtCScXyZP6uc
ouFTMPjyjYECmINWaU/rNEOJRy5XR6q3AcVeObBRZxdst59g9GNtCXAgu47U7WjJ
8u+9wqEO1PD7Oo+ZlFZ971JMsYluU7uxHwqDYqFabPc+FvkD5hEIBM3tfXvmbJuo
qlhpQpVyudYcgCs8Xtt6e1P1GcSc0pXT03nd7mw8QeMsZq3Ua6x8tOEtAnl93pba
LXWoHEmLGg5BbYbkbXMeZYYTyM+e5f4MN78DkolaqzwD73IVITg+8ctJD+rNSgIB
dJhNeAVtsddyQ+7+3IHxsOSgVvnBANoC2e7iBLkVxd0zqKnT6hdbSNQPfrftIQzV
uATOBVgCy16/xjgOeqPENAbT9ElZfgIyEhN3HPQsOPhM0ASSdSgx+fHNH9RY/dZ7
aoWbILGJRL52J1R4koumXvbaWSHLo2HAIv1xljstedltDt4jyjDQtRfJ2Zbf7jK1
hGXZcsUtyZHyZklHyYb8ZiQa6gbGj3KBHQaz91TznTdgIV/G42iL+GFb1jej8TIS
2mBALx5WL82jo5Nmb/4GJ/5nb3ShBAeOm9YkfctQX0fXd3lweZ7h9i79rAocIrZ9
o87ju6uck1ri3q3q01Pt
=oKxB
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

On 2017-05-12 06:53, Holger Levsen wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
>> 1. LUKS passphrase 2. Backup passphrase 3. Screen locker
>> passphrase Managing these three allows me to have an arbitrary
>> number of additional secrets in VMs without having to remember
>> anything else.
>
> you really dont protect your gpg key with a passphrase??
>

See: https://www.qubes-os.org/doc/split-gpg/

> and I assume you dont change the backup passphrase, because it
> needs to be high entropy, despite being visible with "ps fax"…
>

Why is that a problem? It's only visible in dom0. If an attacker is in
dom0, it's already game over.

Tracked here, BTW:
https://github.com/QubesOS/qubes-issues/issues/1582

> I'm really not convinced this is a good setup, though of cause
> everything depends on the thread model! :-)
>

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

iQIcBAEBCgAGBQJZF2SYAAoJENtN07w5UDAwMf0P/1YRlQPo/C0/eUd1M/ZOjk+c
0niJvtOEQkJoo4QrOZqdJ/9CZa3KUYKlH6ktkzbg4TjrODgqRiffPhtTYmTmfxTL
8CMdD4HWSvXVLt4SEJYuX81NwS0BioHqk0lY5bA9dQCDFdb29O4cUvUX43h1+0Je
hQSK4Rcytp8vjelGSPTT9qDzMuVHu6tpUgYIYTwGPS67aeeVvnlT6VY6Q+QfUGr6
+GQWvGkspxTRg3ASml1UtMd4vglxkKvlwmVJTziY0IE/TN50xiTaXIVAvgyVQnf/
hn2gAyn2o5+ciP7Od18XhfXIlqcb8+R5Vn2nvyXtLAJP0zouNGtGDUiACAXXVFJ2
gwpP1yD/e0nmqsUMVYdG2GtuLKF1Y0fxtHswQpnHiPKP6N6hwcqmuRhgnN/GRlGS
jmcQWEETw3zEa/CwOiSyJhwVLxx8nHEjxTRnci2P7L9DHiXJTG+isZQ0innHSXV7
kHmv12Bf4pnpyxilpgDfJH7epZYuMWK1cUwDBDzEOvaH3ScHQyxU9rRd8sDYKlZO
28aK9NgT0xo6DTjgcLh+4z6ph5phrH2pRzrdniyCAyP79nDI4wBC3/bj/Q68aCij
q7jiQH5KxKxXNlr06DhNS4nGK0ugok0q1J5GFZtp4RIrktfopkEF8H4rrn2efoxa
vx2NzWi4br54hWbhS0RF
=Vyk2
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

I agree that qvm-backup is slower, bigger, and less efficient than
file-level backup/syncing methods, but the tradeoffs are pretty
reasonable for a lot of use cases. Since I can just start a script and
walk away, it doesn't really matter to me whether it takes a few extra
minutes while I'm not there.

Don't get me wrong, though. I'd love to see a more efficient solution
that combines some of the best effects of both (e.g., incremental
backup).

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

iQIcBAEBCgAGBQJZF2XJAAoJENtN07w5UDAwUL0P/i9TXn0XxN7U65Y8lmquVo2Y
29iUCeW6sfaXbBBsMmiO+Ptf400QAO4RQa0Yylrg9StROOScsXubbLo1ZBh9alsC
ohGxBIDaG0dUsaAqKnlHLBmyieYBZIbZ5qf93PwvldIJG1M8s8dfuvtKQFZa1zrF
E4ALvxs0qwkcO4zsXIrom2IwXLU5+DVov2N02qegxr3GBYTQEpq+k+meSNNEbpQi
N2CE+LU1oSSK7nI9zITVsICLJ3gROboh/h3EtgqS0BfmXLkHAgZ6EBMvw8KzkodM
HzJjRGfLKNo+kmJ/A+vdwfqO8FSKjBiC9cj2+vMrxmPbJYyc56pI7ircOVuTZETX
7COnAXveluyiej3qyXVUwgTaA6a1TAmaUJntEdtS1MWKlJ97nawPrPQFvGlh5IVg
yNZE3VphAbwJqyTFNI4ls5VrpVXgQ69lplcZFjWfe1OUqdWkiNwpBFi6yyWsRIq8
ZrBpVkNhlQe9Il2gX0iAsyKjjMgQxRPI50rNQ2EykLOeieRmJVv/cYkd7zOLU1t4
Lc760+odYqNW/ldXd1ndQIdhmlGbxOIc3ripLfklitlQtnYubAC28IYvp5jN30M/
4N7/N1HILAn8ssK4PTQycTPHNDLATG2wevvsM2K/ULjDHSrdjl2ir+Xn0VATjWXR
3fL65dRUR+U8aUYzCDp6
=3/mC
-----END PGP SIGNATURE-----

[cooloutac]

Because more attack vector. Seems like common sense for me. The whole point of paranoid mode isn't it?

As for attacker getting the key to the database file thats fine, in other words you also assume like I would that they are not turning it into malware itself. Even if they got the key thats fine if you are just using it to change your passwords using a new database and new key.

[Holger Levsen]

On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
> > you really dont protect your gpg key with a passphrase??
> See: https://www.qubes-os.org/doc/split-gpg/

oh wow :(

> Why is that a problem? It's only visible in dom0. If an attacker is in
> dom0, it's already game over.

no, the world is not black and white.

If an attacker steals your computer while it's unlocked, all your gpg
encrypted stuff is wide open.

If an attacker steals my computer while it's unlocked, my gpg encrypted
stuff is still locked. Surely the attacker can now install as many backdoors as
they want, but as long as I don't type my gpg passphrase into that computer
anymore, it should be pretty safe.


--
cheers,
Holger

[Andrew David Wong]

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

On 2017-05-13 18:39, cooloutac wrote:
> On Saturday, May 13, 2017 at 3:50:36 PM UTC-4, Andrew David Wong

> Because more attack vector. Seems like common sense for me. The
> whole point of paranoid mode isn't it?
>

What do you mean? Are you suggesting that qvm-backup has "more attack
vector" than an encrypted KeePassX (or whatever) database? Why?

> As for attacker getting the key to the database file thats fine,
> in other words you also assume like I would that they are not
> turning it into malware itself.

No, I think it's actually the opposite. An attacker could feed you a
malformed database file, which you believe is your authentic database
file. If it's not authenticated, you won't be able to tell. When you
try to decrypt and open it with KeePassX, it could try to compromise
KeePassX. qvm-backup is designed to protect against this class of
attack.

> Even if they got the key thats fine if you are just using it to
> change your passwords using a new database and new key.
>

I'm not sure what you mean. If an attacker has a copy of your
encrypted database and subsequently gets the key/passphrase to that
database, she can then decrypt the database regardless of what you
subsequently do.

Are you saying that you would render the contents of the database
worthless by changing every password stored in that database? How
would you know to do this? Are you assuming that you'll somehow know
the instant your database has been compromised? What if the attacker
changes some or all of your passwords before you do? What if you have
persistent passwords (e.g., not for online accounts) that can't be
rendered useless in this way?

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

iQIcBAEBCgAGBQJZGLRXAAoJENtN07w5UDAwmegP/imUHFRm0SadmiWdh6T71oWd
VaQt8TMrXoUeguysZEE3l0EwhWKbmET2KunXbkN5/RNfEz7wb9yIerNKnt5cTNMh
ko1ENAdNO9vWufJQyNSuZ+CScV/EL+tUG8626r28em1Rb2TknNk4COBb3pX0VRCC
RF3h7p+rSZufSy4xVuwVZRcllT94HhFTGpuvhzcB+f3FMmKjkTcYZLVL1gddiwcP
mEE1DAEGdsY5Y5eKl7xCAaiICvK2sSLWHTBGYZT3FZF6TSqLJ8iO92IoeMjPIbRS
+OShxw+ITr/g9oN+pSJ6con+mZk6xzrRC5ExZS9mRaYOLlXVx8LyC41cGVSxO0nb
KNoaMZqJ3nA8FtkfJ0Jo7786A2UBPYzSln4qzc8kqQ/23oa6Gevm9JckzixWLo3t
BnPN99fZ0zlspDcvkgPjoJhB3TPlUdvBbcHrWd5G93I/GIPCNp6yBvLAvoMyZcL5
RdZ4yH+CB7BK1aInrHaHtKN68Bjep5ZTBXCmWVwIuXN2g82kip7uQ9qPAUtFvSqx
B4a/N1MPkVB80DFLRFHDdDQM0ChiEj3ewA3NPp2mk6ECJbnq0lxUeWGMU93pufuN
Dqx5EpopP1bVX8amLr8eYn+2C+eTAxgZIj+lC+dUg/kmqn/kjq7mzS3sCyxc41ni
iZbzihGynHg5/sZ31Oft
=nZE4
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

You're conflating two distinct problems:

(1) Passphrases I've typed in dom0 are available in cleartext in
dom0.
(2) Data-at-rest is not encrypted while Qubes is booted and the screen
is unlocked.

We could solve (1) without solving (2). If we did that, it would solve
the `ps` + qvm-backup problem (the first problem you mentioned), since
my backup would be encrypted, and the thief wouldn't have access to the
backup decryption passphrase.

(2) is the second problem you mentioned. Solving (2) is distinct from
solving (1), but in order for the solution to (2) to be satisfactory, we
also have to solve (1) (or make sure no similar problem arises for
per-VM encryption), since otherwise my data-at-rest passphrase could be
obtained via (1).

I think the right approach to (2) in Qubes is per-VM encryption [1]
(probably with LUKS instead of GPG, and certainly not relying on public
key crypto, though hopefully we're all already in agreement on the
latter point). If I'm in an untrusted physical environment, I should be
able to work with less sensitive VMs without decrypting sensitive VMs,
and if someone steals my unlocked laptop, they shouldn't be able to gain
access to the encrypted sensitive VMs. That's the goal, anyway.


[1] https://github.com/QubesOS/qubes-issues/issues/1293

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

iQIcBAEBCgAGBQJZGLwgAAoJENtN07w5UDAwAbQP/juQIolMCIFVF8m+MP4pAOkK
2AssF3W2S9ta9HBj5zFQNxCPrkkg/cF0rK78iB5C4QevU/vXlGQSbtmudQL8vejV
S/tEXPQQZCpU9+9HOXkAAUSXGYxd8rr5j6xtUx5j+GwBV/1RFH1GEyzDAafU/bZR
7Sa8t0HPx6pjOPst85i0Fg++qmka/t0aBjTrjwk63LijqBZXz8FBpeQKdqAzv8Ip
he6/EpDSRP7H6VRuIm8iFeYs/6ohFOemesp8BMF7tcPYxOI68rQTtzdgpSYIf4ve
oALypvQ1oDJt8z/TKckbrGlIk5lYJfOuKq3/4MkyoZxM8V24yKPNaeeoyiEsLvOH
QrnBzyBSbxMIZnuHfNyTb5QGn+YM511hHaGQFSxqCPsSD4orVmuXpnJsm2YdEXeU
iChHyzdfsUrWOeh1TgqnfQ078AvK3JZKMwHwOYucYERgSMu5yUFjS57yv60FdmsH
yXl5S+I9CThKdr9y8mHq8GujEOlMjMG7eqlA8Q/Up48T7RQnHF8Ivrntkiwb4pBb
B2iciTO5KZ+JhcPqoNp/NPCvv3G4R2s0vtFF8QO3nMFjczVv9D3hrockRBEh7rkz
HMVaobICdqMKemHF4Dg30gqG5V9WDpiMwFybj2x339SoOLb6E3rMJ+YH3hM+vvVm
Bd5Hzi2hwvaAD/S31BZx
=6VoB
-----END PGP SIGNATURE-----

[cooloutac]

On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> >
>

> What do you mean? Are you suggesting that qvm-backup has "more attack
> vector" than an encrypted KeePassX (or whatever) database? Why?

> No, I think it's actually the opposite. An attacker could feed you a
> malformed database file, which you believe is your authentic database
> file. If it's not authenticated, you won't be able to tell. When you
> try to decrypt and open it with KeePassX, it could try to compromise
> KeePassX. qvm-backup is designed to protect against this class of
> attack.

Well if they can do that to one file, couldn't they do that to alot more others if backing up the whole vm? I would think one file is alot easier to check. Since that whole vaultvm is only dedicated to that one file for me anyways, and I don't have custom configs or scripts in it.

One cool thing I saw about paranoid mode is it take into account things in user directories that are not even user data to begin with. so ya I back up other vms that way especially templates, and especially vms with custom configs. or vms with just alot of data in alot of diff folders out of convenience.

But for the vault I just do the single file.

And so say if the database file is malware, what do you mean by qvm-backup would prevent it?

And yes "rendering it useless by changing every password". We are talking of the times you suspect it, have a hunch, if you think you can never tell when you are compromised then what else is there to go on? and what else can be done?

[cooloutac]

by a hunch I mean like noticing weird anomalies, freezes, crashes, mouse issues, lag, or just anything really, timing and sequence of events. after my account gets hacked do I still just say it could just be a random bug cause I have no proof?

if we really can't notice anything suspicious in even with live realtime network traffic, system logs, or file integrity logs, then what else are you supposed to do. Just already assume its compromised.

[Andrew David Wong]

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

On 2017-05-14 21:38, cooloutac wrote:
> On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong
> wrote:
>>>>
>
> What do you mean? Are you suggesting that qvm-backup has "more
> attack vector" than an encrypted KeePassX (or whatever) database?
> Why? No, I think it's actually the opposite. An attacker could feed
> you a malformed database file, which you believe is your authentic
> database file. If it's not authenticated, you won't be able to
> tell. When you try to decrypt and open it with KeePassX, it could
> try to compromise KeePassX. qvm-backup is designed to protect
> against this class of attack. I'm not sure what you mean. If an
> attacker has a copy of your encrypted database and subsequently
> gets the key/passphrase to that database, she can then decrypt the
> database regardless of what you subsequently do.
>
> Are you saying that you would render the contents of the database
> worthless by changing every password stored in that database? How
> would you know to do this? Are you assuming that you'll somehow
> know the instant your database has been compromised? What if the
> attacker changes some or all of your passwords before you do? What
> if you have persistent passwords (e.g., not for online accounts)
> that can't be rendered useless in this way?
>
>

> Well if they can do that to one file, couldn't they do that to
> alot more others if backing up the whole vm? I would think one file
> is alot easier to check. Since that whole vaultvm is only dedicated
> to that one file for me anyways, and I don't have custom configs or
> scripts in it.
>

No. With qvm-backup-restore, the entire backup blob is checked for
integrity and authenticity. That check will fail if any bit in the
blob has changed. Since the blob is encrypted, an attacker won't be
able to tell what individual files are in it, unless you divulge that
information in some other way.

> One cool thing I saw about paranoid mode is it take into account
> things in user directories that are not even user data to begin
> with. so ya I back up other vms that way especially templates, and
> especially vms with custom configs. or vms with just alot of data
> in alot of diff folders out of convenience.
>
> But for the vault I just do the single file.
>
> And so say if the database file is malware, what do you mean by
> qvm-backup would prevent it?
>

Suppose you take your encrypted database file and store it somewhere
(e.g., cloud storage, HDD in a safe deposit box). Suppose that an
attacker secretly replaces that file with a malicious one without your
knowledge. The next time you decrypt that database file, it silently
compromises your client or VM and leaks your passphrases through side
channels or does other nasty things.

If you had instead backed up the entire VM with qvm-backup, you would
immediately know, upon trying to restore from the backup, that it was
not the same trusted file that you had originally created, since Qubes
would inform you that the integrity and authenticity check had failed
when you entered your passphrase.

Now, if your password manager also uses authenticated encryption for
its database files, then that's fine, but as far as I know, most don't.

> And yes "rendering it useless by changing every password". We are
> talking of the times you suspect it, have a hunch, if you think you
> can never tell when you are compromised then what else is there to
> go on?

There's nothing wrong with acting on a hunch. In some cases, it may be
obvious that a VM or whole system has been compromised, but there's no
way to know for certain that a VM or whole system has *not* been
compromised.

> and what else can be done?
>

Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)

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

iQIcBAEBCgAGBQJZGRvVAAoJENtN07w5UDAwHAAQALd0vAijgbKELXG+Zc/lHT/Y
0MjYwfzxhjEzxD/nkqgVRjhX8Pjvwxq7LZGtSE0D6TlLl6VRM6OUwjsc2JCD7iSE
/HIij8h/D89wgIuWLXBD394sBuGvLOjoHsaDbSU/GHfN16r88YKJ6L1YDe5XPiwL
0AuM8zvVVcPshNa7QH7fnnWo/VlA9wM2zr6NfKIclEyW1Ty555SXztlG03sQIrDD
1J4+7/NM9zHUvaWtgoy2PcFEPbEiXcL5IqoWUeWxDQhG5fWFuUcYDK5L3dheN43A
B2YYwKK60DpH1/qIXjslpz6jYlV1KSAUaibI1GNQcXkj9HaQ6qHihUUCucYUbrIY
pfMAmtPxOPpReA0HLRT0EurLsknVZ4dj/Va0oUbbL12ZbIsZM6qSoGHA2Uc/8I1+
wQKWOaeSeiluARGwQMfHDOEoM9D6JzJ7LqRhCrV6jAuwMeWiFdeBd+6l/wtN8e9g
UNqoKqK0JOJMJXiQct9zrZ0vyeqGloyW7X/BmytAM/MTznsa5fA+lzG5gx7/IWrZ
BFarprX2R2rIrFkQoEn3LO0DkfjQs+7QKpKXLuvl3lk11Slib13Ah2qLfcV7dMg2
8PpHxVkmuLMfbHwCDFZZSs1K3jZ+c9J0wZZF46bqWqt5DeZi9F+JkBQ53/V2a3dW
52CXFlG7RHmJXxVujHjT
=Z70t
-----END PGP SIGNATURE-----

[cooloutac]

So you are saying qvm-backup will know if an attacker has switched up the backup file, which is well and good. But I'm assuming the vm or file is already compromised before backing it up in the first place.

Also apparently qvm-backup has not taken every file into account or there would be no need for paranoid mode. I still believe having to only verify the integrity of a single file is better then a whole vm.

Although this discussion makes me think maybe when loading the possibly compromised keepassx file I should load it in a disposable just to get the passwords, but not open it in the new vault vm I'm going to create. But then I uess I als can't copy and paste what to do about passwords 100 characters long? lol

[Piit]

Hello,

maybe somewhat off-topic, but the question came up after following this topic.

Am Sonntag, 7. Mai 2017 16:50:35 UTC+2 schrieb Manuel Amador (Rudd-O):
> Building on the excellent pass (https://passwordstore.org), it gives me
> great pleasure to announce the initial release of qubes-pass — an
> inter-VM password manager and store for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass

qubes-pass brought my attention to pass(wordstore) which I haven't heard of before.
I've setup pass in my vault AppVM, which I am currently using to host my credentials with Keepass. This works quit well, even, when this involves some Copy&Paste.
Testing out pass I realized that pass can only store username & passwords but no other information. Often I want to store username + password + emailadress (which I have used during registration) and maybe additional information like a comment with a customer nr.

Can this be done with pass or a workarround which is using pass to store the credentials and store the metadata at another location.
I'd like to keep all information together.

- P

[u+q...@bestemt.no]

'Piit' via qubes-users <qubes...@googlegroups.com> [2017-05-16 10:49 +0200]:

> qubes-pass brought my attention to pass(wordstore) which I haven't
> heard of before. I've setup pass in my vault AppVM, which I am
> currently using to host my credentials with Keepass. This works quit
> well, even, when this involves some Copy&Paste.

Use the -c flag to copy the first line of a pass file (usually the
password) to the clipboard (e.g. "pass -c somedirectory/somepassfile").
Then copy the contents of the clipboard to the Qubes clipboard with
ctrl+shift+C.

> Testing out pass I realized that pass can only store username &
> passwords but no other information. Often I want to store username +
> password + emailadress (which I have used during registration) and
> maybe additional information like a comment with a customer nr.
>
> Can this be done with pass or a workarround which is using pass to
> store the credentials and store the metadata at another location. I'd
> like to keep all information together.

Yes. "pass edit somedirectory/somepassfile" opens that file in your
default text editor. You can add as much information as you like. See
"Data Organization" on https://www.passwordstore.org/.

--
ubestemt

[Andrew David Wong]

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

On 2017-05-16 01:24, cooloutac wrote:
> On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong

> So you are saying qvm-backup will know if an attacker has switched
> up the backup file, which is well and good. But I'm assuming the vm
> or file is already compromised before backing it up in the first
> place.
>

Oh, that's a quite a different scenario from what I had in mind, then.

> Also apparently qvm-backup has not taken every file into account or
> there would be no need for paranoid mode.

I think you might be misunderstanding Paranoid Mode. VMs that you
restore using Paranoid Mode may (still) be compromised.

> I still believe having to only verify the integrity of a single
> file is better then a whole vm.
>

Well, the backup is itself a single file.

> Although this discussion makes me think maybe when loading the
> possibly compromised keepassx file I should load it in a disposable
> just to get the passwords, but not open it in the new vault vm I'm
> going to create. But then I uess I als can't copy and paste what
> to do about passwords 100 characters long? lol
>

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

iQIcBAEBCgAGBQJZG6fvAAoJENtN07w5UDAw6AoQAL6fnfWaRFSy3hSg2lZypLk1
e7ypb/OmuYgCJD8zlYI+JjJdSW4ocsIoyRN6+tQXrCsTDSYpU6z6OX1jeyZb1XLR
Jsfh4Bx8ie2dfZi4bGzdhPcXF/LFgB4NlBB4HTq8OaaDyYFaCOOyu6ANfSVFAUal
R77koWT4O5/cpjt3RrkWJRI9ssv6pHm1jJZzN5T2HeKSkzwIjeB+r+dZkWmtGUzt
TuZPsziXlPkIbCGwAwMb9qT9sz3Oeu0cl7x1nIhXXpVWEo0ovO09uowcUPUxr8Z5
ekvkXzvkgpi6hmGquaUKv6bG7aiDJD1xCW8b74jfExbcQPBHD4sMVWKF3k5MUh39
GsXd5XlgxiYjjUz2cPfME/9w154BFVtuH5S4/daq2PchqhYexHhnUqG217iv0UQU
VY4c0M82IZubew1/73DDTJ7cRADCsJ1Aw2DOO8h8SAKkdg4XQ/p2iBnG4xgvSQxX
mfKuWIF6S9z7X2P39fSn42IhcQC+vhcb70oqoWZ3CFkpZGVKOEiazZuJ2L2RAOYn
DNEvUJ/U2Sp2QUQ1lNyG1CfypR0eGftVopWGrQc2Zodw2P8DNnxygLrlJMFuJ+MY
+BUA3c273WxDxkJ4U4crOQGSl1g4jhqtGiWSr23fzsUIZoOE42o8Vmh9gSl5tnGb
fSo7rrA30ux2TyxtsI5B
=N4TQ
-----END PGP SIGNATURE-----

[cooloutac]

well I thought paranoid mode just disabled copying of some non user data executables and mayb some other stuff? And yes would have to assume it might still be infected. Sounds good to me Definitely something to think about though.

Yes qvm-backup is one file but after extracted, like an iso, is alot more. But with paranoid mode then we can just treat it as hostile but it is less capable to extract data we need. If a data vm maybe even just keep the paranoid vm for like pictures and stuff right?

[cooloutac]

I mean cause if the pictures gonna be infected anyways, might as well keep them in a vm stripped or disabled of things that can do damage. All i do right now for my media-vm is disable internet access.

[Jean-Philippe Ouellet]

Solving 1 is not a simple matter of patching some things to pass
passwords on stdin instead of argv or env vars, it would still be a
mostly trivial matter for an attacker to just make a core dump and run
strings on it. Rather, I believe a proper solution to 1 would require
that dom0 to some degree distrust whoever is physically at the
keyboard. A "kiosking" of Qubes, if you will.

Also, I do not agree on your assessment about symmetric crypto being
obviously the way to go. I think there is value in being able to
initiate a backup from inside a hostile environment (think: someplace
with cameras everywhere watching any passphrase you would enter),
which would make sense to implement by encrypting to an asymmetric
keypair for which the private half is only in a separate physical
environment. (Sure, yes, use a symmetric algo for the bulk encryption
and just encrypt that with the asymetric algo... not my point.) You
would not be able to decrypt your own backups until you had regained
access to the private half, but you would be able to start backups
without needing to divulge your backup secret at the same time. In
this scheme you would also have another keypair with the secret part
on your laptop in order to sign the backup (authenticating it with an
asymmetric signature without requiring a passphrase at backup-creation
time). I've made this argument before, but perhaps never presented it
well enough. Expect a PoC in the hopefully not-too-distant future.

Regards,
Jean-Philippe

[Andrew David Wong]

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

Encrypting a backup to a public key, where the private key is not and
never has been accessible to the machine creating the backup? You have
to admit that's a pretty remote edge case for Qubes, which is supposed
to be a trusted single-user system.

I'm not denying such edge cases exist, but it should be obvious that
statements like, "You should use symmetric crypto for your backups" are
not meant to apply in such remote edge cases. Rather, they're meant to
apply in the vast majority of cases in which they make sense. If we
tried to qualify every statement to make it perfectly accurate across
all domains of possibility, we'd never be able to say anything.

(By the way, just because a camera's watching everything you type
doesn't necessarily mean you have to use asymmetric crypto. You could
use, e.g., a preshared keyfile instead.)

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

iQIcBAEBCgAGBQJZI8aTAAoJENtN07w5UDAwwgoQALjoWMYgAMey/q1vrEwKnYse
xJ1hpSTiq1VpmQJ3AcPZTwUEXQ80JQs2jKn+8r/LyayxvyUoo5v83mJZ/3/R7UV3
jwC2fC4+ITdDUZUbDEIHHDTmi6/EClZ6XZVisZvnNPHMDozFxYsyeY1nqXFonnjq
KwIKUR7On6M5hHuvzoyftnA8Ek+jUTp3xO6vKqzD8IqynGERZAu/4DOzmwoVKyr2
7QUJN2zpwM63CRdG1VNCkmuUuN8DflZHUp1EOTbW/fF2AjBucZPI51vVkelpD++7
g9k27sSwV606CiCtCar2B8Vopdt0DM1i/89Rqfj3vCg4G6FaNXA8nB5hg6B3rxfC
kRnlv/IgVStE+VQAY6f+l+X1IzlODQ3mYccwavm3bvkeWl3fzawGA2P/PUkqoztE
+ig2FGkMcrtItnqKRPmwsdKUMLmTpP1djBR6ToeO0wr6cY9bKSm0tYGYqa0ab5Pi
xSSwiE337ynRJ1eZrsXN0noICsBND0Olc+pqCmxJODEx7hAXEjzTRGW/k53Z/bMf
+mKsjimCtrkqrzFfXZHcrIVbEpx7Yf/kw/0BlVBMVdtgbvOReVwNjWhDwRUZ+RJe
1hAnUmpDQwDfMgG5SxoX40UDhllI+T4ToIX4HlsjYalgas4p091mYwkqeOpZxpda
9KwKFXjo+FTGt4O6a3fW
=ZITB
-----END PGP SIGNATURE-----