RE: TAG - Password in clear text.

Mary Ellen,
 
The TAG discussed your feedback at length today and we really appreciate
your input but on a few of the items we're not exactly sure how to
proceed.
 
Can you propose the changed language you would like to see in the
finding that would address your comments below?
 
-Ed
 

________________________________

From: tag-request@w3.org [mailto:tag-request@w3.org] On Behalf Of Mary
Ellen Zurko
Sent: Tuesday, January 02, 2007 3:05 PM
To: Rice, Ed (ProCurve)
Cc: Vincent.Quint@inrialpes.fr; Noah Mendelsohn
Subject: Re: TAG - Password in clear text.



Ed, 

Here are my comments on reading the draft finding closely. 

"Security on the World Wide Web is an important issue which needs to be
addressed or mistrust of the Web will limit its growth potential."
It's not clear to me actual security and user trust are tightly coupled
in general, or in the case of the Web. User trust comes from perception.
The best work I've seen on that is from:
Andrew S. Patrick, Pamela Briggs, and Stephen Marsh, "Designing Systems
That People Will Trust", Security and Usability: Designing Secure
Systems that People Can Use, ed. Lorrie Faith Cranor and Simson
Garfinkel. 

"The TAG feels there are sufficient technologies available to take a
clear stance on password security as it relates to the World Wide Web."
The finding mentions the wire protocol, the browser history, and web
proxies; the places that transmission in the clear effects. There are a
bunch of other places passwords can leak, starting with server logs, and
going on to any (temporary) files written by either the browser or
server. My product experience is that users do not want their passwords
in the clear anywhere. Bugs that leave passwords in the clear
immediately heighten user mistrust of the system. I'm guessing that the
finding is restricting itself to the transmission because there's where
the sufficient technologies are to solve the problem. Sadly, we have not
found technologies to solve sloppy engineering, although running a
grep-equivalent over the system after testing to look for residue in the
form of a well known password used during testing can be simple and
effective. 

"As customers are becoming more 'net savvy' they are starting to examine
web page types "
I definately see that in techno types, even ones not particularly "into"
security, but my mom cannot hope to understand web security at this
level. She listens to what others tell her (including what I tell her).
I believe that to be the prevalent mode for most users. Mackay's
research on sharing patterns for her MIT PhD thesis back around 1990 is
in the same vein; a few experts get to know the nitty gritty, then share
with others. There seems to be a solid body of reseach on phishing right
now that indicates that if you put a padlock in your login form, your
users will be comforted, even if you're trying to phish them. It seems
to me the level of examination that would be required to identify the
problems this finding is targetted at is beyond what most users can or
want to do. 

"There are some cases where it is acceptable to transmit passwords in
the clear;"
I agree with that; diagnostic and testing scenarios, for example.

However...
" one example would be a test page that has no sensitive information on
it where the only reason for the prompting of the password is to stop it
from being indexed by a major search engine. Placing a password on the
page is a simple way to stop the crawling of the pages without really
having to 'secure' the content. "
This is really lame. Users tend to reuse passwords or password
generating strategies. They'll put passwords they use for high value
applications in the clear this way. 

Which I guess you try to target with....

"Because users often cannot tell when a password is being send in the
clear or not, we need another 'Good Practice' to make sure that users
are aware of the resulting vulnerability, and go on to use the same
password again for a application intended to be secure. 

Good Practice 

A user agent MUST notify the user prior to sending a password in clear
text. 

"

At its most naive reading, it will turn into one of those obnoxious
dialogs that gets configured off with a checkbox after first time use.
Which is bad practice (See Whitten's work on Safe Staging;  Alma Whitten
and J. D. Tygar, "Safe Security Staging", CHI 2003 Workshop on
Human-Computer Interaction and Security Systems, Ft. Lauderdale,
Florida. ). While it could be done better, it probably won't. Have you
discussed this one with browser vendors? If it plays out that way,
you've shifted the blame from a lame use of unsecured passwords to
browser vendors; not the right direction for the example you give, imo. 

Also, it's not clear to me that user agents actually know when they're
sending a password. I know of at least one password I type to an
internal application where my brower never asks me if it should remember
it (so I assume the browser does not recognize that password as a
password and hence as something it could save). 

"there are a few common methods used today which are easy to implement;"
But not necessarily easy to deploy into existing configurations. Take
Digest. It presumes storage of the password a certain way (or in the
clear). A system already storing the password in a secure hash not
Digest friendly cannot easily deploy Digest authentication. Which may be
part of what you're getting at in:
"The Digest method assumes that the username and password are
prearranged. The requirement to prearrange usernames and passwords may
complicate or prevent the user of Digest Authentication certain
applications."


"Good Practice 

User agents MUST use password masking when passwords are displayed in an
HTML form." 

It was brought up in our WG that when there's a mismtach between UI
protection and protocol protection, it's confusing to the user. This is
a good recommendation when the password is also protected in transit. It
strikes me as a bad one when it's not. In fact, perhaps the best way to
"notify" the user will be to not mask a password that won't be protected
in transit (perhaps in combination with other cues). The notification is
built into the task, and the user is looking right at it. 

The core Good Practice items are, imo, great and long overdue:

"Good Practice 

A server SHOULD NOT solicit any passwords in clear text. 

Good Practice 

A client or browser SHOULD NOT transmit passwords in clear text. 

" 

I'll be glad to share this with the WSC WG as well. 


          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Rice, Ed (ProCurve)" <ed.rice@hp.com> 

01/02/2007 12:57 PM

To
<Mary_Ellen_Zurko@notesdev.ibm..com> 
cc
<Vincent.Quint@inrialpes.fr> 
Subject
TAG - Password in clear text.

	




Mary Ellen,

The W3C TAG has been working on a finding concerning password in the
clear.  This is in relation to issue 'passwordsInTheClear-52' which can
be found at
http://www.w3.org/2001/tag/issues.html#passwordsInTheClear-52.

The Draft finding can be found at;
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html

To cut to the chase;

The finding concludes;

1) A server SHOULD NOT solicit any passwords in clear text.
2) A client browser SHOULD NOT transmit passwords in clear text.
3) A user agent MUST notify the user prior to sending a password in
clear text.

Prior to the TAG publishing this as a finding we wanted to give you an
opportunity to review it as the chair of the web security group.

I appreciate any thoughts/feedback you may have.
-Ed Rice
W3C Technical Architecture Team
Hewlett Packard, WW IT manager

P.s. feel free to share this with your working group or any others that
you feel could contribute.