Thanks Craig, Thanks Adrian. Craig, Let's revisit your function -
f(password + random garbage + timestamp, Bob's public key) Given our definition of nonce and salt what is "random garbage"? Who generates the "random garbage", and when? Does the "random garbage" need to be shared, if so, how is this achieved? Cheers, Ed -----Original Message----- From: Craig Andera [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
