On Fri, Mar 24, 2017 at 2:55 AM, Shane Optima <optima.sh...@gmail.com> 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.
