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
--------------------------------------