Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>usability is not a good reason to add or change anything. I suggest you switch to running Lynx on OpenBSD then. I guarantee you're running all kinds of horribly insecure stuff on whatever you're using to read this right now. Usability has always been a top priority in Qubes and that is a major part of why it is such an excellent operating system. Why on Earth do you think they bothered making a GUI tool? Why don't they require a password for sudo? (Newcomers: that last one was a rhetorical question that I've already analyzed at length; please see older messages om this thread.) >Yes i'm a noob, but you still sound like a security nightmare to me. Security isn't a gut feeling thing. At least, not in the way you're doing it. Your gut needs to know what it's talking about first. > You lost me way earlier when you mentioned browser extensions Exactly my point. You don't understand at all what the purpose of the browser extension is. All it does is generate a token that Dom0 uses to look up something in its index. If you can't follow me trying to explain what the extension does (it generates a token of about 3 characters according to a specific set of rules, and appends them to the page title. That's it!), let me try instead to explain what it DOESN'T do: A. The extension would have no way of knowing if the Dom0 code was actually doing anything with a particular token. It wouldn't know if the Dom0 code was running. It wouldn't know whether or not the Dom0 tool was even installed. B. As per the above, it would receive no feedback or input from Dom0. C. It wouldn't be involved at all in handling the username / password (although I guess someone could write another extension to automate that as well. But this probably wouldn't be high on my list of priorities.) D. At no point would the extension cause any data whatsoever to be written to any files in Dom0 except perhaps in the form of a logfile (which the extension itself isn't aware of or capable of accessing.) E. At no point is the extension concerned with the keypress that activates the tool. It doesn't know or care when or how any of that stuff happens. It keeps providing index tokens all day long even if the password key combo is never pressed. F. It would be entirely optional. The password tool could function just fine without it, but would be vulnerable to a title spoofing attack (not as dire a threat as M. Ouellet thinks, but it's there) and it would require a bit more effort to set up your password list on Dom0 and keeping it running smoothly. G. The extension should be thought of as an *extra layer of armor*, not an extra point of failure in this setup. If someone exploits a bug that causes the extension to crash or behave erratically, the tool on Dom0 immediately stops providing passwords. It *can't* provide any passwords if it's been set up to use the tokens but they aren't being provided. H. Building on G, if someone manages to compromise your entire web browser such that they can either disable the extension (or control it) AND they can read your randomly generated salt... then yes, they could intercept your passwords on that VM. And this is what they could do in any other situation involving a catastrophic browser takeover. But you're better off in this situation vs. using the browser's built-in password manager, even an encrypted one. Vs. manually copy and pasting passwords from an offline VM, and it's roughly the same situation. I. Mistakes and misconfiguration should just result in nothing at all happening. Pressing the activation key for the tool while you're on the wrong site results in nothing happening except perhaps an error popup (that is handled by the Dom0 tool, not the extension.) > If my Mother can handle ctrl shift c, I'm sure you can too. This is akin to telling Joanna that your mother can handle running 5 different VMs in Virtualbox, so she can too--crazy window mixing from different VMs? OMG! That's a security nightmare! You've no idea what you're talking about, and Ouellet refuses to consider the version with an extension because he knows there is no plausible security hole. He doesn't like it because it's messy, and I agree, but open source software has rarely been driven forward by anything but people giving in and hacking together something kinda messy. Messy doesn't mean full of security holes, it just means... messy. And if you're telling me you use manual copy/pasting for everything, and you don't use persistent cookies, and you use a DispVM[1] for everything that requires a login, and you don't use a password manager, AND you have strong randomized passwords for everything, AND you have more than a couple dozen accounts, AND that you use your computer heavily, with a decent amount of DispVM restarts throughout the day... Well, I don't believe you. Nobody who tried use to do it all manually, with heavy usage over a prolonged period of
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
> Don't be scared. It's a Shawshank Redemption reference. >>An additional key combination to insert information into the Dom0 database >>from a VM would be a minor convenience that could be put off until the tool >>is overhauled (and probably moved out of Dom0 entirely.) > How many times do you see "insert" and the word dom0? I'm assuming you're merely being lazy here, in which case I would appreciate it if you would refrain from spreading lies about things you can't be bothered to read. This is a difficult enough discussion without nonsense being injected. If this isn't a matter of sloth and your reading comprehension abilities are actually limited to simple pattern matching, then there's no point in continuing this tangent. Even assuming you ignored my clarifications entirely, you should pause for a moment and consider how reasonable it is that you are using a sentence containing the phrase "probably moved out of Dom0 entirely" to claim that I am proposing that $foo should be done in Dom0. -- 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/8e12c35b-9b52-426d-b2bd-feba21fd7baf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>I wouldn't want a vm inserting anything in dom0. You're *still* spreading this nonsense? After what I just said? I don't know how much more clearly I lay this out, but let's give it a shot: Nothing is being 'inserted' into Dom0 and this does not in any way "open up" Dom0. This is a one-way street from Dom0 to the AppVMs, utilizing channels that already exist, and it could not function at all unless the tool was running *and* the user had manually set up a list of passwords in Dom0. Even if VMs are *completely compromised*, they remain unable to insert any information whatsoever into Dom0, they remain unable to generate the key combination that activates the tool, and in case of a spoofing attack (in the context of a total VM compromise, which goes far beyond the spoofing scenario suggested by M. Ouellet) they remain unable to request any passwords that the user had not previously earmarked as being associated with *that specific VM*. The Qubes isolation-based security model is thus being entirely preserved here. The aforementioned 'minor convenience' of the flow of information going the other way isn't being discussed at this time. It's not worth the bother and security implications, which is why I said that such functionality should wait until a more mature version of the tool comes along--a tool that probably doesn't utilize window titles at all and probably doesn't run in Dom0. And that feature might not even need to be implemented; there might be no real benefit vs. simply entering everything directly into the offline VM. I haven't thought about it yet! Because it isn't being discussed! As a *minor* convenience, it simply isn't on my radar right now. The concept was mentioned only to emphasize that it is what I am NOT suggesting. Capisce? Once again, the simple-to-create prototype version of the tool being talked about consists of Dom0 looking at window titles and then information flow occurs in a one-way street from Dom0 to the AppVMs, uses existing channels. Other than an optional anti-spoofing browser extension, the VMs would remain *entirely* ignorant of the existence of this tool, meaning that an attacker who entirely compromised a VM would not and could not know whether or not the tool were installed or running in Dom0. >I personally find you suspect. I'd tell you what I personally find you to be, but I don't wish to be locked up in solitary confinement. -- 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/b3381dac-bf82-41f6-bd09-1cb498b24aa9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>Here's a super simple (but likely quite effective!) exploit which took me a >about two minutes to write It borders on intellectual dishonesty to put this immediately after my bit about using a browser extension to modify the page title in an unpredictable manner. Your pseudocode doesn't work at all using the browser extension I just described, nor can it be fixed to work unless the VM or browser is completely compromised by the attack (in which case, the passwords would be lost regardless.) Again, I'm now talking about an easy-to-write extension that would hash the URL with a randomized salt. It uses this hash to insert some characters into the page title, preferably at the end where the user isn't likely to care or in many cases even notice. After this browser extension is created, the Dom0 code could either work exactly as I previously described with no modifications needed, or you could change it to look for and make use of that signature. This would have the advantage that the tool wouldn't break even if the page title changed, and it would also be easier to set up the password database; instead of mucking about with page titles, you would simply enter the URL and the password, along with the value of the salt that the browser extension generates during its installation. >If you're going to write an extension then there's no reason to use window >titles since you could communicate over another channel which is not under >full attacker control by default, Such as? As a small independent project, it would be much more dangerous (as well as more difficult) to design and implement an additional channel of communication which could be abused in unforeseen ways. I think I've already said a thousand different ways that an ideal solution wouldn't use window titles, but piggybacking on the already-implemented communication channels between Dom0 and the DomUs is very easy to analyze and reason about. Which is why it was so easy to come up with a method of protecting against the attack you keep FUDing about. I maintain that this is a limited and unrealistic attack (your pseudocode ignores my earlier rebuttals entirely), but instead of continuing to argue about how limited and unrealistic it is, I simply showed how easy it would be to entirely prevent, even if the user isn't paying attention. I even mentioned this possibility in my very first posting, before your first reply! Of course this isn't an ideal mechanism, and if you piled some additional other bugs or exploits on top there might still be some theoretically possible attacks lurking in the wings. But if you wish to continuing arguing that this is incredibly dangerous and less secure than the status quo, you need to actually find one of those bugs and delineate one of those attacks. Instead, what you've done here is mix together criticism of the original proposal and criticism of a browser extension+Dom0 tool proposal. >wouldn't have negative UX side-effects The UX side effects of appending (not prepending) the characters is minimal. First off, when window titles are truncated it's always at the end. Second, we don't need fifty characters in a row here. I suspect that you would probably not need more than three characters to provide reasonable performance and security[1]. Realize that attackers' ability to use brute force techniques would be quite limited in this situation. I'm not going to use the tool to reenter my password a dozen times in case of a login failure, let alone millions of times. >For the safety of yourself and others, please don't implement this using >window titles as proposed. I mostly suspect you're being well-intentioned here, but you have failed to admit when and where you were wrong (or at least where you misunderstood) and in addition to the hyperbole you are being very sloppy with your subsequent criticisms. *At best* you're being sloppy. At worst, you are being intentionally deceptive. But I do try to be an optimistic sort of misanthrope. I repeat, if you wish to argue that the modified project is not just un-ideal but is so insecure as to be worse that the status quo, you have your work cut out for you. Fortunately, and perhaps also fortunately for the readers of this fine mailing list, you have quite a bit of time at your disposal to come up with legitimate criticisms and/or a reasonable alternative before I can actually get around to implementing this myself. As I've said to Chris, I'm kind of busy right now and I'm not and have never been a computer professional, so it would probably take me much longer than should be necessary. I simply came here to see if there were any efforts in the works or if anyone had any better ideas. Apparently, the answer to both of these questions is 'no'. Shane 1. This is my off-the-cuff and off-the-top-of-my-head description of how I'd do it: on installation, the browser extension would generate a one-time random sal
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
cooloutac > I'd rather not have such a tool sitting there "enabled". lol First off, you've ignored where I said that this should obviously be an opt-in thing that isn't present, as the mechanism is pretty hacky and the tool shouldn't be used by the careless. But second, it transcends mere hyperbole or 'FUD' and rises to the level of magical thinking to pretend that this would be so dangerous as to present a risk even if not used. Absolutely nothing would happens if the user presses the "insert password" key combination if they haven't manually set up a password file on Dom0. An additional key combination to insert information into the Dom0 database from a VM would be a minor convenience that could be put off until the tool is overhauled (and probably moved out of Dom0 entirely.) -- 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/a2f6e9d7-a1fe-4a5d-b513-a508401fbf10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
On Thursday, March 30, 2017 at 5:27:12 PM UTC-4, Chris Laprise wrote: > I get the feeling when you talk about people contributing, you mean > /other/ people. That's fine, but in my estimation what you're proposing > would take under 30 lines of bash code. I think I've already covered this exact as comprehensively as can be done without writing you an actual autobiographical novel What the hell, I'll try again anyway. Yes, I could do it. Yes, it would in the end be a very small project (that's the entire point of suggesting it.) Yes, it would be interesting and useful. It would also be useful for me to figure out why Thunderbird is derping out again, learn Javascript, migrate all of my boxes to COW filesystems (which entails researching and choosing between ZFS, btrfs or bcachefs), and also do several thousand things that *aren't* computer-related, many of which either involve my son or attempting to make money doing non-IT things. To the extent that I am talking about this specific issue and not "ZOMG systemd sucks, why haven't you built Alpine Templates that can do 3d gaming, XFCE sucks why not use ObscureWM Deluxe, etc.", I was trying to be considerate and constructive. I even mentioned semi-seriously how this could (down the road) be part of a monetization scheme for Qubes, but despite all of that you still managed to play the lazy, self-absorbed noob card. Congratulations. If you can send me a package of free time, I would be more than happy to give it a shot right away. As it is now, if it really is that so amazingly simple as to hardly be worth mentioning and yet no one has done it, then I submit that I have already made a "contribution" and it is to point out that this thing *should be done*: *** Chris: "The schoolhouse is on fire!" Volunteer Fireman: "Have you ever hooked a firehose up to a hydrant before?" Chris: "No, uh, but I mean it's on fire *right now* and..." Volunteer Fireman: "Look, it's really quite simple. And this would be a great opportunity for you learn something. Nothing beats hands-on experience." *** Chris: "If you had enough time to write *all of that*..." Me: "Then perhaps you'd do me the courtesy of reading it instead of attempting to use it (with no trace of irony) as a evidence of my sloth?" Maybe if you (or someone) could write a Firefox extension to modify all browser page titles to be a concatenation of the page title and a short token of characters generated from a salted hash of the URL (so that I don't have to deal with any more hyperbole out of people like M. Ouelette), I could write the Dom0 bash bit. Or vice versa. Couldn't promise delivery on a tight deadline, though. -- 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/f8850253-8170-4bca-8fd4-b873d0a1aa60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>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
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>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
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
> This is actually worse than not using a password manager at all, > because the window you are about to enter the password into has full > control over its title, and so this opens a race condition where the > site could change its title right before dom0 checks it (perhaps > triggered by "I am displaying a login form, and I just lost focus") to > turn the dom0 pw mgr into a confused deputy [1] which would be happy > to deliver the password for site A to the malicious site B which is > temporarily spoofing site A's expected title. Counterarguments in order of decisiveness, starting with the least and going to most: 1. This is touching on a debate on real security vs. theoretical, and I happen to think these situations parallels the debate about cell phone cameras. Do you remember back when they first came out and quite a lot of people were constantly complaining about their picture quality (atrocious) and questioning why anyone would need a camera in a phone? Convenience. You can say "just bring a real camera" all you want but when you're talking about day to day life, 99% people will inevitably be caught with nothing but their camera phone on them. And without a usable Dom0 / Offline-VM password manager, 99% people will choose inferior passwords, have persistent logins and/or store their passwords on their online machine in some fashion. >From another angle: If theoretical security must trump real-world security or >convenience, then passwordless sudo needs to be removed, right? It's not even >all that "theoretical"; wasn't there a Xen jailbreak not that long ago? 2. I'm assuming the name of the VM being in the window titles prevents the password from ever going to the wrong VM. So if you are using multiple VMs of different trust levels, your bank password can't be targeted in this way unless it's by another highly trusted site. I'll take the chance that Gmail is pretending to be Amazon in order to steal my password. I mean, I sort of suspect they have stronger methods of identity theft at their disposal. 2a. Only sites you have an account with *and* are using this manager with could even attempt that attack. So mitigation vs. most realistic attacks is thus as simple as only using the password manager with important, "name-brand" websites and sticking with your browser's password storage for $ObscureUBB#7482. The target user here is a savvy power user who actually understands what's going on, not someone who needs training wheels. 3. How are on earth are they going to time that? How could an AppVM, a non-compromised AppVM[1], anticipate the Dom0 window poll? Like I said, this isn't a suggestion for a standard, robust, idiotproof scheme. It's also not telepath-proof. If not telepaths, How else are you going to know when to change the title? And before you answer, see #4. 4. I was actually already envisioning a few repeated polls over the course of a second or so for reliability, to guard against the user clicking around, but that would guard against this as well. All polls have to agree, otherwise the AppVM's clipboard is never filled. In the context of an attentive user, this should be a fatal blow to your described attack unless they can stack it with some other bugs. The deputy is being closely watched by the sheriff. >Not quite. The holy grail would be never having the VM see the passwords *ever*, and this is in theory actually achievable. Yes, you can split up the AppVM into multiple pieces but one of the pieces with internet access is going to need to see the password at some point. That's far, far ahead of what I'm talking about, though. I'm talking about a very simple project with lots of code reuse. If we're going to start talking about what Qubes should *ideally* do given lots of time or resources, I think some words like Alpine, unikernel and Genode should be thrown around. >This is better than using a password manager, I don't doubt it. I would never suggest a long term focus on window titles as a way of authenticating websites or communicating between Dom0 and DomUs. But I think it will be some years before they manage to get things properly separated and locked down like that. I hesitate to make claims about codebases I've never seen, but... this is a cookie cutter job, isn't it? Aren't the pieces all there? I wouldn't be surprised if someone could have something functional in less than a day's work. (Assuming that the person was sufficiently familiar with both the window manager and the hyperclipboard code bases.) Start by using the existing hyperclipboard code with a new hotkey combination, toss in an SQLite database or maybe just plain text, poll the window title for milliseconds[2] and if the polls all agree, send it to the clipboard. If they don't all agree, abort. I was merely thinking of this as a power user thing. Duct tape. I happen to think it's pretty strong duct tape, and that even a we
[qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
I know this isn't an ideal solution, but I suspect it would be pretty darn easy to implement: Obviously, the holy grail of password management should involve not storing passwords (encrypted or otherwise) on any online VM until they instant they are needed. I've been implementing this via copy/paste for my most important credentials, but it's a pain, and I'm far too lazy to do this with all of my logins. However, I justed noticed that R3.2 introduced a Dom0-to-hyperboard[1] copy function, and since Dom0 knows the window title text... couldn't there be another hypervisor keyboard shortcut that would use the window title to search though a simple database, copy a string associated with that window title and send it to that VM's clipboard? And because browser window titles are changed by websites, that means you could in most cases store one password per website. As always, it would be the user's responsibility to not input the password into a spoofed website. (This tool would thus be more of a convenience for power users, not the robust and idiotproof edition.) One could also use this to quickly retrieve passwords for applications like Pidgin (which still uses plaintext password storage if you ask it to remember passwords). You could use it with passwords for GUI terminals, too Someone might disagree with your passwordless sudo (I'm mostly fine with it), or they might use that terminal heavily with remote machine... perhaps with an employer who has arduous password requirements. I realize this is far from optimal[2], but it strikes me as a hefty security-convenience win that requires little effort to implement. Am I wrong on either of these counts? Shane 1. A much cooler name than "inter-VM clipboard" 2. For starters, website titles can change. And the passwords should ideally be kept in another VM, not Dom0. And there would preferably be a better mechanism for verifying websites or applications to prevent absent-minded copy/pastes into impostors (although, I would argue this tool wouldn't be likely to be used by particularly careless people.) On that latter point, a further very hack-y trick would be you had a web browser extension that could hash the URL, check whether certificate is good and then insert a token into the window title text ... ok ok, this is getting a bit crazy. -- 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/91e93e9a-996b-4667-91b3-55ce97849ac8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.