RE: TAG - Password in clear text.

Sure. If I was queen of the world, here's what I'd write (attachment at 
bottom).

          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/09/2007 02:20 PM

To
"Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
cc
<Vincent.Quint@inrialpes.fr>, "Noah Mendelsohn" 
<noah_mendelsohn@us.ibm.com>, <www-tag@w3.org>
Subject
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