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

[Bjartur Thorlacius]

On 7/11/11, Sean Connelly <sean at pbwhere.com> wrote:
> 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.
>
Fair point. I also worry about attackers removing a form and inserting
their own, or even positioning their own over the old one - if they
manage to gather enough information about the victim's UA or if the
form of a password input is consistently positioned.

> 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.
>
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
 ** generally informing users of the computing needed to brute force
their password open, and if it's in a dictionary
  -- fetching a dictionary from each site is impractical (and thus
only implementable by UAs)
  -- can be implemented by UAs without "braking" sites that work if
laid out in the same way as the author's UA with floating overlays
that appear only while the password input is focused and has input
 * XHR submit
  - Could forms be targeted to a new browsing context and the server
return a HTTP 204 response instead?
  - Are implementors willing to display a more prominent notice of the
status of the submit (e.g. the text "Submitting" under a spin-wheel,
and then the Reason-Phrase of the request colored or on a background
colored to convey the status code)?

> 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.
>
I don't think anyone but the receiving server should be able to read
my password. 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).

> 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:
>> > 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.)
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)?

>>
>> 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.
>>
I propose disallowing changing the action attribute of forms with
password inputs. That is, if we manage to squash all the other obvious
ways a script can compromise the security of a typed password. This
seems to involve a lot of tedious allowance of this and that to be
done to forms, except if you throw in a password input. I'm not to
judge if it's worth it.