If the salt is considered a secret, then what's it's purpose? It can't be sent to the client (because it's a secret), and it therefore cannot be hashed with the password on the client side. So therefore it can't have been hashed with the password for storage on the server, because that'd be useless. The whole point is that you have to do the exact same operation on both the client side and the server side if you want to communicate over an insecure channel. So you need to have the exact same information on the client and server. The idea is to essentially do H(S+R) where H is a hash function, S is the secret, and R is something random to prevent replay attacks. Anything else you do is just obfuscation, which does not add security. H(S+R) must be done on both the client and the server, and therefore the exact same S and R must be available to both the client and the server. There's really nothing more to discuss with regards to that matter.
What I was trying to point out, was that the salting you were suggesting added nothing to the security of the scheme. It only served to make it harder to crack the passwords if the password file is compromised. It does not make it any harder to log in to your system if the password files were compromised, because you end up hashing the exact contents of the password file as part of your scheme. So the attacker doesn't need to know the password. Recovering the plaintext passwords is more difficult though, but how important is that if the plaintext passwords aren't needed to log into the system. As far as encrypting the password goes, it definitely does add an extra layer of protection because the password file on it's own is useless. Sure, if the attacker compromises the entire system and is able to run code on the server, then he can just inject code that will decrypt the password file and print it out. But, it is far more often the case that a password file becomes readable by some human error, either permissions aren't set up properly, it's FTPed or emailed to some other system, or whatever. If this is the case, then my scheme will protect you. Obviously if the server needs to work with the secret, then it's impossible to make that secret 100% secure, but encrypting the password file adds another important layer of security. NTLM, HTTP Digest, these all hash the password with a nonce or challenge. That shouldn't be news to anyone. If the hash algorithm is secure, then this scheme is secure, and that's a pretty well known fact. Salting assists in password storage, as it is mixed in with the password before hashing occurs. Therefore if the salt is not available to the client, then it cannot be mixed in with the password before hashing occurs on the client side, so it is useless. The salt must be known by whomever is doing the hashing, no matter what. Whether you want to call it a secret or not is irrelevant, it's really just being treated as part of the password. Now, if you actually come up with a password based authentication scheme that is impervious to brute-force attacks (or slightly more intelligent brute force attacks, which we'll call dictionary attacks), then that's news. But salting sure as heck isn't the answer. Using a public key cryptosystem may be the answer, but the nightmare of key management should never be underestimated, especially if you want your users to be able to access your system from a web-cafe (for example). Using certificates and whatnot would be a very good idea however, if it's feasible for your application. But the question was asking about salts, it wasn't asking for a recommendation on the entire authentication infrastructure. Even if it was, there was not enough information given about the application for anyone to just say "use a public key cryptosystem". Jordan Frank eBusiness Applications www.ebusinessapplications.ca [EMAIL PROTECTED] ----- Original Message ----- From: "Craig Andera" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 07, 2003 6:59 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes [...] You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
