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

31–40 of 345 posts

Re: Using HTTP Basic Auth in 2022

#31

Post by mbreese »

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 have a few webpages that have to be protected this way, due to an external client that only supports HTTP Auth. I’ve actually been pretty happy with this setup. I have nginx configured to use subauth authentication so I can still have external username/passwords stored in LDAP, etc. It’s been a surprisingly good combination.

Re: Using HTTP Basic Auth in 2022

#32

Post by loevborg »

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 that has permission to access the private resource but checks your identity as a, say, Google Apps user.

Assuming a private bucket on S3, what's the easiest way to accomplish this today?

Re: Using HTTP Basic Auth in 2022

#33

Post by zinekeller »

forgotmypw17 wrote: post #23

I use it as a captcha. It's great for keeping crawler bots out, and easy enough for humans to get past. Once a user logs in, I set a cookie, and the user is not prompted for the auth again. The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. Basic Auth is one of the most supported features of HTTP, supported even by Mosaic. Th…

> There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating

Fortunately, that Chrome version is dead in the water (unlike Chrome 49, which is the last version for XP and Vista)

Re: Using HTTP Basic Auth in 2022

#34

Post by jeofken »

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.

Implementing magic email sign in links is more straightforward and secure.

You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret=. This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every time you require auth

Re: Using HTTP Basic Auth in 2022

#35

Post by smasher164 »

I found that sites (like fb messenger) which block URLs to certain sites can be easily bypassed by using HTTP Basic Auth with empty credentials. I built a small service (https://rot13.akhil.cc) that takes in a rot 13'd URL and redirects it to the original with HTTP Basic Auth. The nice part is that the credentials are cached, so visiting it again won't show the dialog.

Re: Using HTTP Basic Auth in 2022

#36

Post by usrbinbash »

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…

>This has many flaws that make it impractical

Just because something is simple doesn't make it impractical. Not every application requires a complex auth-flow.

>As every request is a login request, effectively

This is the case with basically every single Authentication flow in existence...at the end of the day, no matter how and where credentials are verified, there is a token that has to be sent with every request and verified server side.

>hard to easily build account recovery flows

Why?

> UX of logging in/out is browser-dependent and confusing for users

Its a display with username/password and one or 2 buttons, one of which says "Login", the other of which says "Cancel" or something similar. How is this confusing?

> it can't integrate well with other auth systems

Why?

Re: Using HTTP Basic Auth in 2022

#37

Post by throwawayboise »

mrweasel wrote: post #6
ithkuil wrote: post #2

How do you logout?

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.

Re: Using HTTP Basic Auth in 2022

#38

Post by usrbinbash »

Operyl wrote: post #28
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…

> And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse. Not true. Once you get authenticated you can store that in a cookie with expiration, or any number of other ways to reduce load on auth services.

1. You could do the same in a BasicAuth system.

2. How is validating the session-cookie validity different from validating the username/password?

Re: Using HTTP Basic Auth in 2022

#39

Post by manigandham »

Operyl wrote: post #28
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…

> And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse. Not true. Once you get authenticated you can store that in a cookie with expiration, or any number of other ways to reduce load on auth services.

That's exactly the same with HTTP Basic Auth. Set the cookie and skip checking the credentials.

Another user even mentions doing exactly this: https://news.ycombinator.com/item?id=29762073

Re: Using HTTP Basic Auth in 2022

#40

Post by Denvercoder9 »

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).
Post reply on HN