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

Alex Vincent ajvincent at gmail.com
Sun Jul 10 01:08:46 PDT 2011

This is just an idea.

For the last 10+ years, password inputs have been accessible from scripts,
with nary a complaint.  If I have this code:

  <form action="javascript:void">
      <input type="password" id="pw">
      <button onclick="alert(document.getElementById('pw').value)">Show

I can extract the password by clicking on the button.  More to the point,
with a XHR I can send that password somewhere it shouldn't go... (well, with
cross-domain security code, maybe not, but that's not the point.)

To be honest, I can think of only two good reasons for checking a password
field's value.  The first is to compare against another password field.  The
second is to check the strength of the password.  In both cases, JavaScript
doesn't necessarily need the actual value - if the API provides other ways
to do that.

Specifically, I would suggest two methods for this input type:

 * Check if a password field's value matches another.
 * @param otherPassword Another password element.
 * @throws Error if this.type != "password"
 * @throws Error if other.type != "password"
 * @returns Boolean True if the fields match.
boolean passwordEquals(in HTMLInputElement otherPassword);

 * Check the strength of the password.
 * @param type The type of check to execute.
 * @returns 0 if dangerously low security
 * @returns 1 if "soon-to-be-deprecated" low security
 * @returns 2 if adequate security
 * @returns 3 if good security
 * @returns 4 if strong security
 * @returns 5 if entropy-death-of-the-universe security :-)
unsigned octet passwordStrength(in DOMString type);

The first idea has been suggested before:

I don't know if the second idea has been suggested before.
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

More information about the whatwg mailing list