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

[Dennis Joachimsthaler]

Hello Alex,

may I ask: Why? This would only cover a few cases of cross-site-scripting
attacks. It would not make a website more secure.

As to the suggestion, I have one little concern: It should not be possible
to WRITE those SecurePassword values. You only wrote "reading"...

Also it would cripple communications. If you can't read the password, all
Ajax is useless. You would have to submit the password by a http POST.

About the password strength: W3C would have to make a "worldwide standard"
on which passwords are secure and which not. This is not the philosophy
however, leaving just guidelines and not how the actual implementation
should go.

But I also have good sides about this: Online banking would be more secure,
with all javascript failing on it now. A browser could also store the
password in a secure manner and not even keep the original one, like
SHA'ing it a 10.000 times. The server would have the original password
or the same hash or some really mathematically generated hash that can
somehow compare to the hash sent by the user while being different AND not
storing the original password (is this even possible?). But this would also
cut into browser makers how they do their implementation, and thats not  
really
the philosophy here.

I still only see very few things like online banking that doesn't use
Ajax anyway profiting from this.

Am 10.07.2011, 10:08 Uhr, schrieb Alex Vincent <ajvincent at gmail.com>:

> 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.)
>
> 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:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html
>
> I don't know if the second idea has been suggested before.