-----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 > wrote: 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. :) > > > 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----- -- 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/c3e54ed4-ef89-8bff-3c35-61e8417a2782%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
