A
@kaamoss said:First, the password
is hashed with the salt, and then
the resulting value is hashed together with the one time challenge.
The client then sends this value along with the username to the server
for authentication. Is this sufficiently secure?It's a start, but there's more to security than the basic protocol. All the cryptographic tricks in the world won't help you when there's a gaping hole somewhere else, and very few systems fail because of cryptographic errors. I'm not storing any incredibly sensitive data, where using SSL would be reasonableIs there any compelling reason why you can't use SSL? It takes about ten minutes to set up, and only on very highly loaded systems (thousands of concurrent users or more) are there any CPU usage concerns. It will protect against a wide variety of errors that you're otherwise likely to make.Do I even really need the salt, that protects against dictionary attacksYou do need the salt. That is not the reason. The salt and nonce should be of a similar size to the hash; if you're using the printable ascii characters and a 256-bit hash, that means your salt should be about 40 characters long. Its purpose is to compensate for the fact that a typical password has a lot less than 2^256 bits of entropy in it, which otherwise opens various attacks. but I thought those attacks are usually more common with sha1 and md5?The hash function used is irrelevant, as long as it has no known exploits.