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?