[x500standard] Re: New draft on password policy
- From: David Wilson <David.Wilson@xxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Wed, 23 Sep 2009 21:03:05 +0100
On Wed, 2009-09-23 at 15:34 -0400, Santosh Chokhani wrote:
>
> I am not sure if I fully understand the context, but whoever gave DUA
> the encrypted password can supply the salt. The salt is not a secret.
> Its sole purpose is to make dictionary attack less effective by
> forcing the attack to compute encrypted text for all the salts.
My understanding is of an authentication mechanism (case 2 in the table
sent out earlier) which involves the client sending an 'encrypted
password' and the server compares this directly with the stored
'encrypted password'. The final column says that the client needs to
store too much information. Part of that is any salt (or nonce) used in
the case that the 'encryption' is actually just hashing (if it is
actually encrypted, then the key is needed, of course).
In addition, since the value passed in protocol is the authenicator, it
is a password equivalent. An attacker simply needs to send the value it
has seen the client send. This is why it is, for this server, a plain
text equivalent.
The alternative is that the server holds the plain text password, and
the client hashes the password with a different salt each time, and the
salt is passed with the hashed value. (For mechanisms which generate a
single string, the salt is a known part of the hashed value, for 'crypt'
hashing it is the first two characters). However this, by itself, is not
OK as:
- server has the plain text password
- you actually need to include a timestamp within the hashed value as
well, to limit the number of values the server needs to retain so that
it can detect replay attempts.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
