RE: New version of Passwords in the Clear

Ed Rice asks:

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

No, I don't think what I wrote suggests that at all.

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

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

Indeed.  But I think if you look at what I wrote it's quite appropriate. 
Specifically:

I wrote:

"In fact, I think it's a rather subtle concept, because it's relative to 
who you think is doing the looking."

Your VPN is a good example of that.  You've decided that you care about 
people who are trying to "look" from within the corporate network as well 
as outside.  VPN doesn't purport to deal 

I wrote:

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

I carefully avoided saying the converse, which would have been that 
picking an arbitrary encryption or security approach such as VPN would 
necessarily give you protection appropriate to your use case.  The 
definition above still applies.

I wrote:

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

In the case of your example, you've decided that the intended recievers do 
not include some of the other folks who are on the same corporate network. 
 Accordingly, your VPN+HTTP Basic is not a suitably secure combination, 
because as you say passwords will tend to be unencrypted when users on the 
corporate network go looking for them.

Indeed, the whole reason I suggested clarifying the finding is that it 
gives a strong admonition not to "send passwords in the clear" without 
pointing to any defintion of what "in the clear means".  Your VPN is one 
of many that suggest that the concept is not self-evident, because HTTP 
Basic over VPN is indeed opaque to typical users of the "public" network, 
but potentially "in the clear" once the message starts moving around the 
corporate network.    So, I still think clarification would be helpful.

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








"Rice, Ed (ProCurve)" <ed.rice@hp.com>
Sent by: www-tag-request@w3.org
11/15/2006 01:02 PM
 
        To:     <noah_mendelsohn@us.ibm.com>, "John Cowan" 
<cowan@ccil.org>
        cc:     "Vincent Quint" <Vincent.Quint@inrialpes.fr>, 
<www-tag@w3.org>
        Subject:        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:59:11 UTC