On Monday, March 27, 2017 at 1:16:10 AM UTC-4, Shane Optima wrote: > >which may or may not be *detected* by a sharply observant user, but could > >still not be *prevented* by one > > Um, that is incorrect. I'm not sure you understand at all what I'm talking > about here so let's go over it step by step: > > A. User visits a site associated with a pre-stored password and presses a > special key combination. > B. Dom0 polls the active window title repeatedly over let's say one full > second. Attentive users may at this point glance briefly at the window title > to make sure it matches what the website is. (This isn't *really* necessary > given how infeasible an attack would be, but a single glance at the title > during the polling period is all you need. You don't need to stare at it. I > often glance at the HTTPS when I visit sites, don't you? Why not glance at > the window title?) > C. At the end of the polling period, Dom0 copies your password to the > clipboard of the VM associated with the active window. > D. If the window title did something odd, DON'T PASTE YOUR PASSWORD IN THE > PASSWORD FIELD. And definitely don't paste your password in the password > field and then hit submit. > > It's as simple as that. > > Since we're talking about non-compromised VMs only here, the attacker will be > unable to retrieve the clipboard and your password will thus be safe. > > You might do something like write a browser extension to automatically paste > the password in the password field as browser password managers typically do. > Such an extension could and should, of course, take additional measures to > ensure the password is the correct one intended (I can think of a couple > mechanisms offhand.) This is preferable, and it's also something that would > take more effort. > > >Your argument appears to reduce to "This may be theoretically > exploitable, but the ease of implementation and additional convenience > is more important to me" > > Uh, yes. That's Joanna's philosophy, too. Everything is a tradeoff. I'm not > claiming that she would agree with me that this tradeoff is a good idea, but > the perfectionist stance you appear to be taking, as embodied by this > statement, is antithetical to everything I've seen in the Qubes philosophy. > > Qubes is about reasonable security (citation: the Qubes motto / tag line) > with reasonable usability. If security always trumped usability, surely there > wouldn't be a GUI at all. (If I'm not mistaken, that's pretty much the > approach the OpenBSD people used to justify their superlative claims.) > > >hold, passwordless sudo is *not* a theoretical weakness > > What rubbish. Yes it is. > > >The key difference between this and the passwordless sudo argument you bring > >up is that the qubes security model explicitly assumes that user->root > >privilege escalation within a VM is possible > > The 'Qubes security model' depends on user behavior to support it. It > actually puts a far greater burden on the user to not be stupid (e.g. use > banking VM for all kinds of other stuff) than this password tool would. If > you insist there's no theoretical security loss with passwordless sudo, then > there surely is no theoretical security loss with a password tool such as > this. > > Heck, we don't even need to consider remote attacks to see how usage entirely > determines the security implications of a passwordless sudo: a person walking > by can compromise your un-screenlocked machine. And this is already a threat > model that Qubes takes seriously, as demonstrated by their anti-evil maid > packages. Obviously, a passwordless sudo in Dom0 or the VMs is a major > vulnerability whenever physical security cannot be guaranteed. You are not > just relying on the user to properly use screen lockers, but you are also > relying on the screen locker software to not fail. > > An uncompromisingly strict obedience to the security in depth principle, with > no regard for user convenience, would surely frown on such a single point of > failure, no? > > But I repeat, I mostly agree that the convenience of passwordless sudo > outweighs the risks, and even I would go a step further and say that this > could be an example of an inverse of the password post-it note effect: when a > secure tool (such as Qubes) becomes significantly easier to use with a very > small additional risks incurred, it results in a REAL WORLD SECURITY GAIN, at > the cost of some additional minor theoretical security risks. > > This is exactly as it is with a password manager such as I describe, except > the risk is even more negligible because the attack would have to be > conducted completely blind and could be easily spotted and foiled by an aware > user. Such a tradeoff should be acceptable for the first iteration of a > password manager. Later iterations could use browser extensions or multiple > VMs doing fancy tricks or whatever long term solution is best. > > And as far as my using phrases like "attentive users" goes, another analogous > situation can be found with something else that's already shipping with > Qubes: Whonix. In many situations, Tor can be more dangerous than no proxy at > all, even if you fully understand how it works. For a noob who understands > nothing but a magical gateway that makes everything private, Tor is a > liability. > > Let me end by stressing that there could easily be good arguments against > such a tool... it might be harder to implement than I imagined, or it could > be that I'm the only crazy person copy-pasting passwords from offline VMs > thus no one else would care because this tool would be a bit more cumbersome > to use than a browser password manager, or perhaps there's a much better > solution that's already in the works.
read your last paragraph. no you're not crazy, that is what most Qubes users do I believe. copy and paste passwords from their offline vault vm using keepasx. -- 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/f419523b-9396-4753-bfaa-6a0b2479b1fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
