>Yeah, it could be dangerous, but still might be worth writing for oneself if >the threat model seems appropriate. I wouldn't suggest this as a Qubes feature.
As an out of the box official Qubes feature, no, but it seems like an excellent stopgap and stepping stone given the ease of implementation and the infeasibility of exploits. I personally think such a project would be acceptable and desirable as a beta or experimental thing that the user needs to opt-in for, or failing that an unofficial project. >Sure, you could be super careful, but you're still pointing the gun at your >foot. Better my foot than my face. Can you at least recognize that this would be an entirely opt-in tool? There would be no risk to anyone who doesn't use the tool even if it's enabled, and (barring the use of additional spoofing exploits) there's no risk from a specific site unless you use it with that specific site. This is all inherently granular. If you don't trust one specific site, just use the browser password manager or a long term cookie. The two can be used in tandem. I'm not going to memorize fifty different twenty character passwords, manual copy-pasting for everything is too cumbersome, and I've discovered the hard way that passwords cannot under any circumstances be shared, even among seemingly reputable sites, so the real question is what you think we should all be doing in the meantime. Exploits that target browser password storage or cookie exploits? They already exist, regular usage will not spot them, and a compromise of a browser means the immediate compromise of all your passwords. Given the potential for using DispVMs on a regular basis[1], this latter point is particularly important because *all* compromises on a DispVM are temporary ones, so if you can limit a single breach to only compromising one or two logins that's a huge win. Exploits that could target this Qubes-specific password tool? Ludicrously obscure[2], cannot work against an attentive user, cannot be done stealthily-- attentive users can release warnings for the less attentive users to heed, can't be used to snag a password from another VM, etc. A successful attack is quite implausible. And once the ball gets rolling, someone else can add features to it to make it much more secure. By the time anyone cares enough to even try the attack, it will almost certainly be guarded against. Your primary concern can be mostly addressed with simple, straightforward hack: a browser extension that overrides the page title in some fashion. This could be done in a manual whitelisting fashion, or ideally you could append a token computed from a hash of the URL (salted with a random per-VM value that isn't known to the attacker.) This would not only protect vs. spoofing, but if you modified the password manager to use only the token it would also prevent page title changes from breaking the tool. And then a third person could come along and make it sexier by automatically pasting it in the password field for you, and a fourth person could add username + password support, and a fifth person could add a keyboard shortcut to make it easier to create new stored logins on Dom0... and suddenly you have a full featured, easy to use, fairly secure tool that everyone starts using. And then a sixth person proposes rewriting the whole thing to use on something much better than window titles and copy-pasting (perhaps using the split VM scheme you described), and at this point it hopefully becomes an official Qubes tool, one that can be proudly touted on the box: "Password manager runs on a secure offline VM!" And at that stage, perhaps Qubes could even offer start offering subscription cloud services to keep your precious passwords available and backed-up (with a master passphrase that decrypts locally, of course), with maybe an eye for offering more truly *secure* cloud services down the line. Or at least that how it goes if everything unfolds as an ideal UNIX-philosophy bazaar. But I'd rather risk that pipe dream stalling along the way than wait around for five years with nothing but a "go roll your own." None of that is a regression. >You don't even need to rely on the window title for the security aspect That did occur to me; I was jsut pointing out that even simple string parsing of the window title should be sufficient on its own (provided you're intercepting it before the Dom0 WM appends the VM name.) >xdotool also lets you inject keystrokes into windows. That, I did not know. >Automatically injecting the keystrokes removes the "just watch the window title and don't paste if it changed" mitigation 'Automatically', yes. But even if you're not doing it automatically, xdotool might be better to utilize than the clipboard so that neither the hyperboard nor the VM clipboard contents get clobbered. > With a shortcut-key assignment this can be easily scripted by the user (you > said this was for power users). There's easy and there's *easy*. My preferred definition of "power user" includes editing of config files but generally excludes scripting. I can do it; but my experience is limited and I'm liable to overlook things I wasn't aware of (like xdotool). Conceptually, this is pretty simple and all the hard work has already been done, but I wouldn't be shocked if what might take others an afternoon to write could end up taking me a fortnight to do properly. If this is something that a lot of people either are desiring (being fed up with copy-pastes) or have hacked together on their own, I think it would be worth organizing into an unofficial project at the very least. There might be too many people in the world already who are all talk and no code, but I probably wouldn't be the best person to set it up to said lack of experience. However, it's out of recognition and concern for the hard work and the limited time of the Qubes team and Qubes enthusiasts that I'm suggesting this as a straightforward, 'first stepping stone' sort of project instead of merely suggesting a polished end product. My Qubes wish list is two pages long, but this may be the only thing on it that makes me pause and say "you know, someone could probably put together something very decent in an afternoon. If they knew what they were doing." I'll get around to it eventually, but I'm hoping that someone else will manage to beat me there. In the meantime, I'm playing to my existing experience and strengths, which generally involve picking apart and analyze the crap out of things. 1. I don't use it for my email and banking yet, but that's mainly because we don't yet have multiple DispVMs. Once we have the ability to remove persistence from any AppVM, I suspect virtually all of my browser usage will be on such VMs and the prospect of keeping passwords out of the VM until/unless they're needed becomes powerful indeed. 2. This sort of obscurity should never be an intentional design goal, but neither should it be omitted from the *real world* security calculus. "Security through obscurity" is a widely misunderstood and widely abused concept because the "obscurity" can mean very different things and have wildly different implications from case to case. Many kinds of obscurity are (taken alone) desirable; the key question is what you are giving up in exchange for it? It's usually a very bad thing when black box type obscurity is intentionally pursued as a means to prevent scrutiny by would-be attackers. A related but distinct type of "obscurity" can apply to complex projects, including complex OSS projects in the sense that perhaps 'not enough eyes are looking at it'; in other words, perhaps a more well known product might be preferable even if it has more known flaws simply by dint of more people having examined it. This is usually a tricky assertion to argue either way. But this isn't a black box and barring some surprises with how browser window titles can be manipulated (Could it ever feasibly display one thing to the user and report something else to the tool?), it isn't very complex. -- 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/ac82bd1d-726c-4dd0-b887-2eb92d1e6394%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
