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

101–110 of 345 posts

Re: Using HTTP Basic Auth in 2022

#101

Post by makeworld »

hasel wrote: post #80
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?

It can be used for either. Depends what you'd like to do. Maybe the domain is admin.mysite.com and so you want to wall the whole thing off. I've used it for specific endpoints as well though, like to protect certain folders of a file server.

Re: Using HTTP Basic Auth in 2022

#102

Post by mholt »

hasel wrote: post #80
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?

You can do either. To Caddy, "entire domain" or "specific endpoints" are all the same thanks to request matchers. You can precisely customize which requests have basic auth applied to them: https://caddyserver.com/docs/caddyfile/matchers

Re: Using HTTP Basic Auth in 2022

#103

Post by weaksauce »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

I could be missing something but they are not suggesting to use a javascript version but the version where the zero knowledge algorithm is used at the browser level. the password would never be outside the secure context of the browser and nothing other than the algorithm bits would be sent.

Re: Using HTTP Basic Auth in 2022

#104

Post by fivelessminutes »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

If someone gets a copy of the encrypted traffic - and we know that 'full take' is being done routinely for some parts of the internet - the credential in the plaintext means that if they are ever able to decrypt it even weeks later, they can make fresh connections using the valid credential afterwards.

If the server issues a different challenge each time, decrypting one response doesn't buy you anything.

Re: Using HTTP Basic Auth in 2022

#105

Post by throw0101a »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

> If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection.

If a zero knowledge (ZK) system combined with HTTP Basic was used, then account entry would come from the browser itself and not a web form that could be intercepted by JavaScript.

Further, a ZK system would help with the silliness of folks using bad algorithms (straight MD-5 / SHA-1) to store passwords, or even storing them in plain-text.

Re: Using HTTP Basic Auth in 2022

#106

Post by znpy »

nuccy wrote: post #30
showerst wrote: post #15

Earlier quoted context omitted.

I do the same thing; really nice for those things you just can’t put behind a VPN for one reason or another.

A nice alternative to VPN (especially when you don't have a root to set it up) is using ssh tunnels: ssh user@server -D 1234 and Firefox with socks proxy set to 127.0.0.1:1234 (e.g. using Foxyproxy addon, though possible without it via the Firefox network settings). Then all Firefox trafic is exiting on the server side (including DNS requests).

> including DNS requests

Don't be sure about that!

There's an additional setting to check to be sure dns goes through the proxy.

Can't recall the details now, but it's there!

Or maybe it was due to dns over tls not being proxied?

Re: Using HTTP Basic Auth in 2022

#107

Post by gjsman-1000 »

almost wrote: post #95
gjsman-1000 wrote: post #91

Earlier quoted context omitted.

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password. But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.

I hope you are kidding.

A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.

And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.

Re: Using HTTP Basic Auth in 2022

#108

Post by oconnore »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

- If you share your password across sites that used a hypothetical browser-implemented PAKE, site A cannot login to your account on site-B

- If a site is attacked, there is no risk that password material was extracted from application memory — site operator can dump session tokens and safely re-auth users.

Re: Using HTTP Basic Auth in 2022

#109

Post by ufmace »

I like the reminder that this is out there and mostly available.

I think many of the comments here are missing the point - they're saying it's useful for small-time projects with one or a few users and not needing to be integrated into a sophisticated infrastructure. No need to worry too much about hashing, logouts, the full chain of account management, etc. Use a full-featured solution if you need that, keep Basic Auth for a thing with a few admin pages where anything unusual gets handled over SSH.

This also reminds me - Gemini uses client certs for a similar purpose. Gemini doesn't seem to have much going on, but it does make a good case for using client certs better. Right now, they're technically supported, but the UI for both browsers and server support is really clunky. Build a decent UI on both sides, and it could be a nice simple solution for higher-security authentication.

Re: Using HTTP Basic Auth in 2022

#110

Post by gjsman-1000 »

fivelessminutes wrote: post #104
gjsman-1000 wrote: post #91

Earlier quoted context omitted.

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

If someone gets a copy of the encrypted traffic - and we know that 'full take' is being done routinely for some parts of the internet - the credential in the plaintext means that if they are ever able to decrypt it even weeks later, they can make fresh connections using the valid credential afterwards. If the server issues a different challenge each time, decrypting one response doesn't buy you anything.

I guess this makes sense - but who is capable of decrypting it weeks later unless the original private key was stolen, in which case it could be decrypted almost in real-time? Maybe if you were concerned a nation-state or something was trying to get your private key, but you've got bigger fish to fry at that point.
Post reply on HN