Re: Risks the password role does create

Sure, which is to say that currently the ability to exploit a password
input (whether native or custom) is trivial today, and I think a very scary
thought. While I struggle with us adding an ARIA role that partially
facilitates the ability to extend a false sense of security to additional
inputs, it's true that the role value itself isn't the real culprit, it's
HTML password inputs in general that are scary.

In a perfect world, when browsers address this crater of a hole
(type="password") through tightened security restrictions, it would be
awesome that the role of password would also get the same treatment.
Ideally, an author could use *that* role value to actually impart the
behaviour natively in the browser (rather than depending on custom
scripting to do the obfuscation part), so that role="password" is the
'one-stop-solution' that both delivered the on-screen functionality, drove
the AAPI, and locked-down the input-string all in one.

We can dream, can't we?

JF

On Wed, Jun 22, 2016 at 3:56 PM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Wednesday, June 22, 2016 4:00 PM
>
> I think that you may have an idea there, although after spending a bit
> more time with this, I'm now freaked to report how truly insecure
> type=password is as well.
>
>
>
> 3 minutes on Google, and a few minor edits to an existing example I found
> illustrates how woefully insecure that input type actually is: a single
> line of javascript can extract the obfuscated characters from *any* input
> and echo them back into a second form input as clear text. Make that input
> hidden using aria-hidden=true, and I can watch Jason enter all of his
> passwords without him even being aware that I can see the values on screen.
>
> *[Jason] You could even extend the exploit to generate a QR code in SVG
> that your mobile device could capture by taking an image of the screen (and
> leave out the SVG title and desc elements). None of this requires the
> compromised password data to be transmitted over the network, although of
> course for most practical purposes, attackers are likely to use the network
> to log the information imperceptibly to the victim.*
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion