[whatwg] Passwords
Was "Re: [whatwg] Proposal: Write-only submittable form-associated controls." On 2014-10-16 01:31, Eduardo' Vela" wrote: If we have a password manager and are gonna ask authors to modify their site, we should just use it to transfer real credentials, not passwords.. Passwords need to die anyway. And use what instead? At some point a password or passphrase (aka sentence) is needed. Password managers need a password to lock their vault as well. Password/phrases are "free", all other methods requires something with a cost. Biometrics requires scanners, and good ones (that can't be fooled by by breathing on a printed out fingerprint) are expensive. There are USB sticks, and Smart cards (which require a card reader) Audio require a microphone (and can be heard by others) "my voice is my passport verify me". You could use a app but this means you need a smart phone (which I don't have and probably do not plan to get any time soon, no need for one). There is SMS but a phpBB based forum site isn't going to shell out cash for SMS based login or similar. Biometrics have other issues, the voice may change (your voice changes throughout the day), your fingerprints change based on moisture, and you can damage them, there are diseases and medicines that can affect them. The retina may change as you get older, even your DNA may get damaged over time. Also credentials (certificates) are not free if you want your name in them. (you can get free email/identity ones from StartSSL.com and a few other places but they are tied to your email only). Installing certificates are not always easy either, and then there is the yearly or so renewals, and you can throw away old certs or you will b unable to decode encrypted emails you got archived. A regular user will feel that all this is too much noise to deal with. They could use something like Windows Live as a single sign on and tie that to the Windows OS account, but only sites that support signon with Live can take advantage of that. And a password (or a portable certificate store, or biometric of sorts) is still needed for the Windows OS on that machine anyway. I mentioned StartSSL above, the cool thing they do is they hand out domain only verified certificates, so any website can have "free" https, why the heck this isn't a "thing" more than it is I don't understand, each time I see a login to a site or forum that is http only I always ponder why the heck they aren't using HTTPS to secure their login. But I digress. Single word passwords need to go away, if a attacker finds out/guesses it in for one site, changes are the same pass is used on multiple sites as is or with minor variations. Passphrases is the solution to some of this problem as it will make dictionary attacks much more expensive. There are still sites that enforce a 8 character password which is insane, people should be allowed to enter any password they are able to enter on their keyboard, be it one character or long sentences, with or without numbers or odd characters, the more restrictions there are on the password input the easier it is to guess/crack. The only restrictions that does no harm would be to ask for passphrases instead. Also http logins with plaintext transmission of passwords/passphrases need to go away, and is a pet peeve of mine, I detest Basic HTTP-Authentication which is plaintext. Hashing the password (or passphrase) in the client is the right way to go, but currently javascript is needed to make that possible. If a password field could have a hash attribute that would be progress in the right direction. or something similar perhaps a comma to separate method and number of rounds, alternatively just and use a browser default instead (in this case the server side need to support multiple methods of hashing and the hashed password need a prefix to indicate method, salt and rounds if any. There is some new crypt stuff, but again that needs javascript to be utilized, having a password be hashable by the browser without the need for any scripts to do so would be the best of both worlds in my opinion. For example if a hostile script had access to the form and hte password field, the password would have been hashed before it was put in the password field anyway, sure they might be able to snoop the hash but the hash could be using a unique salt (or should rather) and would be useless to re-use. -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On 2014-10-15 18:10, Tab Atkins Jr. wrote:
On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola
wrote:
For the XSS attacker, couldn't they just use
`theInput.removeAttribute("writeonly"); alert(theInput.value);`?
Or is this some kind of new "un-removable attribute"?
Doesn't matter if it is or not - the attacker can still always just
remove the and put a fresh one in.
Nothing in-band will work, because the attacker can replace arbitrary
amounts of the page if they're loaded as an in-page script. It's
gotta be *temporally* isolated - either something out-of-band like a
response header, or something that has no effect by the time scripts
run, like a that is only read during initial parsing.
~TJ
There is also legitimate needs for being able to edit the password field
from a script.
I have a custom login system (that is currently in public use) that
takes the password, does a HMAC on it (plus a salt and some time limited
info).
This allows login in without having to send the password in the clear.
It's not as secure as https but it's better than plaintext.
A writeonly password field would have to be optional only or my code
would break.
And I'm not the only one. SpiderOak.com also uses this method (they use
bcrypt on the password to ensure that SpiderOak has Zero-Knowledge).
Any limitations on form manipulations should be based on same origin
limitations instead, such that only a javascript with the same origin as
the html with the form can read/write/manipulate the form.
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Yea the keyup/down/press restrictions are definitely not useful, at least for password protection since the user has clearly no way to know if the field is safe or not. The tainting is never gonna work reliably and consistently as Michal hinted (say, a blob: URL would run in the same origin but not be bound to CSP which could be used to exfiltrate the data). The dependency on CSP also makes this a bit aspirational. I can agree that the login form could be CSP protected but the whole origin is not as likely. Specially for connect- and form-. And even that might be insufficient (its a common practice to echo back typed passwords when the user doesnt answer a captcha or has it wrong, for example - a same-origin XHR will leak the password). There are other solutions that seem more likely to work to solve the problem of password managers (something like a synced channelId, for example, or even FIDO style solutions). This proposal seems to try to achieve a mixture of just replacing canary values at the network layer based on destination with an httpOnly-style model for user-supplied data. If we have a password manager and are gonna ask authors to modify their site, we should just use it to transfer real credentials, not passwords.. Passwords need to die anyway.
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 6:10 PM, Tab Atkins Jr. wrote: > > Nothing in-band will work, because the attacker can replace arbitrary > amounts of the page if they're loaded as an in-page script. It's > gotta be *temporally* isolated - either something out-of-band like a > response header, or something that has no effect by the time scripts > run, like a that is only read during initial parsing. > Yes. Hence the CSP directive portion of the proposal. The inline attribute is useful for the specific password manager case I'm concentrating on, as it gives us a clear indication that the site doesn't intend to do wacky manipulation of its credentials on the fly. We can use this to determine how and when the password manager (or credit card autofill, or whatever) ought to refuse to expose information to the renderer. -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 5:59 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> For the XSS attacker, couldn't they just use
> `theInput.removeAttribute("writeonly"); alert(theInput.value);`?
>
> Or is this some kind of new "un-removable attribute"?
>
The strawman suggests setting a flag on the element, and doesn't suggest a
way of unsetting that flag. This is conceptually similar to iframe@sandbox's
effect on the document loaded into the frame.
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
So I might have started this on the wrong foot, but let's consider the broader threat model. What do we want to protect against? 1) XSS stealing the passwords / CC numbers entered by the user manually? This is probably not possible with this proposal; the evil payload may construct a form where the writeonly attribute is not set. 2) XSS stealing the passwords entered by the password manager? To do this, I feel that we need a taint-tracking system coupled with a password manager that remembers that some passwords can go only into writeonly fields, and which URLs and methods they need to be submitted to. The CSP solution + blocking GET feels like a crutch that won't work in practice; my main concern is that writing site-wide policies is hard as-is, and that the likelihood of well-scoped per-page policies, especially with path granularity, is low. But if we go the CSP route, breaking writeonly fields if form targets are not policed may be the best we can do. (Also note that my attack #3 will work simply if XSRF tokens are user- but not action-bound, which is a common pattern.) I also expect many other corner cases to crop up when others look at the implementations later on. 3) Regular compromised renderers / malware stealing the data manually entered or automatically populated by the browser? Not doable. 4) Future Chrome origin-bound sandboxed renderers stealing the data manually entered by the user? Probably not doable, by analogy with #1. 5) Future Chrome origin-bound sandboxed renderers stealing the data auto-populated by the password manager? Feels like for this, we need taint tracking; otherwise, the renderer can ask for the password under false pretenses, perhaps after loading a sub-page with different or no CSP rules. We could try giving the renderer a token that is converted to a password on an ongoing request by the network stack, but there is no way to confirm that the request is being made to the right destination and in good faith. ... The reason why I was previously skeptical of proposals of write-only fields is pretty much because the threat model is so complicated and the solutions are so fragile - but maybe I'm in the wrong on this. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
- Would one be able to validate the password field (eg, to detect an empty password)? Is HTML5 validation allowed on a writeonly field. - Could a cross-domain XHR be made? Could FormData from such a field be limited to the same domain. - Something that could be interesting is if the password field only exposed an encrypted or hashed value. For example, it'd be pretty awesome if a website could put a public key and say "when a user types in a password here, encrypt it with the public key before sending to the server". This could prevent an attacker from ever seeing the plain text password. Today you could do this with JS, but it would prevent one from using the writeonly attribute. On Wed, Oct 15, 2014 at 4:15 PM, Mike West wrote: > # Problem > > A user’s credentials are valuable, and are often the key target of phishing > and content injection attacks. If a content injection attack can trick a > user's credential manager into autofilling her credentials, then the user’s > credentials will be available to the attacker directly via DOM APIs or > indirectly via form submission to a malicious endpoint. The latter risk can > be mitigated via the Content Security Policy `form-action` directive, but > the former is a real problem. If passwords are a simple value accessor > away, users are at risk. > > ## Proposal > > We could mitigate this latter risk by allowing sites to opt-in to denying > DOM access to an element's content. If JavaScript can't grab the value, > then script injection attacks have a much more difficult time exfiltrating > interesting data. This might be as simple as adding a writeonly attribute > to submittable elements: > > > > This would throw an `InvalidStateError` on `value*` accessors, bar the > element from constraint validation, block `keydown`, `keyup`, `keypress` > events, and probably other things I haven't considered yet. > > `FormData` objects created from forms including these writeonly elements > would be "opaque". You could use them to submit an XHR request, but you > couldn't read the values directly from script. > > This state could also be controlled via a Content Security Policy directive > which would set writeonly state for some arbitrary set of submittable > elements, perhaps based on autocomplete attribute values. Perhaps: > > Content-Security-Policy: form-writeonly cc-number cc-csc ... > current-password new-password > > ## Spec Suggestions > > I've strawmanned out the monkey-patching this would require of XHR, Fetch, > and HTML in a bit of detail at > https://mikewest.github.io/credentialmanagement/writeonly/, and there was > a > short-lived public-webapps thread at > http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html > (and > a shorter-lived discussion at > http://specifiction.org/t/write-only-input-fields/598). > > ## Implementer Interest > > I'd like to implement pieces of this in Chrome to harden our password > manager; if we can use this state as a heuristic to mark particular > credentials as writeonly, we can keep them out of the renderer process > entirely, which would be a nice win for security. > > I've also talked about it tangentially with Anne and Jonas at Mozilla (the > former in relation to Fetch, the latter in relation to a proposed > Credential Management API). Neither jumped on it as the best thing ever, > but they were both more than marginally supportive. > > Thanks! > > -- > Mike West > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > Geschäftsführer: Graham Law, Christine Elizabeth Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) >
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola
wrote:
> For the XSS attacker, couldn't they just use
> `theInput.removeAttribute("writeonly"); alert(theInput.value);`?
>
> Or is this some kind of new "un-removable attribute"?
Doesn't matter if it is or not - the attacker can still always just
remove the and put a fresh one in.
Nothing in-band will work, because the attacker can replace arbitrary
amounts of the page if they're loaded as an in-page script. It's
gotta be *temporally* isolated - either something out-of-band like a
response header, or something that has no effect by the time scripts
run, like a that is only read during initial parsing.
~TJ
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
For the XSS attacker, couldn't they just use
`theInput.removeAttribute("writeonly"); alert(theInput.value);`?
Or is this some kind of new "un-removable attribute"?
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 4:27 PM, Mike West wrote: > 1. If you can spin up a service worker, the site is already very much in > trouble. > > 2. I have handwavey ideas about ensuring that the FormData object which > would be readable via the Request object in the service worker would retain > the opaque flag. The spec strawman hints at that, but I haven't done the > work to find all the places to monkey-patch. Hello: Just a quick question: how does this relate to the COWL proposal [1]? labeled contexts/communication seems to be - in general - a good idea to implement what you propose. Regards, -- [1] http://cowl.ws/ -- Eduardo Robles Elvira @edulix skype: edulix2 http://agoravoting.org @agoravoting +34 634 571 634
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski wrote: > > Fair enough - although I worry that the likelihood of people using > > this in conjunction with tightly-scoped per-document CSP (versus the > > far more likely scenario of just having a minimal XSS-preventing > > site-wide or app-wide policy that will definitely not mitigate #3 and > > probably do nothing for #1) are pretty slim. > > In fact, the XSS-preventing part is probably a stretch. Facebook and > Twitter are often mentioned as the two most significant customers for > CSP, but both use unsafe-inline and unsafe-eval. > True. Because both have huge legacy systems built on inlining JavaScript. That's an architectural change that is really truly difficult in aggregate. The same is not the case for login forms. Or credit-card forms, for that matter. The only sites that wouldn't be able to implement something like this without significant effort are those who do client-side encryption (well, "encryption") of the sensitive data before passing it on to the server. > On top of that, note that #3 is not defeated by origin-scoped rules - > you need to specify full paths. > You're correct. I mentioned that. :) #3 also relies on the site having a comment form, or some other mechanism of publicly reflecting POST data to the world without a CSRF. Lots of sites have that sort of mechanism, sure, but I don't think that even a majority of high-value sites do. Honestly, if we're creating a mechanism that implies that a degree of > protection is provided for password fields, we should either make it > work on its own Do you have suggestions for what "on its own" might look like? > , *or* at the very minimum require a CSP with > form-action specified, and otherwise warn or better yet, break fields > flagged as writeonly. > Sure. Doing one or both is probably pretty reasonable. :) -mike
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
> Fair enough - although I worry that the likelihood of people using > this in conjunction with tightly-scoped per-document CSP (versus the > far more likely scenario of just having a minimal XSS-preventing > site-wide or app-wide policy that will definitely not mitigate #3 and > probably do nothing for #1) are pretty slim. In fact, the XSS-preventing part is probably a stretch. Facebook and Twitter are often mentioned as the two most significant customers for CSP, but both use unsafe-inline and unsafe-eval. On top of that, note that #3 is not defeated by origin-scoped rules - you need to specify full paths. Honestly, if we're creating a mechanism that implies that a degree of protection is provided for password fields, we should either make it work on its own, *or* at the very minimum require a CSP with form-action specified, and otherwise warn or better yet, break fields flagged as writeonly. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
>> 1) Change the action value for the form to point to evil.com, where >> evil.com is in attacker's control, > > I hope that this is mitigated by the `form-action` CSP directive, which > allows the site to control the valid endpoints for form submission, and > `connect-src`, which allows the same for XHR, EventSource, WebSockets, etc. > >> 3) Change the action value of the form and the name of the password >> field so that the posted data is interpreted by the server as an >> attempt to, say, post a comment. > > Again, mitigated (but by no means avoided) by path restrictions on the > `form-action` CSP directive. Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. We're effectively adding a mechanism that works well only if you remember about a fairly counterintuitive gotcha, which realistically means that it won't be used correctly something like 90%+ of the time. Cheers, /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Good feedback, Michal. Thanks! On Wed, Oct 15, 2014 at 4:41 PM, Michal Zalewski wrote: > > > > I think that one huge problem with this is that the attacker will have > many other, indirect ways to get the value even if you protect direct > access to the field. Two most obvious options include: > Note that there are two types of attacker I care about: 1. XSS. You've outlined some (of the probably many) ways to bypass the kinds of protection I'd like to build here. Let's discuss below. 2. Renderer flaws. Currently, if someone can corrupt Chrome's renderer process, she can request any and all passwords from the password store by pretending to be various origins. If we can mark certain credentials as "writeonly", we know we never have to send them to the renderer, and that any such requests could be ignored. This is similar to what (I hope) we're doing with `httponly` cookies (though I haven't checked, it seems like an obvious optimization). > 1) Change the action value for the form to point to evil.com, where > evil.com is in attacker's control, > I hope that this is mitigated by the `form-action` CSP directive, which allows the site to control the valid endpoints for form submission, and `connect-src`, which allows the same for XHR, EventSource, WebSockets, etc. > 2) Change the action of the form to GET while keeping the same method, > let it submit, and then examine location.search. > Good idea. One way of avoid this would be to lock all forms with writeonly data and XHR with opaque FormData to the POST method. That's probably what we'd like folks to be doing anyway in order to keep potentially interesting information out of server logs and browser history. > 3) Change the action value of the form and the name of the password > field so that the posted data is interpreted by the server as an > attempt to, say, post a comment. > Again, mitigated (but by no means avoided) by path restrictions on the `form-action` CSP directive. > I worry that there's actually more, and that a lot of nasty "taint > tracking" heuristics would be required to make it go away. > That's something I'd like to avoid, insofar as possible. I think it's likely unavoidable to have some sort of opaque flag on request objects in order to do the right thing with regard to ServiceWorkers, but since we already track opaqueness for responses, I hope that's not an overly burdensome taint to track. -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
> I think that one huge problem with this is that the attacker will have many other, indirect ways to get the value even if you protect direct access to the field. Two most obvious options include: 1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, 2) Change the action of the form to GET while keeping the same method, let it submit, and then examine location.search. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. I worry that there's actually more, and that a lot of nasty "taint tracking" heuristics would be required to make it go away. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Yes. Two things about service workers: 1. If you can spin up a service worker, the site is already very much in trouble. 2. I have handwavey ideas about ensuring that the FormData object which would be readable via the Request object in the service worker would retain the opaque flag. The spec strawman hints at that, but I haven't done the work to find all the places to monkey-patch. -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Wed, Oct 15, 2014 at 4:25 PM, Boris Zbarsky wrote: > On 10/15/14, 10:15 AM, Mike West wrote: > >> `FormData` objects created from forms including these writeonly elements >> would be "opaque". You could use them to submit an XHR request, but you >> couldn't read the values directly from script. >> > > If you're at the point where you can run script on the page, can't you > spin up a service worker that would capture the data in that XHR? > > -Boris >
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On 10/15/14, 10:15 AM, Mike West wrote: `FormData` objects created from forms including these writeonly elements would be "opaque". You could use them to submit an XHR request, but you couldn't read the values directly from script. If you're at the point where you can run script on the page, can't you spin up a service worker that would capture the data in that XHR? -Boris
[whatwg] Proposal: Write-only submittable form-associated controls.
# Problem A user’s credentials are valuable, and are often the key target of phishing and content injection attacks. If a content injection attack can trick a user's credential manager into autofilling her credentials, then the user’s credentials will be available to the attacker directly via DOM APIs or indirectly via form submission to a malicious endpoint. The latter risk can be mitigated via the Content Security Policy `form-action` directive, but the former is a real problem. If passwords are a simple value accessor away, users are at risk. ## Proposal We could mitigate this latter risk by allowing sites to opt-in to denying DOM access to an element's content. If JavaScript can't grab the value, then script injection attacks have a much more difficult time exfiltrating interesting data. This might be as simple as adding a writeonly attribute to submittable elements: This would throw an `InvalidStateError` on `value*` accessors, bar the element from constraint validation, block `keydown`, `keyup`, `keypress` events, and probably other things I haven't considered yet. `FormData` objects created from forms including these writeonly elements would be "opaque". You could use them to submit an XHR request, but you couldn't read the values directly from script. This state could also be controlled via a Content Security Policy directive which would set writeonly state for some arbitrary set of submittable elements, perhaps based on autocomplete attribute values. Perhaps: Content-Security-Policy: form-writeonly cc-number cc-csc ... current-password new-password ## Spec Suggestions I've strawmanned out the monkey-patching this would require of XHR, Fetch, and HTML in a bit of detail at https://mikewest.github.io/credentialmanagement/writeonly/, and there was a short-lived public-webapps thread at http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html (and a shorter-lived discussion at http://specifiction.org/t/write-only-input-fields/598). ## Implementer Interest I'd like to implement pieces of this in Chrome to harden our password manager; if we can use this state as a heuristic to mark particular credentials as writeonly, we can keep them out of the renderer process entirely, which would be a nice win for security. I've also talked about it tangentially with Anne and Jonas at Mozilla (the former in relation to Fetch, the latter in relation to a proposed Credential Management API). Neither jumped on it as the best thing ever, but they were both more than marginally supportive. Thanks! -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
