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

41–50 of 345 posts

Re: Using HTTP Basic Auth in 2022

#41

Post by foepys »

loevborg wrote: post #32
nuccy wrote: post #12

I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-…

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 and the rest of Microsoft's ecosystem.

Re: Using HTTP Basic Auth in 2022

#42

Post by dqv »

gjsman-1000 wrote: post #22
yuliyp wrote: post #13

This has many flaws that make it impractical beyond hobby projects or projects with a small set of users: - It's trickier to throttle credential checks as every request is a login request, effectively - It's hard to easily build account recovery flows or captchas into the login process. - The UX of logging in/out is browser-dependent and confusing for users - it can't integrate well with other auth systems - Sending…

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 which domain is requesting credentials - no need to check if the page looks off to detect possible phishing. Oh and you wouldn't run in to the issue of accidentally logging in on the sign up page!

[0]: https://blog.stevensanderson.com/2008/08/25/using-the-browse...

Re: Using HTTP Basic Auth in 2022

#43

Post by zanny »

SavantIdiot wrote: post #10
sdze wrote: post #3

This is perfectly fine. Nothing to be ashamed of. At least you don’t need to create a logon form

But if you are rolling your own auth, you still need to create the signup, change password, reset password, confirm account, delete account, etc. pages. What's one more? Given that a logon form is >5% of the total amount of work to roll auth, seems kinda pointless to use this.

I definitely think doing openid logins is way easier than any home rolled auth scheme.

Delegate responsibility where you can, which includes use authentication. It sucks that Persona died all those years ago because web browsers really could use an identity system for users to authenticate themselves against sites with their browser accounts.

The problem is then ofc getting browsers to cooperatively allow cross sign in. If messengers are anything to go by, siloed products really do not want to interoperate, particularly I imagine Edge and Safari.

Re: Using HTTP Basic Auth in 2022

#45

Post by billpg »

Denvercoder9 wrote: post #40
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.

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.

Re: Using HTTP Basic Auth in 2022

#47

Post by pmontra »

ithkuil wrote: post #2

How do you logout?

With Firefox, from the Preferences, select only "Active logins" in the Clear History dialog [1]. Very odd that it belongs to history and far from ideal. However it's not something a lot of people use nowadays so I'm not surprised that they tucked it under the carpet.

I use Basic Authentication for a few web services running on a server of mine and that I'm the only user of. It saves me a lot of work. I set the user and password in a file on the server and let nginx deal with it.

[1] https://security.stackexchange.com/questions/192828/firefox-...

Re: Using HTTP Basic Auth in 2022

#48

Post by zimbatm »

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 popup looks too ugly.

* Improve the Digest auth to modern crypto standards. Stop passing plain passwords over the wire.

That's it. It's not a massive amount of work and it could enable to simplify a lot of the Internet.

Re: Using HTTP Basic Auth in 2022

#49

Post by billpg »

klodolph wrote: post #25
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.

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.

Re: Using HTTP Basic Auth in 2022

#50

Post by mckmk »

loevborg wrote: post #32
nuccy wrote: post #12

I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-…

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…

Google Cloud offers Identity Aware Proxy and AWS offers Cognito integration with their Application Load Balancers which can do this.
Post reply on HN