Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[7690]

On Sunday, April 9, 2017 at 2:55:01 PM UTC-4, cooloutac wrote:
> 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. 

-- 
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/d9663d11-aea1-461b-98cc-c6d4199ad8ea%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?

[cooloutac]

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 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/80fb44b6-c024-4a74-a1ec-a94eb7243329%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?

[Shane Optima]

>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 

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[cooloutac]

On Saturday, April 8, 2017 at 6:19:07 PM UTC-4, Shane Optima wrote:
> > 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.

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.

-- 
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/49609146-e5d0-4d01-8729-a31e24f082ce%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?

[Shane Optima]

> 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?

[cooloutac]

On Saturday, April 8, 2017 at 4:32:05 PM UTC-4, Shane Optima wrote:
> >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.

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?

-- 
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/4b009d07-f8fc-403a-9a98-d26238c75a3e%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?

[Shane Optima]

>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?

[cooloutac]

On Friday, April 7, 2017 at 6:37:21 PM UTC-4, Shane Optima wrote:
> 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.)

I wouldn't want a vm inserting anything in dom0.  But you are free to do what 
you want.  I personally find you suspect.

-- 
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/6577b209-6d6f-46c2-bb98-b2aedf96c761%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?

[Shane Optima]

>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 

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Shane Optima]

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?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 6:21 PM, Shane Optima  wrote:
> 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.

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, 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.

-- 
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/CABQWM_An4gJZ%2BbY4i5j7j07iz9AVkp27JcCpxxjHGMDmD_kjcQ%40mail.gmail.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?

[Shane Optima]

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?

[Chris Laprise]

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.


You should write it yourself as a way to learn about Linux and Qubes.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/3b1563c3-e9e9-6f46-029d-6d9ab3ac80d2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Shane Optima]

>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?

[Chris Laprise]

On 03/30/2017 10:34 AM, Jean-Philippe Ouellet wrote:

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  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.


Agreed.



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.


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.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/8ef6bde4-8675-89e7-53d2-c3813a190625%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  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.

-- 
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/CABQWM_DTC24h6XfbjW0xw%2B4q7MfpnKN8CmLRE660ahemBMOQBw%40mail.gmail.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?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:
> 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 '"'`

The issue I raise is not pasting into the wrong VM, I think that's
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.

-- 
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/CABQWM_BpjhE8YkEXe-rHnCuU3aXHKKkMCtzP1FqShyBLUKCZKA%40mail.gmail.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?

[cooloutac]

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[cooloutac]

Didn't bother reading the anarchical walls of text haha.  but Ya I agree with 
Jean that sounds like you would be exposing dom0 to stuff for really no 
reason...

-- 
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/eb595d36-d1eb-4b18-83cc-52c9317f0d28%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?

[Shane Optima]

>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 

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

- If we consider a compromised VM with:
  - 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)

-- 
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/CABQWM_DFw3_%2BD5XViMkie7mn4x60WgQ7yvYVPhhXdzpxoBoMhQ%40mail.gmail.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?

[Shane Optima]

> 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 

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Fri, Mar 24, 2017 at 2:55 AM, Shane Optima  wrote:
> 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.)

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.

[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.

Not quite. The holy grail would be never having the VM see the
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

-- 
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/CABQWM_Ak6WeJVtqw33CRsp%3DoYmDhDLmP5fTD32pFA%3D3BpekucQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Shane Optima]

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.