role=password Re: Security Evaluation Request

On Tue, 05 Apr 2016 20:39:08 +0200, Richard Schwerdtfeger  
<richschwer@gmail.com> wrote:

> Virginie,
>
> I chair the ARIA Working group. We are considering a new ARIA role for  
> ARIA 1.1 called “password”. The definition of this role is here.
>
> https://rawgit.com/w3c/aria/password-role/aria/aria.html#password  
> <https://rawgit.com/w3c/aria/password-role/aria/aria.html#password>
>
> For those who are not familiar with ARIA, ARIA semantics are added to  
> web content so that User agents can then convey semantic information to  
> assistive technologies running on the native platform using  
> Accessibility APIs for the platform. Examples of assistive technologies  
> might be: a screen reader for the blind, an alternate input device for  
> the mobility impaired, or a screen magnifier for low vision users.
>
> The reason for the new role is that authors are creating custom password  
> input fields instead of the native HTML input type=“password”. By  
> applying a role=“password” to the input element we can convey to the  
> assistive technology that the author intended it to be a password field  
> vs an ordinary text field. Since these are custom password fields it is  
> up to the author and not the user agent to handle the obscuring of text.
>
> example: <input type=“text” role=“password”>

This example conveys the primary problem I see - it doesn't include  
anything that makes the input behave like a password.

Issues as I understand them:

1. Relying on web app authors to implement security seems like a terrible  
idea, just because there are so many more of them to get it wrong.

2. The primary audience for ARIA is screen reader users, and the primary  
audience for screen readers are people who are blind. If their screen  
reader tells them they are on a password field, they have no way to verify  
beyond noticing it behave differently from a real one. Which means they  
have to expose some of their password and notice different things happen.

In the example above, they may be told that there was a password field,  
and as they start to type the password it is likely that it would be  
echoed back at them. Depending on their settings, perhaps as a complete  
word - i.e. when they've put it all there.

They may not be told, since the backward compatibility story is that the  
input would seem to be a normal input. I think that is preferable, since  
at least users can tell they are not in a "real" password field.

3. There is currently no way for the role value to trigger common user  
agent behaviour with passwords, such as blocking copy or storing things in  
a password manager.

4. Expecting the user to listen to characters when they start typing  
passwords, as a way to determine whether they are visually exposing their  
password, seems to be an anti-apttern from the point of view of user  
experience, and inherently fragile from the perspective of protecting  
security.

A counter argument is that it is not clear what is a password input  
anyway. There is a convention that characters entered are masked with "*"  
but this is easy enough to mock up with a standard text input. So how much  
are we increasing the attack surface?

cheers

Chaals

> The browser would convey to the assistive technology that this is a  
> password field vs. an ordinary text field. In this scenario the user  
> should pay attention to the text rendered.
>
> Does your group believe this adds security risks? If so, what are those  
> risks?
>
> Thank you,
>
> Rich Schwerdtfeger
> ARIA Working Group Chair


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 6 April 2016 04:02:50 UTC