-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-01-27 18:11, anoa wrote: > On 01/27/2017 12:21 AM, Andrew David Wong wrote: >> [Please don't top-post.] >> >> On 2017-01-26 20:21, [email protected] 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. >> >> > > 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 :) >
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----- -- 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/bb8f7b16-b577-25b7-06ed-fd21ce21c8f6%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
