Using HTTP Basic Auth in 2022 • Hacker News Board

Re: Using HTTP Basic Auth in 2022

#111

Post by michaelcampbell » Sat, Jan 01, 2022, 8:59 PM UTC

oconnore wrote: post #83

gjsman-1000 wrote: post #67

Earlier quoted context omitted.

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

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…

> No, it would be much better to use a zero knowledge proof

Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.

Re: Using HTTP Basic Auth in 2022

#112

Post by ChrisMarshallNY » Sat, Jan 01, 2022, 8:59 PM UTC

I just use it once, to generate an API key, then use the key, and a server secret (in the basic auth header), after that. The key could be generated by something like Sign In With Apple.

Not Fort Knox, but fairly good.

Because of FastCGI, I have to have an option to pass login creds in the URL, but that is not by default.

Re: Using HTTP Basic Auth in 2022

#113

Post by na85 » Sat, Jan 01, 2022, 8:59 PM UTC

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…

>Yes - it does - but I am having a hard time thinking that this actually matters in the real world.

In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants.

For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes.

Often the salt would be common across all passwords, so if you got a database dump it was a gold mine for credentials.

Re: Using HTTP Basic Auth in 2022

#114

Post by loevborg » Sat, Jan 01, 2022, 8:59 PM UTC

mckmk wrote: post #50

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…

Google Cloud offers Identity Aware Proxy and AWS offers Cognito integration with their Application Load Balancers which can do this.

That's helpful thanks. Googling "CloudFront cognito" gives me a bunch of interesting links:

https://awslabs.github.io/aws-cloudfront-extensions/deploy/d...

https://aws.amazon.com/blogs/security/protect-public-clients...

Re: Using HTTP Basic Auth in 2022

#115

Post by gjsman-1000 » Sat, Jan 01, 2022, 9:02 PM UTC

oconnore wrote: post #108

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

This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.

Re: Using HTTP Basic Auth in 2022

#116

Post by gjsman-1000 » Sat, Jan 01, 2022, 9:03 PM UTC

na85 wrote: post #113

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…

>Yes - it does - but I am having a hard time thinking that this actually matters in the real world. In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants. For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes. Often the salt…

Right - but that's been resolved, PHP and others now store the unique salt used with the password together, so every password has its own salt.

That didn't need client-side hashing to fix it.

Re: Using HTTP Basic Auth in 2022

#117

Post by watermelon0 » Sat, Jan 01, 2022, 9:04 PM UTC

xnaas wrote: post #63

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.

It only supports a single user/pass pair for each site. There are many cases where you would want to use multiple identifies and switch between them.

Re: Using HTTP Basic Auth in 2022

#118

Post by staticassertion » Sat, Jan 01, 2022, 9:04 PM UTC

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…

> Accidental logging?

Yes, it happens all the time that passwords get logged.

> I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript.

I have no idea what "set up your logs correctly" is supposed to mean but clearly no one's doing it. What is a "clean log" ?

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

This assumes you have full control over the client page. But that's not necessarily (or often? most people don't serve JS from the same code that serves their auth API) the case.

1. The JS could be loaded from a CDN, not the same service that has access to the password. You may have absolutely no control over the JS on the page.

2. Every point between the browser and the password DB is a point where the password is in cleartext. So a compromise of any of those, including any logging paths, is a compromise of the password.

3. I don't think anyone cares about breaking login for users who don't use JS, nor should they.

What's more, ZKP means that if your password database is owned the impact is far less. If you're doing things right for password storage on top of ZKP you can practically make your password db public.

Even if we're talking about a basic client side hashing approach you're significantly improving security, but to be clear, the parent poster is talking about ZKPs, which involve more than that.

Re: Using HTTP Basic Auth in 2022

#119

Post by staticassertion » Sat, Jan 01, 2022, 9:05 PM UTC

gjsman-1000 wrote: post #115

oconnore wrote: post #108

Earlier quoted context omitted.

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

This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.

PAKE isn't theoretical at all and the post you're responding to didn't say client side hashing it said zero knowledge proofs.

Re: Using HTTP Basic Auth in 2022

#120

Post by smitty1e » Sat, Jan 01, 2022, 9:06 PM UTC

One non-technical advantage is prototyping.

Going this route says to the consulting client: this is NOT the full solution. This is only work-in-progress. If you treat this as the final delivery and deploy this to prod, you're making a big mistake.

Not that I've ever seen that happen, mind you.