[whatwg] <input type="password">... restrict reading value from JS?
ayg at aryeh.name
Mon Aug 1 08:25:12 PDT 2011
On Fri, Jul 29, 2011 at 9:53 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> So there are two use cases for reading user passwords:
> * client side password strength indicators
> ** telling users if their passwords conform to site specific password
> - arguably bad practice
> - IMO better achieved with declared regular expressions
If you're doing useful password strength checks, regular expressions
won't cut it. For instance, you'll want to check against
dictionaries. Regex is only useful for crude and ineffective checks
like "must be at least six characters long with mixed-case letters,
numbers, and punctuation" (= "Abcd0!" is okay,
"effervescentarcheopteryxattack" is not).
> I don't think anyone but the receiving server should be able to read
> my password.
cornerstone of the web security model. The server is what sent you
no way you're going to paper this over by trying to remove one or two
we do this as an XSS defense-in-depth measure, like HttpOnly cookies,
but only for very narrow things where it makes sense.)
> This is one of the reasons some people disable
> doing other more useful things. If we disable just stuff like this we
> (such as me).
can't work around that without crippling it.
> Are XHR submits of passwords common and important enough to outweigh
> the security cost of scripts having access to all passwords in their
Yes. We can't stop them without breaking the web.
> I propose disallowing changing the action attribute of forms with
> password inputs.
We can't do that without breaking the web. There are going to be
which includes setting their action attribute and includes forms with
More information about the whatwg