[whatwg] <input type="password">... restrict reading value from JS?

Aryeh Gregor 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
> restrictions
>  - 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.

JavaScript acts as the agent of the receiving server.  This is a
cornerstone of the web security model.  The server is what sent you
the JavaScript, so it's trusted to act on behalf of the site.  There's
no way you're going to paper this over by trying to remove one or two
minor privileges from JavaScript.  (Yes, there are a few cases where
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
> JavaScript. Most don't, as they don't want to stop JavaScripts from
> doing other more useful things. If we disable just stuff like this we
> can bring some security to the folks that have JavaScript enabled
> (such as me).

No you can't.  JavaScript can replace arbitrary page content.  You
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
> document(s)?

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
countless sites that rely on being able to create forms in JavaScript,
which includes setting their action attribute and includes forms with
password inputs.


More information about the whatwg mailing list