Basically, the client must send something that is what you store in the database, or which can be transformed into same through an algorithm.

Now, since the function of that algorithm depends solely on inputs from the client and stored values already on the server, there’s no way to secure it if they know the values on the server or what the expected response is. All you can do is to make it difficult (take longer to brute force). You can’t actually make it impossible.

http://tools.ietf.org/html/rfc2831

however, that’s being replace with SCRAM:

http://tools.ietf.or[...]asl-scram-11

using one of these schemes that have been fully-vetted by the security community is a much better approach, even if you have to pull it up into your application rather doing inside the protocol like SASL imagines.

Setting up a self-signed SSL cert, or buying and installing one (basic validation is only a few dollars now) isn’t a huge deal. Most just skip the step to speed and because it just works.

Put a barrier there and people will second guess disabling a security feature.

IMHO all apps should require SSL for login. I have an SSL cert for my blog for the purpose of securing the contact form, and for login (most important).

For best security, the salt value is kept secret, separate from the password database. This provides an advantage when a database is stolen, but the salt is not. To determine a password from a stolen hash, an attacker cannot simply try common passwords (such as English language words or names). Rather, they must calculate the hashes of random characters (at least for the portion of the input they know is the salt), which is much slower.

In some protocols, the salt is transmitted as cleartext with the encrypted data, sometimes along with the number of iterations used in generating the key (for key strengthening).

I think that a hash of a hashed string plus salt can make it harder to reverse, but once the algorithm is figured out it’s just layers.

Am I misinformed?

The problem with database only, is that it seems rare only the DB is compromised. Normally it’s the last to be attacked, the web app being in front of the DB. The DB should be the most restricted (only the webapp needs to even communicate with it).

That said, you can pretty much solve wire attacks by using SSL which also verifies identity and helps against MITM attacks. IMHO more worthwhile than a JS solution. Overhead is reduced if you have SSL hardware on your server.

That’s another good reason to optimize against a wire attack vs. a database only attack.