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

181–190 of 345 posts

Re: Using HTTP Basic Auth in 2022

#181

Post by mooreds »

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…

> Add a button to log out. Logout never really worked across browsers with basic auth.

In my experience, the way to logout is to close the browser. Is this standardized anywhere?

> Allow to inject a logo or a tiny bit of customization for branding. The default popup looks too ugly.

I think that this would be nice, but most anyone who wants customization will want to control everything, and wouldn't be a fit for the limits of basic auth.

> Improve the Digest auth to modern crypto standards. Stop passing plain passwords over the wire.

As others have mentioned, TLS helps with this, but I agree that it would be a good idea to hash it anyway.

Have you thought about submitting these improvements to chromium and firefox (as feature requests)?

Re: Using HTTP Basic Auth in 2022

#182

Post by notfed »

ncann wrote: post #81
lukevp wrote: post #65

Earlier quoted context omitted.

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…

How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?

There are answers to this. I asked myself this a few years ago, which led recursively to new tricky questions. I eventually solved the tree of the questions: I designed myself into a solution that I later realized was essentially an asymmetric PAKE (e.g., analogous to OPAQUE).

So, an attempt to solve your question eventually leads to using an asymetric PAKE. But, this is way, way more complex. You'd really have to squint your eyes to believe that the diminishing returns are worth it.

Re: Using HTTP Basic Auth in 2022

#183

Post by kevincox »

I have always wondered how feasible it would be to use the basic auth URL syntax for thinks like API tokens and email validation. Ideally these values would not be logged but if you want a user to click them they basically need to be in the URL. So either you don't log URLs or you need to redact all of these parameters. Most systems are smart enough to avoid logging passwords so if you could just use URLs like randomtoken@example.com/confirm-email. However it seems like browsers usually put up scary warnings and most email providers will consider this a spammy/scammy pattern.

Of course another problem here is that you just want it for one URL, whereas basic auth is usually preserved for the session.

Re: Using HTTP Basic Auth in 2022

#184

Post by tlrobinson »

justsomehnguy wrote: post #94
forgotmypw17 wrote: post #23

I use it as a captcha. 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. Th…

> 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. You don't even need the basic auth for that. Years ago I needed to expose my pfsense WebGUI on the default HTTPS, but I didn't want it to be so obvious, so I made a couple of HAProxy rules, which allowed me to open https://pfsense.tld/open-sesame to set a cookie, after whic…

Kind of like “port knocking” but for HTTP.

Re: Using HTTP Basic Auth in 2022

#185

Post by armchairhacker »

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…

idk if you even need a zero knowledge proof.

Server sends client a salt, client hashes the salt and password and sends back to server.

Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).

Re: Using HTTP Basic Auth in 2022

#186

Post by madacol »

fzzt wrote: post #171
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…

There's a lot more to that. A bank doesn't want the "back" button to work forever; they want to control the lifetime of your session, ideally on the server. Google wants to let you sign into multiple accounts on the same origin. Many others want to have seamless single sign-on across several of their web properties. Sometimes, you want the change of your password to invalidate other sessions (say, when recovering a c…

Maybe we don't want them to be able to do any of that

And I think you are missing the point, the goal it's not to standardize logins, it's about making impossible for servers to know my password, hence impossible passwords leaks

That would allow people to reuse strong passwords, and not need passwords managers, because that's what they are doing anyway!

Re: Using HTTP Basic Auth in 2022

#187

Post by xmprt »

armchairhacker wrote: post #185
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…

idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).

Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.

Re: Using HTTP Basic Auth in 2022

#188

Post by wswope »

staticassertion wrote: post #176
pests wrote: post #173

Earlier quoted context omitted.

What benefits would you get though? You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your link) would still let an attacker grab password_hash, craft a custom client, and send it as if the original client had hashed the plaintext_password to begin with. The attacker doesn't need to know plaintext_password, just the string you use to authenticate wi…

If the attacker only has access to the hash that hash is only usable for your website. If the user uses the same password for another site an attacker can not log into that other site using the hash. That's really the main benefit of this approach - it reduces the impact of password reuse.

If I’m understanding your argument correctly (I may not be) - implementing PAKE would only be helpful in a scenario where an attacker gets access to hashed passwords, but isn’t able to modify front-end code to directly intercept unhashed passwords, right?

Re: Using HTTP Basic Auth in 2022

#190

Post by mooreds »

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…

You can use API Gateway to delegate to any auth server that can generate JWTs. https://docs.aws.amazon.com/apigateway/latest/developerguide... has more details.
Post reply on HN