Simple Dom0 password manager for an imperfect-but-strong security upgrade?
Shane Optima
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.
Jean-Philippe Ouellet
> 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.)
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.
[1]: https://en.wikipedia.org/wiki/Confused_deputy_problem
> 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.
passwords *ever*, and this is in theory actually achievable.
You could do your browsing in VM A, which has a browser extension
which securely determines the origin of the login form currently being
displayed, forwards a very simple "i am trying to login to site A" to
a different VM B. VM B has the list of credentials, and if we have one
for the site in question, performs a login. Then, only the session
cookies are forwarded back to vm A and injected back into A's browser
via the browser extension.
In this manner, a VM can obtain a valid login session for a given
site, without the ability to ever determine that password for that
site. This is better than using a password manager, because with a
password manager the vm still sees the password, and a compromised VM
need only wait until you login and then observe your password.
Of course, a compromised VM could also send your login session
cookies, etc. to an attacker who would then have a valid way to have
access to your account, but many sites require that you re-enter your
password before changing it so at least the attacker could not steal
the account by changing its password. Additionally, when you are done
using the site, the login-token-generating VM could automate a logout
of the site, invalidating the session tokens held by the requesting
VM.
The problem with your method (confused deputy password manager) is
avoided by having a browser extension validate the origin of the site
actually being displayed and ensure the login session token is only
injected into the correct corresponding site's context, rather than
relying on entirely attacker-controlled information for authorization.
See also: https://github.com/rustybird/qubes-split-browser
Shane Optima
> 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 xxxx 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 well-placed adversary would be find it difficult to pull off an attack against a user who was paying attention to what she or he was doing, but I want to underline that I would never consider this solution to be anywhere near ideal and I'd be aghast if anyone suggested standardizing on window titles as a permanent, long term solution.
Shane
1. If it's been compromised, then they can just intercept your credentials directly.
Jean-Philippe Ouellet
- passwords saved in the browser: an attacker can obtain all passwords
- your proposed password manager: an attacker can still obtain all
passwords, just needs to wait for them to be used
- If we consider a non-compromised VM with:
- passwords saved in a browser: an attacker can not obtain passwords
- your proposed password manager: an attacker can obtain passwords
by changing window titles during authentication (which may or may not
be *detected* by a sharply observant user, but could still not be
*prevented* by one)
Therefore, your proposed solution is actually appears worse from a
security perspective (aiming to guarantee password confidentiality)
than just saving passwords in your browser!
Your argument appears to reduce to "This may be theoretically
exploitable, but the ease of implementation and additional convenience
is more important to me", which assumes your adversary is not
sufficiently {resourced, motivated, creative} to exploit that
theoretical weakness against you. For many users this assumption and
associated trade-off may be fine... however they are quite strongly
rejected in the arguments motivating the design of Qubes.
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, and designs
around that fact. Meaning, assuming the security assumptions of Qubes
[1] hold, passwordless sudo is *not* a theoretical weakness [2].
[1] which have nothing to do with assuming weak/unmotivated adversaries
[2] unless Xen vulns affecting Qubes are somehow more exploitable from
kernel vs. userspace within a VM *and* the adversary does not also
have a linux privesc exploit (which history has shown to be quite
unlikely)
Shane Optima
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.
cooloutac
Chris Laprise
The _QUBES_VMNAME window property will tell you. For example:
$ CUR_WINDOW=`xdotool getwindowfocus`
$ VMNAME=`xprop _QUBES_VMNAME -id $CUR_WINDOW | cut -d \= -f2 | tr -d '"'`
xdotool also lets you inject keystrokes into windows.
With a shortcut-key assignment this can be easily scripted by the user
(you said this was for power users).
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
cooloutac
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.
Jean-Philippe Ouellet
> You don't even need to rely on the window title for the security aspect: The
> _QUBES_VMNAME window property will tell you. For example:
>
> $ CUR_WINDOW=`xdotool getwindowfocus`
> $ VMNAME=`xprop _QUBES_VMNAME -id $CUR_WINDOW | cut -d \= -f2 | tr -d '"'`
easy enough to avoid already.
The concern is pasting the wrong password into an expected site in the
expected VM because that site spoofed its window title (which is under
full javascript control) while dom0 observed it to choose which
password to deliver.
Jean-Philippe Ouellet
>
> With a shortcut-key assignment this can be easily scripted by the user (you
> said this was for power users).
window title and don't paste if it changed" mitigation which Shane
claimed as sufficient to make this attack preventable rather than just
detectable.
Overall I think this concept is simply too dangerous because you are
ignoring the actual origin of the browser and authenticating based
entirely on fully attacker-controlled information. Sure, you could be
super careful, but you're still pointing the gun at your foot.
Chris Laprise
> On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise <tas...@openmailbox.org> wrote:
>> xdotool also lets you inject keystrokes into windows.
>>
>> With a shortcut-key assignment this can be easily scripted by the user (you
>> said this was for power users).
>
> Automatically injecting the keystrokes removes the "just watch the
> window title and don't paste if it changed" mitigation which Shane
> claimed as sufficient to make this attack preventable rather than just
> detectable.
>
> Overall I think this concept is simply too dangerous because you are
> ignoring the actual origin of the browser and authenticating based
> entirely on fully attacker-controlled information. Sure, you could be
> super careful, but you're still pointing the gun at your foot.
oneself if the threat model seems appropriate. I wouldn't suggest this
as a Qubes feature.
Shane Optima
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.
Chris Laprise
/other/ people. That's fine, but in my estimation what you're proposing
would take under 30 lines of bash code.
You should write it yourself as a way to learn about Linux and Qubes.
Shane Optima
> 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.
Jean-Philippe Ouellet
> 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.
window titles since you could communicate over another channel which
is not under full attacker control by default, and wouldn't have
negative UX side-effects of abusing window titles as a communication
mechanism.
Furthermore, it's not hyperbole. Here's a super simple (but likely
quite effective!) exploit which took me a about two minutes to write:
(function() {
var attack_target = 'Sign in to GitHub ยท GitHub';
var saved_title = '';
var pw = document.querySelector('#password');
pw.addEventListener('focus', function() {
saved_title = document.title;
if (Math.random() < 0.2)
document.title = attack_target;
});
pw.addEventListener('blur', function() {
document.title = saved_title;
});
})();
What you are proposing is simply too dangerous and easy to exploit.
For most threat models, passwords would honestly be safer if saved in
the browser. For the safety of yourself and others, please don't
implement this using window titles as proposed.
Don't get me wrong, your fundamental concept is a good idea, but only
if the password manager authenticates the requesting site in a secure
way. Window titles are absolutely not the way to do that, not even for
an initial version.
cooloutac
I'd rather not have such a tool sitting there "enabled". lol
Shane Optima
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.)
Shane Optima
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 salt. I intend the user to manually copy over this salt and name of the VM in question to the Dom0 database, along with a list of URLs and associated passwords for that VM. Both the extension and the Dom0 tool would hash the URLs with the salt and use the resulting hash to generate three ASCII characters.
I say "ASCII" but I have no idea if it should be unicode or something else... you see, this is one of those potential speed bump details that might slow down a non-professional like myself. I'd need to know how window titles are treated and if there are any forbidden characters and I would need to be able to properly hash it and then properly transform the hash into three characters. If there isn't a library to do this transformation, I would have to wing it, but in testing this function I would generate lots of output to verify that all ASCII characters were appearing with the same frequency. Might be as simple as doing "[integer representation of the hash] mod [number of different characters in the valid charset]" and then simply transforming the resulting remainder into a character.
The Dom0 code is activated when the appropriate keycombo is given. It first examines the VM name. (It can do this through mechanisms other than looking at the window title, but I wouldn't bother doing this in the first prototype.) The VM name tells it which file / table it should be looking at. If it doesn't have a file associated with that VM, it logs a timestamped error and optionally could give an error popup. (DispVM can be handled like any other VM.)
Next, it examines the window title to see if it appears to be a browser window. If so, it strips the browser name out of the window title string and then looks at the last three characters, which were generated and appended to the window title by the extension. It tries to match this in its database. If it can't find those characters, it generates a different error / popup.
If it finds those three characters, it either copies the password to the VM's clipboard or uses xdotool to directly enter it. Like I said I don't know much about the character encoding rules here, but if three characters is too short to reasonably dodge collisions, just increase to four or five. This really isn't a big deal. It's straightforward arithmetic, and for good measure the Dom0 tool could look for duplicates during startup.
I wouldn't mind supporting programs other than browsers (like Pidgin), so there would be a separate table/file of window titles and associated passwords. If the window title doesn't appear to be a browser, the Dom0 program tries to match the entire window title instead of looking at only the last three characters. If the verbatim window title isn't found, a different error is logged.
As additional security measures, you can make the browser extension a bit more intelligent: if an HTTPS connection or self-signed cert (or expired or whatever) is detected, it could warn Dom0 through its 3 character signal in lieu of hashing the URL. The Dom0 code then logs the incident and/or throws a popup saying the password was not provided because there's suspicious stuff afoot.
You could go a step further by having the browser extension keep a record of which websites have passwords stored with them (and not appending anything to the window title if doesn't see that you've indicated that you have an account with that site), although this puts an additional burden on the user and may be undesirable in the sense that an attacker who compromises the machine automatically has a list of sites you have an account with (which they wouldn't normally have, particularly if you're using a DispVM.)
Is this all a hacky mess? Yes! Of course! But it's much easier and much more secure than the status quo, and it's still a one-day job for someone who is in possession of all the requisite familiarity and experience.
And as a casual UNIX fan (and as someone who once implemented first class functions in VBA out of frustration one fine afternoon), I do know that just because something is a hacky mess doesn't make it inherently bad or useless. I also know that, in high enough concentrations, perfectionism is toxic.
cooloutac
I wouldn't want a vm inserting anything in dom0. But you are free to do what you want. I personally find you suspect.
Shane Optima
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.
cooloutac
Don't be scared.
" 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.)"
How many times do you see "insert" and the word dom0?
Shane Optima
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.
cooloutac
its already out of dom0, just use the vault vm. If my Mother can handle ctrl shift c, I'm sure you can too. This is like the most important part of Qubes you are talking about it. I think it works fine, usability is not a good reason to add or change anything. You lost me way earlier when you mentioned browser extensions. Yes i'm a noob, but you still sound like a security nightmare to me.
Shane Optima
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 time, could possibly think that copy/paste is sufficient.
It's not even secure! Do it fast enough over a long enough period of time and you'll eventually slip up and paste the password somewhere it shouldn't be.
That's the real irony here. Ergonomics count. You're supporting an approach that is, in the real world, less secure.
Shane
1. Well neither do I at the moment; we really need multiple customizable DispVMs.
cooloutac
listen you don't have to be a computer genius to have common sense. If I touch fire my hand gonna burn I don't need anything scientifically explained to me to understand it first.
Maybe you are a computer programmer or developer that likes to follow logic. sure I get it. But the digital world of computers is highly connected to the physical world. They are extensions of each other and the same laws of nature apply to both. Same goes for people. Those that exist in digital world and physical are the same thing, have the same traits.
I freak out when I paste a password and it doesn't go anywhere. lmao. So I understand that fear. It is less likely to happen in Qubes but of course still possible. But I just change my password every 1-3 months. I have keepassx remind me and generate one with it.
What I meant about Browser extensions is that they are like the worst thing to use at the moment man. I use lastpass out on the windows machine and assume every password in there is compromised. I only have to hear the word browser extension and cringe and stop reading. Do you pay attention to current events? Apparently in firefox its even doubly worse.
The whole reason someone like me would use Qubes is because I'm so paranoid I assume I'm already hacked or going to be in the near future. If they wanna watch me look at teen porn or play video games thats fine, I use windows for that. Thats not important stuff...lol And it doesn't matter cause you're only an endpoint.
But I do everything else on a Qubes only machine, that I custom built for Qubes. All I can do is try to be careful and wipe a vm at the sign of any anomaly. (usually sys-net and untrusted) Gone are the days of me even trying to figure why an anomaly occured anymore man...that shit is over and done with. its becoming impossible noone can keep up. Chances are something suspect happened and its best to wipe it.
Its the arrogant nerds who don't use Qubes because they think they are too smart for Qubes or too smart to be vulnerable. /sarcasm. Or because of the myth that its harder to use then basic linux, probably spread by the same haters. Alot are here just to try and hack it or make it vulnerable. Which is the category I put you in. If I'm wrong I apologize.
I think its great though, my family uses it, requires less tech support then windows. ctrl shift v was no issue. But printing is still tricky for most.
cooloutac
Maybe you should post in user devel the people there are not as noob as me.
7690
> I gotta say the dvm template always gets messed up too. So i also only consider it untrusted tasks now. but the vault vm is great imo.
>
> Maybe you should post in user devel the people there are not as noob as me.
You type to much trash and you give nothing to the community.