On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.
At first that appears to not store the plaintext of the password, but looking closer, isn't it really using the hash as a password? That is, if the bad guys got a copy of the hashes stored on the server, they could use a modified client to log in.
The protocol is requiring the client to prove that the client knows that hash, not that the client knows the password, if I'm reading it right (I might not be).
Yes, the intermediate hash is password-equivalent, but at least you haven't (directly) handed over your Google Mail password at the same time.
SRP was designed, in part, to make the serverside storage of passwords crypto-hard to break. It's an elegant protocol, but it's a little more complex than digest auth.
None of this stuff is anywhere nearly as safe as bcrypt and TLS with form auth. Digest HTTP auth can, in fact, make you even less safe than unencrypted form auth.
You're right; if you go out of your way, you can instead store an extraordinarily viciously crackable derivative of the password. I'd stick with basic auth and use BCrypt on the server; you're far more likely to lose your whole password database than you are to lose a significant number of basic auth logins to interception.
That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Ad...
On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.