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 Tuesday, 14 November 2006 20:21:39 UTC