The problem with basic auth has nothing to do with how it's encoded. All authentication is insecure in flight if you're not using SSL. The problem with basic auth is that you can't log out.
You may work on a computer that only your cat can access, but a lot of people --- maybe most --- don't have that luxury.
it might be worth noting that basic auth is slightly worse than the others because it sends your password across in the clear for every request, whereas session-based authentication is only sending it once.
if i login to flickr at home and then go to a coffee shop a few days later, i'm never sending my password in the clear. of course, someone can steal my session cookie and be me, but they still won't have my actual password. with basic auth, i would have been giving my password out on every page view.
Yes, yes it is. The article talks about how non plain text authentication schemes are moot if you've got tls (https). I think you should. While this idea violates defense in depth strategies I think the core of his argument is compares apples to oranges.
Refraining from sending passwords plain text along your transport is always a good idea. Even if on the public internet the password's transport may be encrypted, once it hits your network it might not be. HTTPS accelerators (or reverse proxies) will remove this secure layer and with basic authentication you'll be left with the base64 clad password.
While you could argue that if your local networks are compromised you're screwed anyway. (think bad network topology in your data center) Think back to defense in depth, I'd rather the passwords never enter my network to begin with. (Think digest, or better yet Kerberos.)
Agreed. I believe the author doesn't get what a well designed protocol aims to provide: good security, even if some of the mediums are compromised.
Any plaintext-equivalent protocol (including the recommended http digest) will be susceptible to a wide range of attacks. For digest, authentication, there's chosen plaintext Attack, man in the middle, online dictionary attack, and others. And, given enough motivation, there will certainly be someone to carry those attacks. So security is never too much. And I think we're responsible to use schemes that are harder too break, once they are known.
These days when I need a simple auth protocol (one that doesn't require a trusted third party), I stick with Stanford's SRP. It's a zero-knowledge protocol (the client doesn't leak any information about the password, not even to the host, except the fact that it knows it). At first this looks like black magic, but in the end it's easy to understand (and implement).
Digest is worse than Basic-Auth: it has most of the same underlying problems, and adds the problem that your passwords need to be stored cleartext on the server.
It requires the server to store _either_ the password or the hash of the concatenated username, password, and realm. As long as the realm used in the challenge is consistent, the password need not be stored (at all, anywhere).
If you want the challenge to be password-equivalent, then yes, you can avoid storing the password. This defeats one of the purposes of digest authentication.
Note also that by doing this, you're also conceding to store the password in an extremely insecure hashed format. It's not as bad as cleartext, but it's markedly worse than a real password hash.
I do appreciate what you're saying, but with this kind of thinking, where do you stop? Yes you can do defense in depth and defensive programming and all sorts of nice things. But if you tried to do this for every scenario all the time, you would never get anything done. At some point you need to trade off being productive against well pretty much anything else, which is basically YAGNI, i.e. do enough but don't go overboard.
You may work on a computer that only your cat can access, but a lot of people --- maybe most --- don't have that luxury.