- From: Tanvi Vyas <tanvi@mozilla.com>
- Date: Fri, 8 Apr 2016 13:37:37 -0700
- To: Gervase Markham <gerv@mozilla.org>, Richard Schwerdtfeger <richschwer@gmail.com>
- Cc: Virginie.Galindo@gemalto.com, public-web-security@w3.org, ARIA <public-aria@w3.org>, Mike Cooper <cooper@w3.org>
Websites may have a reason for using type="text" instead of type="password" on a password field. Perhaps they don't want Password Managers to save the user's password[1]. Or perhaps they are trying to avoid browser warnings about unencrypted HTTP pages requesting password information[2]. Or something else? If we create role="password", browsers and password managers will adapt to treating role="password" the same way as they treat type="password". Then the same websites that purposely avoid type="password" will start avoiding role="password". ~Tanvi [1] I am unclear on why some sites wouldn't want their users to have the benefits of a Password Manager. The only mildly plausible reason I've heard before is that such websites are worried they will not meet PCI compliance if passwords are stored in cleartext. This should be true when we are talking about passwords on the site's servers, but PCI compliance shouldn't be effected by users who choose to store their password on their own machines. [2] https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords, https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ On 4/8/16 9:37 AM, Gervase Markham wrote: > On 08/04/16 17:22, Richard Schwerdtfeger wrote: >> Companies do not use standard HTML markup when they feel it does not >> meet their needs. It really does not have anything to do with whether >> the markup is semantically correct. This is happening now and we >> don’t even have a password role. Companies that must do this for >> business reasons need a way to make it accessible. > They have a way to make it accessible - use a proper password field. So > what you are asking for is actually a second way to make it accessible. > What happens if some company then comes forward and says they can't use > your solution because for security reasons they aren't allowed to label > the field "password" in any way. What do you do then? Invent an alias > and call it "type='mrblobby'"? > > There is only a certain distance one should go to accommodate ridiculous > corporate requests. "We want to do passwords but don't want to use > password fields" is a user-hostile request (both for users requiring > accessibility technology and other users) and should be treated as such. > >> The bigger issue is that passwords as a technology have long outlived >> their usefulness. The growing world aging population has issues >> remembering passwords for all the sites they have to gain access to >> so they often use a simple, short, easy to remember password across >> all the sites creating a security issue. To this end even HTML’s >> password is a security risk as it is much easier to hack. This can >> result in identity theft and a whole litany of issues. Captchas are >> also a huge problem for aging users. > This may be so; but encouraging people to use non-password fields for > passwords and so avoiding all the software people are using to help them > manage the password problem (which does make things better) doesn't help. > > Gerv >
Received on Friday, 8 April 2016 20:38:09 UTC