Services like CAPTCHA are intended to solve different problems, like protecting your web service against DoS or bot/spam attacks.

To brute force crack a password, you would really need direct access to the digest. We are talking around the order of 2^80 attempts before finding a collision with a algorithm like SHA-1. Checks need to happen very fast. Doing this through a web interface is already too slow to be feasible from a time perspective.

So really, cracking passwords is only a consideration when someone gets a hold of all your digests (eg. your database) and can crunch away on them locally for a long time.

I'm really not sure you're talking about the same thing as, well, anybody else doing password security. Brute force incremental crackers (read: almost every password cracker ever written) don't attack the algorithmic strength of SHA1. They attack the complexity of the underlying passwords, using dictionaries, mutation functions, and statistics.

SHA1 is strong (at least in this application). Passwords are very, very weak.

Password cracking is an offline attack. If you think the only way you're going to lose your password table is if someone steals a hard drive or a backup, or uses a zero-day to root your whole server, you are making an extemely bad assumption.

Assuming the webserver is not compromised, the sql server is on it's own local network, and the webserver is on both the local network and the Internet accessable network (2 network cards), how exactly does someone get direct access to the sql server to run an offline attack.

I have always assumed the database server is safe there alone on it's own network as long as someone doesn't break into a machine that is connected to that network.

Consult the Wikipedia on "SQL Injection" attacks.

I already parse everything from the querystring, form fields, (even) cookies (anything the user can manipulate) for malicious input (sql injection). That is standard fare, anyone who doesn't do that will find themselves in a world of hurt fast.

Tell me all the things you parse for, and I'll name something you missed. The catch: if I do, you have to change the front page of your application to this:

http://www.kare11.com/assetpool/images/0791415019_well101HDB...

for at least 2 weeks.

After reading every comment on this thread, I have determined that all posts from Thomas are written using the same pattern.

"Several sentences of very informative information and background on the topic of security for those non-experts (vast majority of us).

One sentence calling the parent poster an embarrassing retard."

Seriously though, I appreciate the insight into the topic and enjoyed your reply post to the one at Coding Horror. Thanks to you I finally understand the reason a decent salt matters, and I'll be sure to ditch SHA1 for bcrypt when I get home. You can rest assured I'm not trying to design my own password system (for anything public)... I was just wondering, are there other systems that do authentication without actually sending the password over the wire besides the supposedly-hard-to-implement Stanford one that may or may not be patented? Bonus points if it's open source...

You are right, and this is a personal failing. Experience suggests I'm unlikely to overcome it. For the record, I don't think any of you are embarassing retards. But after reading comments here and elsewhere --- "that's OK, I'm making my salt 256 bits!" --- I fear that some of the password systems you will devise will be embarassingly retarded.

As for the parent comment: I just really like that picture.

Regarding challenge-response alternatives to SRP: I don't think these work well on the web.

Reason 1: on almost anything unencumbered by the Thomas Wu patent, you're going to have to store cleartext passwords on the server, which is probably worse than forcing clients to send passwords over the wire.

Reason 2: challenge-response only works if you feed the login page and Javascript dependencies over SSL (otherwise, the same attacker who can sniff passwords can hijack and man-in-the-middle logins). But if you trust SSL to feed the login page, why not trust it with the actual passwords?