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

61–70 of 345 posts

Re: Using HTTP Basic Auth in 2022

#61

Post by mholt »

Caddy comes with basic auth support because it's still useful for a lot of use cases.

IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: https://caddyserver.com/docs/modules/http.authentication.pro...

Of course, password hashes are slow, so KDF'ing a plaintext string at every HTTP request can grind even powerful servers to a halt. So Caddy can optionally cache hash results in memory (we do expect memory to be safer than a config file -- and Go is a memory-safe language in this regard). And while this can introduce nuanced timing variances (fast if recently hashed), they do not necessarily correspond to correct passwords.

If you think this stuff is interesting and want to help make Caddy's basic auth even better, feel free to contribute or sponsor: https://github.com/caddyserver/caddy

Re: Using HTTP Basic Auth in 2022

#62

Post by nichochar »

I love simplicity.

the reasons you provide for using it are really strong, and I think it's a much superior option to prototyping leveraging oauth 3rd parties (which has tons of downsides).

It would be good to have a hard rule as to when you migrate, and what the reasons are (if a project has more than N users, if you store field X which is pretty sensitive, etc..)

Re: Using HTTP Basic Auth in 2022

#63

Post by xnaas »

kogir wrote: post #46

My big problem with HTTP basic auth in 2022 (squints at Netgear router) is that in Edge/Chrome 1Password can’t auto complete it. It gets really annoying really quickly.

Bitwarden has 0 issues 'autofilling' basic auth. It just passes the login credentials on connection and you never see a basic auth prompt.

Re: Using HTTP Basic Auth in 2022

#64

Post by jerf »

usrbinbash wrote: post #38
Operyl wrote: post #28

Earlier quoted context omitted.

> 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?

For 2, in many cases validating username/password requires hitting an external system. If you want to give your IT department a fun day, write a moderately popular internal web service that accidentally hits LDAP freshly for every single web request. It's really easy to accidentally do in some environments. Session cookie validation will typically only involve local resources.

For many of my internal tools I don't even bother with a database and just store it in local RAM, especially when I have no other database involvement, because having all sessions reset every few months during a reboot or restart is worth it to not have to stand up a database solely for that purpose. In that case it's just a quick lock&lookup in a map/dict/whatever your language favors to see if the token matches or not.

Re: Using HTTP Basic Auth in 2022

#65

Post by lukevp »

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

Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert issuance and installing their own root CA is easily doable). Another issue is that improper logging on the server (or depending on the implementation, even intermediate load balancers) could accidentally leak the plaintext password. Client side hashing is a much better solution to this, and if it’s a native browser supported protocol, it would even work without JS.

Re: Using HTTP Basic Auth in 2022

#67

Post by gjsman-1000 »

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."

If you are using HTTPS, you are equally as good as any other login form.

Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies somewhere. You are reliant on the server being a source of truth either way.

Re: Using HTTP Basic Auth in 2022

#68

Post by VTimofeenko »

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…

Technically as far as I understand the client side certificates and signing/revoking them through internal CA solve the same problems.

However I have yet to encounter such setup used in a professional environment for humans. Is the complexity of such approach just too high compared to LDAP and the passwords?

Re: Using HTTP Basic Auth in 2022

#69

Post by rmbyrro »

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…

Maybe combining Lambda integration with CloudFront (CF)?

You could intercept every HTTP request before it reaches CF, check auth data and decide to let it through or respond with 401 already. The CF auth password could be kept as an internal secret. You rotate temporary passwords on Lambda environment variables (bit insecure) or using AWS Secrets Manager (very safe).

Requests successfully authenticated on Lambda level gets rewritten with the master CF password to make them succeed there.

It's a lot more trouble than simply setting up basic auth, but you setup only once and theoretically it works.

Re: Using HTTP Basic Auth in 2022

#70

Post by [deleted] »

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.

[deleted]
Post reply on HN