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

Sean Connelly sean at pbwhere.com
Mon Jul 11 06:29:23 PDT 2011


As a web developer, if I wanted access to the password, I would then avoid
using the <input type="password"> field, and create my own field that reads
characters (perhaps via onkeyup), and fakes a password field visually.

I also think it's a bad idea to change the behavior of <input
type="password"> because it will break websites that assumed they could read
the value.  Perhaps a website checks against a user's past 10 passwords to
see if they are using the same one, via XHR.  Or perhaps the entire login
process is XHR.  Who knows.

I think there is definite room for improvements in security when it comes to
<input type="password">, and I've also been trying to make it more secure by
designing some sort of client-side hashing.  But I don't think restricting
JavaScript from reading the value is a security benefit... in my opinion, it
would just be a hassle for developers who need to read the value, and force
them to use another means of password entry where they can read the value.

~Sean



On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> > 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">
> >    <div>
> >      <input type="password" id="pw">
> >      <button onclick="alert(document.getElementById('pw').value)">Show
> > password!</button>
> >    </div>
> >  </form>
> >
> > 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.)
>
> You can send it anyway by changing the action attribute on the form
> and calling submit().  So what attack scenario are you actually
> avoiding here?  You'd need a really strong security benefit for it to
> be possible to even contemplate breaking so many websites.
>



More information about the whatwg mailing list