On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong wrote:
> -----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-----

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/33251e19-d115-48a8-9dbc-789a1393e4fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to