Using HTTP Basic Auth in 2022 • Hacker News Board

Re: Using HTTP Basic Auth in 2022

#131

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

gjsman-1000 wrote: post #126

staticassertion wrote: post #118

Earlier quoted context omitted.

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

> "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"?" As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail.

Sorry, but the idea that implementing "clean logs" is:

a) Tractable

b) Simple or straightforward

compared to client side hashing is absurd.

Client side hashing is a one time solution forever that exists in one place, requiring no 'cooperation' from other code to be safe. "Cleaning logs", which you still haven't defined at all, is going to be a constant maintenance burden that can break in any place where you log ie: absolutely fucking everywhere by absolutely fucking everyone.

Re: Using HTTP Basic Auth in 2022

#132

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

staticassertion wrote: post #119

gjsman-1000 wrote: post #115

Earlier quoted context omitted.

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.

PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now.

Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.

Re: Using HTTP Basic Auth in 2022

#133

Post by tunesmith » Sat, Jan 01, 2022, 9:16 PM UTC

I don't know if it really holds up to scrutiny, but I use http basic auth for a semi-public website. It has members (like less than twenty) that I don't know personally other than through the website, but I don't want the website public because I don't want to deal with with TOC, GDPR, legal stuff in general. Once you're past basic auth, it actually does have a login/registration flow, but it seems like I'd need to see a lawyer if I ever wanted to make a member-driven website public and I just haven't gotten around to it yet, so... http basic auth. Is this sound thinking? I don't know.

Re: Using HTTP Basic Auth in 2022

#134

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

gjsman-1000 wrote: post #132

staticassertion wrote: post #119

Earlier quoted context omitted.

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

PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now. Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaSc…

Not sure what you mean.

1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ?

> I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.

Even a trivially implemented client side hashing approach protects against a number of attacks.

Re: Using HTTP Basic Auth in 2022

#135

Post by masklinn » Sat, Jan 01, 2022, 9:19 PM UTC

gjsman-1000 wrote: post #107

almost wrote: post #95

Earlier quoted context omitted.

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…

> A compromised website that was well designed

Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it?

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

That makes quite literally no sense, did you miss the entire thing and go off with whatever?

The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.

Re: Using HTTP Basic Auth in 2022

#136

Post by masklinn » Sat, Jan 01, 2022, 9:20 PM UTC

weaksauce wrote: post #103

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…

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.

You're not missing anything, GP is.

Re: Using HTTP Basic Auth in 2022

#137

Post by masklinn » Sat, Jan 01, 2022, 9:21 PM UTC

gjsman-1000 wrote: post #130

throw0101a wrote: post #105

Earlier quoted context omitted.

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

Right - it would, I don't disagree, it'd be awesome. It's something like WebAuthn. I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea.

> I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea.

So you're arguing against something nobody is arguing for?

Re: Using HTTP Basic Auth in 2022

#138

Post by indymike » Sat, Jan 01, 2022, 9:22 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.

The first implementation was Bellovin and Merritt's Encrypted Key Exchange in 1992. In 2000 a provably secure implementation was released. PAKE has been around for quite some time and is proven, and is in wide use in the field. Here's a decent article on the subject: https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

Re: Using HTTP Basic Auth in 2022

#139

Post by dllthomas » Sat, Jan 01, 2022, 9:23 PM UTC

gjsman-1000 wrote: post #67

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…

You've responded as if the bit you've quoted is advice to individual developers in the present context, but the topic of conversation was about extending browsers so that the standard login form would do this (... better than existing auth digest). If we did that and people were used to using the browser's built-in login dialog, and (as with https) we made it visible what security features were enabled, then a trivial server-side change wouldn't compromise user passwords.

Re: Using HTTP Basic Auth in 2022

#140

Post by diarrhea » Sat, Jan 01, 2022, 9:26 PM UTC

zinekeller wrote: post #33

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…

> There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating Fortunately, that Chrome version is dead in the water (unlike Chrome 49, which is the last version for XP and Vista)

> unlike Chrome 49, which is the last version for XP and Vista

Oh God.