Is Basic Authentication Really Insecure?

http://www.skorks.com/2009/08/is-basic-authentication-really-insecure/

by askorkin • 17 years ago

12 12 17 years ago

wizard_2• 17 years ago

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.)

tptacek4• 17 years ago

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.

Nobody uses digest.

mastrix• 17 years ago

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).

reginaldo• 17 years ago

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).

askorkin2• 17 years ago

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.

tptacek4• 17 years ago

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.

there• 17 years ago

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.

tptacek4• 17 years ago

You could stop that behavior with a session cookie, but then you might as well just bite the bullet and use form auth.

askorkin2• 17 years ago

Agreed, that is an issue unfortunately.

charlesju• 17 years ago

The only way to intercept this data is to:

1. Hijack a DNS on route

2. Sniff packets from the air or wire of the computer or server

right?

Both of those seem like reasonably safe risks to take.

mason55• 17 years ago

>2. Sniff packets from the air or wire of the computer or server

From your home connection, maybe. Anywhere else I wouldn't trust it.

Is Basic Authentication Really Insecure?

Related Stories