21–30 of 345 posts
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 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…
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 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.
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. 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, but that's the only exception I know.
For example, just handling a websocket myself before later using some sort of library for it.
In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about how I’ll evolve and grow without the answer being “just preemptively grow it so you don’t have to think about it.”
And naturally I’m discovering that the basic tools go far further than I expect and sometimes I never need to pay for that abstraction at all.
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.
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 is actually exactly how I use it: HTTP Auth is the first step to get in, then set a cookie which bypasses HTTP Auth in future sessions.
Effectively, it is a captcha.
Something I’m practicing more often is to keep something dead simple and then later adopt a library or some higher abstraction when necessary. For example, just handling a websocket myself before later using some sort of library for it. In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about…
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…
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.
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.
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 thing; really nice for those things you just can’t put behind a VPN for one reason or another.