W3C home > Mailing lists > Public > www-tag@w3.org > January 2007

Fw: Re: TAG - Password in clear text.

From: <Vincent.Quint@inrialpes.fr>
Date: Sat, 6 Jan 2007 12:06:08 +0100 (CET)
Message-ID: <38118.82.67.73.67.1168081568.squirrel@webmail.inrialpes.fr>
To: www-tag@w3.org
Cc: Mary_Ellen_Zurko@notesdev.ibm.com

All,

At the last f2f meeting the TAG decided to offer the
Web Security Context Working Group an opportunity to
review the draft TAG finding on Passwords in the Clear.
Here is a message from the chair, Mary Ellen Zurko
(with her authorization), providing comments on the
draft. What is now a technical discussion should
continue on this public mailing list.

Vincent.

Begin forwarded message:

Date: Tue, 2 Jan 2007 18:04:55 -0500
From: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
To: "Rice, Ed (ProCurve)" <ed.rice@hp.com>
Cc: Vincent.Quint@inrialpes.fr, "Noah Mendelsohn"
<noah_mendelsohn@us.ibm.com>
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.
Received on Saturday, 6 January 2007 11:06:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:51 UTC