Comments on draft passwords-in-the-clear finding

Members of the TAG,

As a follow up to our joint discussion yesterday, I am reiterating and
expanding on the two comments I made. While most of the discussion,
rightly focused on the major findings, I believe these points should
also be addressed in the final version of the document as any technical
inaccuracies in the document will tend to undermine the force of its
recommendations.

A. Near the beginning of section 2 the following text appears:

"2. The password is available in browsing history. Most web browsers
allow you to navigate 'back' to previous pages, with content locally
cached for performance as well as ease of use for the user. These pages
are stored in memory and are relatively easy to examine."

As Tim pointed out, this item does not exactly fall under the subject of
the finding, so perhaps it will be omitted. Assuming it is retained, I
believe it should be corrected. 

If the password is being sent from the server to the user agent as a
part of content, this may be true, but transmitting passwords is rare in
practice. In the much more common case that the password has been
entered by the user, I don't believe the assertions are correct. I
personally have never seen a case where this is possible (security
people actually spend time trying stuff like this) and I would be very
interested to hear of a specific website and browser combination where
this is true.

In any event, I believe that this problem can be avoided in all cases by
use proper coding practices in the user agent, server and/or web
application. If the TAG is concerned about this issue, I suggest that
the document describe and recommend the software best practices which
will prevent this from occurring. 

B. In section 2.1 the following text appears:

"Digest Access Authentication[Digest]:

    Digest acts as an extension to HTTP 1.0 and offers a way for
authentication to happen between parties using a 'shared secret' (a
password). This verification method can be done without transmission of
the password in clear text to address the HTTP 1.0 Basic method of
authentication. 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."

This explanation is inaccurate. The practical difficulty in making use
of digest is not prearrangement. Both cleartext and digest passwords can
be used in a self-service environment. The problem is that both parties
must posses or be able to derive exactly the same secret. Most
organizations store a salted hash of the password, which in practice
cannot be derived by the client.

For those not interested in the details I propose the follow replacement
text:

Digest Access Authentication[Digest]:

    Digest acts as an extension to HTTP 1.0 and offers a way for
authentication to happen between parties using a without transmitting
the password over the network. Instead the password is treated as a
secret input to a digest algorithm. The resulting digest is transmitted
and verified by the server. Unfortunately the Digest method requires
that both parties have access to the same initial secret value. Because
most passwords are stored as a salted hash, it is not possible in
practice for both parties to compute the same initial secret value. 

For those who are interested, here are the details.

Most passwords, whether stored in a UNIX password file, database, LDAP
server or other repository are stored as a salted hash. What this means
is that for each userid/password, an arbitrary value called the salt is
chosen. The salt is combined with the password and some sort of one way
algorithm is applied to calculate a hash value. Both the resulting value
and the salt are stored in the password repository. When a cleartext
password is received (whether over a secure channel or not) the server
combines it with the salt and computes the hash. This value is compared
to the stored value.

The purpose of this exercise has nothing to do with communications
security. It is intended to make life more difficult for an attacker who
manages get a hold of the password file. (This was relatively common 10
years ago.) The use of a one way hash means the attacker must make a
series of guesses and check them to obtain each password. The use of a
salt prevents the attacker from precomputing hash values for a large set
of guesses and comparing them to all the stored values. The salted hash
is so popular that many organizations have incorporated it into their
corporate security policy.

Digest authentication works by using a secret known to both parties as
an input to a one way function. The problem is that with a salted hash,
there is no secret value known to both parties. Obviously the server
does not know the original password. In theory, the client could compute
the salted hash of the password and that could be used as the shared
secret. However in practice, there is no way for the client to discover
the salt value for a particular userid.

Hal

Received on Wednesday, 7 November 2007 19:06:50 UTC