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

291–300 of 345 posts

Re: Using HTTP Basic Auth in 2022

#291

Post by Too »

huntertwo wrote: post #221
staticassertion wrote: post #162

Earlier quoted context omitted.

Plenty of very simple web apps terminate TLS at the edge ie: at something like API Gateway. So if you then turn on request logging... voila. Hardly a complex scenario, happens all the time. Or at the application layer: @path("/login") def login(request): print("I have a bug, I'll just log the whole request real quick to see wtf is up!", request) It's actually very hard to ensure that the password doesn't get logged.…

If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.

The hash is not constant.

With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key.

Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.

Re: Using HTTP Basic Auth in 2022

#292

Post by Too »

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…

bcrypt solves that in two ways. It uses per password unique salts and it has a tunable cost-parameter to deliberately slow down the computation, making it slow and infeasible to build a rainbow table.

Re: Using HTTP Basic Auth in 2022

#293

Post by moltar »

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…

* password manager support

Re: Using HTTP Basic Auth in 2022

#294

Post by Too »

jacobsenscott wrote: post #261
gedy wrote: post #238

Earlier quoted context omitted.

Compiled languages had a harder time with this.

Even with interpreted languages - if your configuration is in code you still need to wait for a code review, wait for CI to pass, and wait for the deploy. It can easily take over an hour to do a simple configuration change.

Depends how you deploy it. Python can import a file located anywhere you want, either by changing PYTHONPATH or using importlib. And vice versa an xml-config file might be placed in the repo and going through code review.

Code review for config changes is a good practice in either case, see gitops and config as code.

Re: Using HTTP Basic Auth in 2022

#296

Post by staticassertion »

Too wrote: post #291
huntertwo wrote: post #221

Earlier quoted context omitted.

If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.

The hash is not constant. With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key. Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.

Yeah, once you get to the ZKP approach, which is what you're describing, the benefits are more significant.

Re: Using HTTP Basic Auth in 2022

#297

Post by lucb1e »

klodolph wrote: post #175
diarrhea wrote: post #154

Earlier quoted context omitted.

The parent commenter possibly meant: with an incoming request, sending a password in clear-text, how do you cache it? You hash it, then store the fact that authentication was valid with some expiry. Once the next request, again with clear-text password, comes in you need to look up its validity. You want to check without hashing , that's the entire point. If you look up whether the hash is validly cached, you gained…

> You want to check without hashing, that's the entire point. It's not the point. There is no attempt to avoid hashing. At this moment I'd like to be careful and distinguish between ordinary cryptographic hash functions (SHA-2, BLAKE2, etc) and key derivation functions (PBKDF2, Argon2, etc), even though both are often referred to as "hashing" in this context. The thing about key derivation functions is that they make…

> At this moment I'd like to be careful and distinguish between

between a technicality (that I'm not even sure I agree with, hashing is still hashing also if you do it a million times) and what the people you're replying to were talking about. Sure, if you ignore what the topic was above then you can indeed say that nobody was trying to avoid doing hashing.

Re: Using HTTP Basic Auth in 2022

#298

Post by lucb1e »

Denvercoder9 wrote: post #56
billpg wrote: post #45

Earlier quoted context omitted.

The server will have a clear-text (leaving the base64 to one side) password in the HTTP request and a PBKDF2 (or similar) token loaded from the user database. Unless you store the user's password in the clear inside your user database, but will have other security issues.

Ok, but if you handle that in the app, it doesn't get invoked for CSS/JS/images/etc requests.

I don't know how you got to this being used for an app, but in most cases users will just be using a normal web browser and they will be requesting those resources (perhaps with etag/if-modified-since) on each request.

Re: Using HTTP Basic Auth in 2022

#299

Post by lucb1e »

ChicagoDave wrote: post #286

The primary flaw isn't BASIC AUTH. It's the password itself. Brute force attacks are easy. The only good way of securing anything is through an Authenticator app.

You can still have the server trigger an authentication confirmation when using basic auth. Web servers not coming with authentication apps is not a flaw, it is a completely separate component and scope.

Re: Using HTTP Basic Auth in 2022

#300

Post by thesz »

eru wrote: post #288
Thorrez wrote: post #275

Earlier quoted context omitted.

Good point that it protects against a phishing site that exactly replicates the victim site but with a different URL. But the phishers could do a slight variation. They could create a website that looks very similar to the browser's Basic Auth popup, but implemented in HTML and Javascript. Most people won't notice the difference. Most people don't understand the line of death[1]. [1] https://textslashplain.com/2017/0…

You could make the line of death better. In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed? I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.

This is what was done in the EROS [1] (extremely reliable operating system) UIs - it was not possible for user window to be rendered completely undistinguishable from system windows like, you knew it, a password prompt.

[1] https://en.wikipedia.org/wiki/EROS_(microkernel)

EROS used capabilities to enforce such rules. If you lack a capability to be a system window, you can't pretend to be one.

Post reply on HN