> Can someone help me understand the usage of a salt in > PasswordDeriveBytes? > I think I understand, but I want confirmation. Right now, I > create a salt > for each user when the user is created. I use > PasswordDeriveBytes to create > a userkey based on a password and the salt. Then I store the > userkey and > the salt. Now, I don't want to transmit a password over the > wire right? So > client side code needs three things to prepare its > authentication message. > 1) the password from the user, 2) a nonce, and 3) the salt. > I have not > stored the password because I don't want an attacker to be > able to walk off > with the password file. I have not stored a simple hashed > password because > I don't want an attacker to be able to walk off with the > password file and > use dictionary attacks against it. I have stored a salted > hashed password - > so the client needs the salt in order to create the user key. Is this > right? Should I be allowing anyone to say "My user name is > joe, what is the > salt I should be using?".
I've been writing a system for the last month to deal with exactly this problem. I'm not sure I understand you, but if I do, you're missing something pretty fundamental. Assume a user Alice. Assume she's talking to a system called Bob. Assume a malicious attacker Mallory. You say you don't want to send a password over the wire in the clear. This is correct, but the *reason* is that you don't want Mallory to be able to steal it, since that would mean they could authenticate to Bob as Alice. If you have Alice send a hashed password, all Mallory has to do is to steal that and transmit it to Bob with Mallory's fake request. There are generally two approaches to this: 1) Make sure you use SSL or the equivalent between Alice and Bob. In that case, Mallory can't read their traffic. Note that sophisticated attackers might still be able to do something useful with the traffic, but it's better. 2) If you can't encrypt the channel, encrypt the password USING A RANDOMLY SALTED PUBLIC KEY CIPHER. That is, you send f(password + random garbage + timestamp, Bob's public key), where f is something like RSA. Anyone can perform the encryption - the public key is widely known - but only Bob can decrypt the password. Appending random salt means that Mallory can't just dictionary the password. Using a timestamp means that Mallory has to be quick to simply replay the encrypted password. 1 is by far preferable. 2 is still subject to replay attacks, albeit only within a certain timeframe. 2 has the additional problem of requiring Alice and Bob to synchronize their clocks. Note that 2 requires a PUBLIC key algorithm. If you use a symmetric cypher like DES, you have the problem of how to get Alice the shared key securely. Make sense? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
