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.
Using HTTP Basic Auth in 2022
11–20 of 345 posts
Re: Using HTTP Basic Auth in 2022
#12I 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-domain (with proper rewrites added to apache/nginx) prevents numerous HTTP basic auth requests so authentication is required just once after the browser has been restarted.
Re: Using HTTP Basic Auth in 2022
#13This 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 a password on every request requires care to avoid accidentally logging passwords
- Every request needs to do password validation, presenting additional load on the authentication systems/datastores
Re: Using HTTP Basic Auth in 2022
#14How do you logout?
Last time I used HTTP basic auth, we've had a page which would unconditionally send 401 error code -- it'd invalidate credentials cache (effectively logging out the user) and then pop up new credentials dialog. I am not sure how standard-complaint this was, but it seemed to work in most browsers.
One downside is that in trivial implementation (/logout page returning 401), you'll end up with credential prompt where no credentials work, and this can be pretty confusing if someone leaves the compute in that state. I think it can be worked around with "expiration" URL parameter or a cookie, but this is somewhat finicky to setup.
Re: Using HTTP Basic Auth in 2022
#15I 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 thing; really nice for those things you just can’t put behind a VPN for one reason or another.
Re: Using HTTP Basic Auth in 2022
#16This 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.
Author mentions internal tools, so I assume they already have a user database they integrate with on the back-end? LDAP or similar.
Re: Using HTTP Basic Auth in 2022
#17This 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.
But still, why reinvent the wheel? There are plenty of libraries, even services available that do what you want.
Re: Using HTTP Basic Auth in 2022
#18This 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…
Probably true. I’m not suggesting it for your enterprise project. I’m just trying to remove personal roadblocks so I can test an MVP before I invest too much development time.
Re: Using HTTP Basic Auth in 2022
#19This is great for small projects and services that have just a few users and an easy way to change passwords and create/delete accounts directly in the backend. It’s secure (although you must use HTTPS) and is very easy and fast to use, especially if you have a password manager that automatically fills out the login form.
Re: Using HTTP Basic Auth in 2022
#20How do you logout?
Great question. This is a downside, there is no built-in method, but there are some tricks. If I remember correctly you can send headers with incorrect credentials. I’ll have to do some research and add that to my template.
If I remember this correctly, you send a request with incorrect credentials either via javascript, or by sending the user to a "/logout"-endpoint where you disallow any authentication credentials, causing the browser to prompt the user for a new username and password. This not great in terms of UX and depending on something implicit for something as important as logging out does not seem great for security.
Why browsers do not have better functionality built in for authentication is something that's always been a bit baffling...