Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using HTTP Basic Auth in 2022

joeldare.com

Post reply on HN
Print view View original

51–60 of 345 posts

Re: Using HTTP Basic Auth in 2022

#51

Post by gjsman-1000 »

dqv wrote: post #42
gjsman-1000 wrote: post #22

Earlier quoted context omitted.

I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec. Some of your criticisms aren't exactly accurate though. "Sending a password on every request requires care to avoid accidentally logging passwords" applies to almost every login system ever made. Unless you use browser-based hashing with JavaScript, but that has significant known flaws and doesn't add much security. And "Every request needs to do…

>I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec. Yes! I remember in the early aughts, IE6 would present this cool login screen [0] for (what I think, but may be remembering incorrectly) HTTP Basic Auth. I always wanted to do that, but didn't really understand anything other than making basic HTML pages. It could help improve security. It's a ubiquitous login screen that makes it really obvious…

I wouldn't bet on it improving security, personally.

If I was a hacker, I can use the User-Agent to know what OS they are using (or close enough). I also know what browser they are using.

I can use this information to create a custom webpage with a white background and similar imagery to look like the native browser form. If the user was unsuspecting, they might not realize it's not a separate window, and think that they were logging into the correct site.

Re: Using HTTP Basic Auth in 2022

#52

Post by loevborg »

foepys wrote: post #41
loevborg wrote: post #32

Earlier quoted context omitted.

I do the same, e.g. to expose static resources like API docs in an S3 bucket to the world (you can configure CloudFront to check Basic Auth). However, at some point you run into issues (doesn't work well with password managers, how do new team members learn the password, no easy way to rotate passwords when offboarding, etc.). Now I want to upgrade to a proper OAuth wall. Some server needs to act as a reverse proxy t…

> doesn't work well with password managers, how to new team members learn the password, no easy way to rotate passwords when offboarding This is where LDAP and similar are really strong. Unfortunately a lot of companies know that and charge big bucks for this simple feature, often hiding it behind "enterprise" subscriptions where you need to contact them for pricing. It's also the reason why companies love Exchange a…

That's the thing though - I don't want the complexity of Exchange, LDAP, etc. Complexity kills. This is a simple problem calling for a straightforward solution.

Re: Using HTTP Basic Auth in 2022

#53

Post by pmontra »

throwawayboise wrote: post #37
mrweasel wrote: post #6

Earlier quoted context omitted.

While your point is correct: It's not design with a logout in mind, but you can do it. For instance clicking link that will send invalid credentials, that will return a 401 and work like a logout. Mostly I just close my browser, that clear everything in my setup.

I don't see anything wrong with a convention "to log out, close your browser" especially for little internal utility pages.

People could have many open tabs with work in them. Maybe they would have to login again in some of them. Other could come back in a different state, especially with SPA.

Re: Using HTTP Basic Auth in 2022

#54

Post by jerf »

HTTP Basic Auth was deprecated a long time ago, back when HTTPS was a very expensive exotic thing that only large sites used. I'm not sure it would be worth deprecating freshly today if it came up, now that anyone who wants HTTPS can get it easily. It may not be the perfect solution to everything but it does fill in a nice space, even in its current form. If browsers would just pay a bit more attention to it it could become very nice; most of its worst quirks are technically in the browsers, not the protocol.

Re: Using HTTP Basic Auth in 2022

#55

Post by slim »

zimbatm wrote: post #48

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and over again. Plus it would be more secure since the popup is in its own security context. * Add a button to log out. Logout never really worked across browsers with basic auth. * Allow to inject a logo or a tiny bit of customization for branding. The default po…

  Stop passing plain passwords over the wire
this is already solved by https

Re: Using HTTP Basic Auth in 2022

#56

Post by Denvercoder9 »

billpg wrote: post #45
Denvercoder9 wrote: post #40

Earlier quoted context omitted.

Huh? HTTP Basic Authentication doesn't use PBKDF2 (or any other key derivation function).

The server will have a clear-text (leaving the base64 to one side) password in the HTTP request and a PBKDF2 (or similar) token loaded from the user database. Unless you store the user's password in the clear inside your user database, but will have other security issues.

Ok, but if you handle that in the app, it doesn't get invoked for CSS/JS/images/etc requests.

Re: Using HTTP Basic Auth in 2022

#57

Post by kjaftaedi »

You should take a closer look at AppWrite, AzureB2C, or Google's Firebase.

You can even have Azure or Google connect to your own custom identity provider.

It's only a few lines of code to implement user management using identities you control.

I get not wanting to get locked into these things, but once you learn how they function, you can switch between identity providers in minutes.

I do get the sentiment though, but for something like this my vote would be for certificates instead of basic auth.

Re: Using HTTP Basic Auth in 2022

#58

Post by [deleted] »

slim wrote: post #55
zimbatm wrote: post #48

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and over again. Plus it would be more secure since the popup is in its own security context. * Add a button to log out. Logout never really worked across browsers with basic auth. * Allow to inject a logo or a tiny bit of customization for branding. The default po…

Stop passing plain passwords over the wire this is already solved by https

[deleted]

Re: Using HTTP Basic Auth in 2022

#59

Post by codazoda »

billpg wrote: post #11

Wouldn't you need to the substantial workload of PBKDF2 (et al) for each and every HTTP request? Maybe have the images, JS, CCS etc handled by a separate server, but there's still going to be many requests that need to be authenticated for.

Yes, if you use PBKDF2 for the hashing and you do it with every request.

In my template I’m using bcrypt and I’m doing it with every request. That might not scale well.

One commenter suggested storing a session token, probably one that expires, and not authenticating if that exists.

But, I’m using this for MVP’s to see if they’ll gain any kind of traction. Once a tool gets the kind of traction where this will be a problem it will be time to rethink the auth method.

Re: Using HTTP Basic Auth in 2022

#60

Post by klodolph »

billpg wrote: post #49
klodolph wrote: post #25

Earlier quoted context omitted.

I don't see why that couldn't be cached.

Your "is this password valid" cache would need to be indexed by the clear-text password. That's a separate security issue.

Why would you need to index it by the clear-text password? You don't need to retrieve the clear-text password, it doesn't have to be stored in the cache at all.

The cache itself would be in the memory of a process which had access to cleartext passwords anyway, so presumably an exploit which allowed you to read the cache would be damning no matter what.

Post reply on HN