Basic Authentication over HTTP – The Evil | Hacker News Reader

Basic Authentication over HTTP – The Evil

adnanahmed.info

16 pointsidnan11 comments

What an idiotic article.

> The server simply uses base64 to decode the Authorization header to retrieve the given username and password to authenticate against.

The encoding had fuck all to do with security.

> The HTTP protocol unlike its sibling HTTPS is not encrypted. So it means that everyone on internet can see what you send.

No, that's not how it works at all. I have to be somewhere in between you and the server to see what you're transmitting in plain text. I can't just read random fucking data from Joe Bloggs.

> It means that all of our HTTP calls are open to any malicious hacker sitting in between us and the server

Oh ok, you know that. So why sensationalize your previous point?

> I did have to stick my credentials in the Authorization header when I made the request.

You're missing the point, if it's unencrypted it doesn't matter where the data is.

I agree that the article is very poorly written, and inaccurate in places.

But at this point, having seen thousands of customers use Basic auth over HTTP, I don't actually care how sensationalized the article is. If it gets people to stop doing it, I'm all for it. We can explain the nuances later.

Frankly, the nuances of /why/ it's bad are somewhat less important than just knowing it's bad. This isn't true for all cases, but I would argue is true for what is probably one of the most common issues we see.

What a pointless post and sensationalized title. The problem is not Basic Authentication, it's HTTP.

Yeah, it‘s just three paragraphs explaining that HTTP is not encrypted.

Plain HTTP is fine if we send it over an encrypted connection. Hmm... I wonder if we could use TLS for that?

;)

"Despite its simplicity, you should never ever use basic authentication over HTTP! Basic authentication should only be considered over HTTPS."

Small correction: You should NEVER EVER use ANY authentication mechanism over HTTP. Basic authentication has its uses, and for those use cases it works fine using HTTPS

Another way to look at this article is that Basic authentication may be a perfectly acceptable implementation over HTTPS, as opposed to something like Oauth2 when you aren't even using it for authorization. I've seen APIs that aren't user-facing at all and use Oauth2 merely for authentication. Pointless. Your best line of defense is HTTPS.

Suppose I develop a website that uses basic authentication. Because this is 2018, I store my user's passwords using bcrypt/scrypt/PBKDF2/et al.

Every single request supplies the claimed password in the clear (wrapped in HTTPS) so I would need to run the long hashing process for every single request.

I could maybe cache those clear-passwords that I know are good in memory, but that's getting dangerously close to storing user's passwords in the clear.

Is there a good practice for using basic authentication without over burdening the server's CPU?

yes, get more CPU's if your auth server is hitting it's limits.

Scale it by moving auth to it's own URL, so you can then load-balance it differently if needed (and can add more security like disallowing Javascript at all - via headers, etc)

But first, verify you are actually hitting CPU max because of bcrypt/scrypt/etc and not just because of crappy code or something.

Revelation of the century...

Upvote bot?

Reply on news.ycombinator.com