[x500standard] Re: New draft on password policy
- From: "Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Wed, 23 Sep 2009 16:06:17 -0400
I think I am digressing, but when you encrypt, you do not need the key
necessarily since both the data and key can be password (the way Unix
used to do, and may be still does).
> -----Original Message-----
> From: x500standard-bounce@xxxxxxxxxxxxx
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Wilson
> Sent: Wednesday, September 23, 2009 4:03 PM
> To: x500standard@xxxxxxxxxxxxx
> Subject: [x500standard] Re: New draft on password policy
>
> 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.
>
>
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
