I know that .NET's Rfc2898DeriveBytes requires at least 8 bytes of salt, but how many bytes are ideal?
When a user is created, or changes their password, my server stores a new random salt for that user, and a "hash", which is really just some number of bytes from
Rfc2898DeriveBytes (ed: .NET's implementation of PBKDF2), using the user's password and the salt, and 5000 iterations.
My client app connects to the server via SSL, sends the user's user name, the server sends the salt for that user, the client calls
Rfc2898DeriveBytes with the user's password and the salt, and sends that "hash" to the server for authentication. If the server receives an invalid user name, it returns a random salt, so that the client doesn't know whether the user name or the password is invalid, and so some time is wasted to hamper hacking.
My understanding about salt is that it's really only intended to get different keys for the same password, which would lead me to think that 8 random bytes should suffice, but since I'm sending it over SSL, I'm wondering if a longer salt would increase security somehow.
Besides the number of salt bytes, how many "hash" bytes would be best?