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

191–200 of 345 posts

Re: Using HTTP Basic Auth in 2022

#191

Post by mooreds »

Waterluvian wrote: post #24

Something I’m practicing more often is to keep something dead simple and then later adopt a library or some higher abstraction when necessary. For example, just handling a websocket myself before later using some sort of library for it. In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about…

Reminds me of this: https://adamdrake.com/command-line-tools-can-be-235x-faster-...

Re: Using HTTP Basic Auth in 2022

#192

Post by ClumsyPilot »

vbezhenar wrote: post #71
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.

"you need to add links to registration, password recovery and so on"

All of which could be easilly standardized

Re: Using HTTP Basic Auth in 2022

#193

Post by mooreds »

diarrhea wrote: post #140
zinekeller wrote: post #33

Earlier quoted context omitted.

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

Agreed. My sympathies that the GP even needs to know this.

Re: Using HTTP Basic Auth in 2022

#194

Post by staticassertion »

wswope wrote: post #188
staticassertion wrote: post #176

Earlier quoted context omitted.

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?

You are correct. I (and I think most people?) consider that to be the most common attacker scenario.

Re: Using HTTP Basic Auth in 2022

#195

Post by madacol »

gjsman-1000 wrote: post #150
indymike wrote: post #138

Earlier quoted context omitted.

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

I don't dispute the technology exists - I dispute that this technology can be deployed on a web app to general users effectively. I don't believe that is currently possible in production effectively in a way that neutralizes my arguments that an attacker could just change the JavaScript to record passwords somewhere.

That's why the browser's built-in login Form could be so useful, it would have its own security context, so I, as a user can be sure that no Javascript could read that

I would happily sign up and reuse a password for a website that I didn't trust if it were as secure as described (PAKE + browser built-in login)

Re: Using HTTP Basic Auth in 2022

#196

Post by gitgrump »

staticassertion wrote: post #131
gjsman-1000 wrote: post #126

Earlier quoted context omitted.

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

No post body was provided.

Re: Using HTTP Basic Auth in 2022

#197

Post by LinAGKar »

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…

Digest auth is fundamentally less secure, as it requires the server to have access to the plain text password, whereas with basic auth you can store it salted and hashed. And you should be using HTTPS regardless.

Re: Using HTTP Basic Auth in 2022

#198

Post by lgvld »

LAC-Tech wrote: post #76
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!

Yeah caddy is such an awesome server! ;-)

Re: Using HTTP Basic Auth in 2022

#199

Post by LinAGKar »

StefanKarpinski wrote: post #72
slim wrote: post #55

Earlier quoted context omitted.

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.

>The password is still revealed to the server.

And with digest auth, the server must have the plain text password already. But sure, maybe there is a third option.

Re: Using HTTP Basic Auth in 2022

#200

Post by madacol »

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.

So you are strawmanning?
Post reply on HN