Re: Comments on draft passwords-in-the-clear finding

For tracker's benefit, this completed ACTION-341.
-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2007-11-07 11:05:54 -0800, Hal Lockhart wrote:
> From: Hal Lockhart <hlockhar@bea.com>
> To: www-tag@w3.org
> Cc: public-wsc-wg@w3.org
> Date: Wed, 7 Nov 2007 11:05:54 -0800
> Subject: Comments on draft passwords-in-the-clear finding
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/2E22E42D2E71B845B67F093A02B962DB0151A124@repbex01.amer.bea.com>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 
> 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 Monday, 19 November 2007 17:05:48 UTC