Either I'm not understanding your strategy, or there are some problems with it. I'm not sure which is more likely. :)
> You're right about the salt, it's basically to make it so the > same password > will not lead to the same hash, and also to prevent > pre-computed dictionary > attacks, where an attacker can make a list of every hash for > every possible > password (or a reasonable subset) and then just do a simple > lookup. The salt > is not a secret, and should just be stored as the first N > characters of the > password on the server. That's the quick answer to your > question. For more > info, continue reading. Agreed, although I'm not sure the salt shouldn't be considered a "secret". It should be as secret as the password hashes, which benefit from all the protection you can reasonably manage. > The problem with your scheme is that the security lies in > keeping h(P+S) > secret, but that's what's going to be stored in your password > file. So a > compromise of the password file will give an attacker access > to the user's > account, because say the hashes in the password file are > called C, then all > the attacker has to do is sniff the nonce and then compute > h(C,N) and then > they'd have everything required to log in. You follow? Agreed. Although I'd argue that it depends on what you're trying to protect against. If what you care about is that a *particular* user not get compromised (e.g. admin), then this is a major issue. If what you care about is that *no* user get compromised, then a dictionary attack against the stolen password hash file will likely succeed on at least one password - at least one user will choose a crap password - and nothing you do will help. If they know the password, they can log in. > What has to happen, somehow, is the nonce must be hashed with > a secret. The > secret is the unknown for the attacker, but if your password file is > compromised, then the hash of the password+salt is known. So > you can't use > the hash of the password+salt as the secret if you want to > protect against > the problem of your password file getting compromised. If > you're not worried > about the password file being compromised, then you don't > need a salt at all > anyways. The important part to figuring out these types of > schemes is to > define exactly what the secret is. In your case it's not the > password, it's > the hash of the password+salt. And with your system that > secret is stored in > plaintext in the password file. I agree that a secret is needed. Ultimately, that's going to be the password, UNLESS you're using a public key system. Otherwise, you're using hashes or symmetric key cyphers, and the attacker is going to either know the hash algorithm or be able to get the private key. > So what you need is a secret that is only known to the user > and the server. As I said, that'll be the password. All other secrets that are derived from the password and information that an attacker knows are equivalent to the password. > That's obvious. You need that secret to be hashed with the > nonce in one > operation. That's the hard part. You obviously can't just > store the secret > on the server as is, yet the server needs to be able to > perform an operation > using the secret. So it sounds like what you need to do is > not only hash the > password, but you need to then encrypt that hash to store on > the server. > Then when it comes time to authenticate, you decrypt the > stored secret, > which gives you the password hash, then have both the user > and server hash > that with a nonce, and compare. You follow? I don't get this at all. What good does encrypting the password hash do? Where do we store the key for encryption that an attacker can't steal that, but can steal the password file? I know you mention DPAPI but if they can get to the password file - which must have a DACL on it - they can presumably get to other resources that are only accessable by your authentication infrastructure. I'm curious to hear you explain this more - I don't claim to be an expert, and if I'm missing something I'd love to know. What's particularly interesting is to note what Windows does: NTLM sends a challenge (nonce), and you hash your password with the nonce and send it back. Subject to dictionary attacks? Yes. Oddly, though, we use it every day without thinking about it too much. But then, we generally don't send this traffic over the Internet. Not sure if that's what the original question is talking about or not. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
