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

71–80 of 345 posts

Re: Using HTTP Basic Auth in 2022

#71

Post by vbezhenar »

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…

I don't really see it simplifying a lot of internet. Everyone will make his custom login page anyway, you need to add links to registration, password recovery and so on. And sending password on every request, hashed or not, is just bad security, you need session token anyway.

Re: Using HTTP Basic Auth in 2022

#72

Post by StefanKarpinski »

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

The password is still revealed to the server. There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere.

Re: Using HTTP Basic Auth in 2022

#73

Post by marcosdumay »

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?

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

Validating codes is done with fast crypto algorithms, while validating passwords uses purposefully slow algorithms.

Re: Using HTTP Basic Auth in 2022

#74

Post by axiosgunnar »

lukevp wrote: post #65
slim wrote: post #55

Earlier quoted context omitted.

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…

Your suggestion is vulnerable to the https://en.m.wikipedia.org/wiki/Pass_the_hash attack.

Your suggestion is basically going back to the days where databases stored plaintext passwords in the database, just that the plaintext happens to be a hash.

Re: Using HTTP Basic Auth in 2022

#75

Post by adamzochowski »

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…

One of my favourite auth is the NTLM/SSPI which came out of the the windows NTLM world.

Users don't even see they are being asked to be authenticated, they are either logged in, or told they don't have access.

Works great in corporate world.

Re: Using HTTP Basic Auth in 2022

#76

Post by LAC-Tech »

mholt wrote: post #61

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: ht…

happy new year. Caddy is such a great piece of software. It has great defaults 'out of the box' but at the same time doesn't feel like I'm drowning in incomprehensible magic. We need more software like this!

Re: Using HTTP Basic Auth in 2022

#77

Post by throwaway984393 »

Spend an hour to set up an OAuth2 Proxy (https://oauth2-proxy.github.io/oauth2-proxy/) instead.

You can use the one proxy for entire subdomains / unlimited number of apps. No plaintext passwords, scales well, open source, industry standard, and you get SSO for free. Hell, you don't even have to manage accounts! It makes your life simpler and it's more secure. You can't say that often.

Re: Using HTTP Basic Auth in 2022

#78

Post by lixtra »

lukevp wrote: post #65
slim wrote: post #55

Earlier quoted context omitted.

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…

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

Shouldn’t it be a proper challenge/response? Otherwise the hash is barely better than the password.

Re: Using HTTP Basic Auth in 2022

#79

Post by tdeck »

smasher164 wrote: post #35

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.

That's really clever!

Re: Using HTTP Basic Auth in 2022

#80

Post by hasel »

mholt wrote: post #61

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: ht…

Is this supposed to be used to put entire domains behind basic auth or should you use it for specific end points?
Post reply on HN