-----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----- -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/383ebf73-ef21-60e8-6d33-26a7105c5405%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
