Err, I think your protocol is still subject to dictionary attacks
against weak passwords. E.g., I'm Mallory, I intercept
{h(h(P+S), N), S, N}
all of which are sent cleartext, then use a dictionary attack to recover
P by simply permuting P values and computing
h(h(P+S), N)
until he gets a match. Mallory can't precompute this quantity for all
values of N, but users tend to use crappy passwords, and he can most
likely try a few million per second on a fast machine.
I agree with your definition of salt, BTW: it's something we keep around
for a while. A nonce is something we use once.
Schneier, Applied Cryptography: "Salt isn't a panacea; increasing the
number of salt bits won't solve everything. Salt only protects against
general dictionary attacks on a password file, not a concerted attack on
a single password. It protects people who have the same password on
multiple machines, but doesn't make poorly chosen passwords any better."
If you are implementing security, I highly suggest reading the first
third of this book, and using the rest as reference.
> -----Original Message-----
> From: Pinto, Ed [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
>
>
> Hey Craig,
> Thanks for the reply. I guess I should have been more clear.
> I agree that
> channel encryption is important, however, my question is
> about the security
> protocol, not about the channel.
>
> I guess I'm somewhat confused about two commonly used terms - salt and
> nonce. What you refer to as "random salt" I've always
> thought as a nonce
> ("number used once"). To me, the term salt has always represented a
> randomly generated, but persisted set of bytes that are used to make
> dictionary attacks impractical. Using my definition of salt,
> here is my
> question in a little more detail.
>
> Let's say the user creates a password P and the system
> creates a salt S and
> hashes the password and the salt creating a userkey K. The
> system then
> stores the username U, the userkey K, and the salt S. Then, for
> authentication:
>
> 1. If the client sends username U
> U
>
> 2. The server creates a nonce N with a short TTL and sends it
> and the salt S
> N, S
>
> 3. The client applies hash h to the user's password P, and
> the salt using
> the PasswordDeriveBytes class, and then hashes this with the nonce
> h(h(P + S), N)
>
> 4. If the nonce's TTL has not expired when the client submits
> its response,
> the server then uses the same function to verify that
> h(K, N)
> Matches whatever the client sent (where K = userkey as defined above).
>
> My question is about step 1 and 2. Is this how the salt is
> supposed to be
> managed?
>
> Cheers,
> Ed
>
> You can read messages from the Advanced DOTNET archive,
> unsubscribe from Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
