On Fri, Aug 1, 2014 at 3:31 PM, Brian Smith <br...@briansmith.org> wrote:
> There is some tension here between making things password-specific and > simple vs. making them general and harder to understand. Defining this > as a mechanism to protect only passwords keeps it simple. But, it > seems wrong to have a way to protect passwords but not credit card > numbers and social security numbers and other very sensitive input > fields that don't use <input type=password>. I hadn't considered autofilled credit cards; that's a reasonable use case. We could address credit cards by turning the CSP directive into a list of autocomplete attribute values: `form-readonly cc-number cc-csc ... current-password new-password`. That seems like it would address the credential use case, while leaving flexibility for future field types that developers might care about giving extra protection. That said, it gets quite verbose. If we go this route, perhaps we could come up with a chunk of those types we'd expect developers to want to protect, and give them a special keyword expression: `form-readonly 'the-usual-stuff'`. > I am not sure that looking only at POSTs is sufficient. I don't think we should encourage GET-based submission of valuable information. > websites put login forms on every page (whether they should or not). If we filled a form on every page, but the user never logged in, there would indeed be a (marginal?) performance impact if we had to examine every POST a website made. That feels like an edgy enough case that we don't have to worry too much about it, but I don't have any numbers to back that up. > But, I agree that it would be better to avoid the need for the > attribute if we can. The less work we make the website do to get some security benefit, the better. > I suspect some websites will want to disable some aspects of their > form validation code if they are dealing with placeholders instead of > the real values, especially if the mechanism is extended to things > such as social security numbers and credit card numbers. If the field is write-only, they won't be able to do client-side validation. That's a necessary consequence of keeping the password out of the renderer, and out of reach of JavaScript. I agree that this is more problematic for SSN or CC fields than for passwords, but I don't see an alternative that would keep the renderer in the dark about the actual value. If they use the credential management API to get credentials, they'll only be getting credentials the user saved. Presumably the user wouldn't save credentials that weren't valid for the site. >> I'm pretty happy to break that use case, given that the credential API I've >> proposed is locked to secure origins. There's no advantage to using >> WebCrypto to doubly encrypt the password in this context, and I don't think >> it's something we should encourage. > > I think it is fine to say that this would be mutually-exclusive with > WebCrypto-based approaches to encrypting passwords in the short term. > However, I think it is too early in the history of WebCrypto to say > that there's advantage to encrypting passwords (or other sensitive > information like credit card numbers) in a way that protects them from > the from the web server. I think it is likely that some way of > composing WebCrypto and this mechanism will be necessary, eventually. I'm curious about the use cases for protecting the password from the webserver. I've had some conversations with Sigbjørn Vik about returning hashed passwords rather than "real" passwords, which might be going along the lines you're thinking. That is, the site would provide hash function and a server nonce when requesting credentials, and the UA would return a client nonce and a LocalCredential whose password value was `hash(password + server nonce + client nonce)`. I think that's worth exploring, but it's tough to do well without requiring the site to hold passwords in plaintext. Is that the kind of use case you're considering? -- Mike West <mk...@google.com> 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.)
