RE: New version of Passwords in the Clear

Noah,

Are you suggesting that if the server application is accessed via a VPN
than it should be ok for the password to be transmitted without an
Secure Socket?  If that's the case, than anyone on the same VPN has
access to the password as well, and since most vulnerabilities happen
within the confines of the 'corporate' firewall.. I'm not sure that an
adequate safeguard.

The only possible exception I could see would be if you had only two
computers on your network and they're together in a locked room.  But
then its outside of the scope of the world wide web so the finding
doesn't apply.

My 2c.
-Ed
 

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of noah_mendelsohn@us.ibm.com
Sent: Tuesday, November 14, 2006 9:21 AM
To: John Cowan
Cc: Vincent Quint; www-tag@w3.org
Subject: Re: New version of Passwords in the Clear


John Cowan writes:

> Vincent Quint scripsit:
> 
> > Thanks to Ed, a new version of the draft finding "Passwords in the
Clear"
> > is available at:
> > 
> >
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.html
> >    http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
> 
> This draft mentions HTTP basic authentication only obliquely; it 
> should make it clear that using it is an instance of
passwords-in-the-clear.

I wonder whether the problem isn't the failure of the finding to more
"clearly" define the phrase "in the clear". 

In fact, I think it's a rather subtle concept, because it's relative to
who you think is doing the looking.  We think of http basic being "in
the clear" when used over ordinary TCP connections, but less so over SSL
or other "encrypted" connections.  Why?  I think it's because we
understand that, as the finding pretty much says, messages sent using
HTTP basic without SSL wind up in a lot of places where a lot of people
have the tools necessary to see them in their original form, i.e. as
plain text. 
There are log viewers, proxy caches that can be searched, etc.  It's
assumed that many fewer people, if any, have the tools to crack digest
authentication, so in that sense passwords sent using digest are in the
clear for a much smaller community, and indeed we hope only for the
intended recipient.  Indeed, perspectives on what's 'in the clear' may
change over time.  I believe there was a time when if you said that you
were using spread spectrum transmission techniques the military would
have presumed you were using an advanced encrypted radio channel.  Now
we all have 802.11 receivers that readily "crack" at least one form of
spread spectrum transmission.

So, I wonder whether it would be worth more carefully defining what we
mean by "in the clear"?

=========SUGGESTED ROUGH DRAFT OF NEW SECTION ==========================

2. When is a transmission "In The Clear"?

Computer messages are encoded at a variety of levels.  For example, text
may be encoded using Unicode, which in turn is represented using some
transmission protocol, and ultimately transmitted or stored as
electrical impulses, optical brightness levels, magnetic polarizations,
etc. If you have the necessary equipment and are able to decode the
encodings used, you can retrieve the information in a message.

This finding concerns itself with assuring that certain messages, and in
particular passwords transmitted in such messages, be safely hidden from
those who are not intended to receive them. 

Definition:  Accordingly, we say that a message or a password is "in the
clear" if the representation used to transmit it is likely to be
decodable by those other than the intended receiver.

In particular, we observe that messages transmitted using HTTP over TCP
(as opposed to HTTP over an encrypted channel such as SSL or TLS) tend
to be decodable from message logs, from Web caches, by using packet
sniffers, and with a wide variety of other commonly available tools and
software libraries.  Accordingly, this finding takes the position that,
unless additional means are used to protect the content, any message
sent using HTTP over (unencrypted)  TCP should be presumed to be "in the
clear", and thus vulnerable to unintended inspection.

One common means to ensure that messages or portions of messages are not
in the clear is through use of encryption, by which we mean encodings
that are easy to decode when certain particular information such as a
key is available, but impractically difficult to decode otherwise.
Encryption may be used to encode a message prior to submission for
transmission, or may be achieved as a byproduct of using an encrypted
channel (which typically only protects the message while it's in
transit, as opposed to at the sender or receiver.)  A message sent using
encryption is viewed as being "not in the clear" to the extent that the
encryption used is sufficiently difficult to decode by unintended
receivers, I.e. that its methods a robust against decoding without a
key, and that key distribution is done sufficiently carefully that
unintended recipients are unlikely to obtain the necessary keys. 

=========END SUGGESTED ROUGH DRAFT OF NEW SECTION
==========================

With that in hand, I think the admonitions to "not solicit" passwords in
the clear and not "transmit passwords in the clear" take on some teeth. 
This definition allows us to do what I think John is asking, which is to
talk a bit more about basic vs. digest authentication, and to explain
the senses in which each is or isn't "in the clear", when transmitted
using ordinary HTTP over TCP vs HTTP over SSL or TLS.

Thanks.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 15 November 2006 18:03:01 UTC