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

141–150 of 345 posts

Re: Using HTTP Basic Auth in 2022

#141

Post by diarrhea »

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…

Embracing security through obscurity like that is also how I decided to help protect my password manager, Vaultwarden. It's open to the internet on 80/443, but its URL is `subdomain.domain.tld/some-secret-path/`. It's dead simple, but indeed no unwanted visitors even see that site. Of course, even if they did, the regular login prompt with MFA appears.

Re: Using HTTP Basic Auth in 2022

#142

Post by usrbinbash »

freedomben wrote: post #90
usrbinbash wrote: post #38

Earlier quoted context omitted.

1. You could do the same in a BasicAuth system. 2. How is validating the session-cookie validity different from validating the username/password?

A non-trivial difference is that to validate password you need to run it through bcrypt or similar algorithm which is intentionally slow. With a token or cookie, you can use a regular fast hashing algorithm.

Nothing prevents me from using BaseAuth for the login, and then issuing a session cookie to the user.

Re: Using HTTP Basic Auth in 2022

#144

Post by emj »

tunesmith wrote: post #133

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

The GDPR/Cookie rules are just the same common courtesy that all projects I've been invovled with always has had. No ad trackers and no personal data stored about what I did on the site unless necessary for the function provided. There is no exemption for personal sites. Point being, I'm from the EU but some times that has not always been important and only come up after working with someone online a couple of years.

Basically; HTTP Basic auth does not make you website anymore private than a login page. Just treat you users fair and be straight forward with what you do with the data, and you won't need any lawyers.

Re: Using HTTP Basic Auth in 2022

#145

Post by w3ll_w3ll_w3ll »

gjsman-1000 wrote: post #110
fivelessminutes wrote: post #104

Earlier quoted context omitted.

If someone gets a copy of the encrypted traffic - and we know that 'full take' is being done routinely for some parts of the internet - the credential in the plaintext means that if they are ever able to decrypt it even weeks later, they can make fresh connections using the valid credential afterwards. If the server issues a different challenge each time, decrypting one response doesn't buy you anything.

I guess this makes sense - but who is capable of decrypting it weeks later unless the original private key was stolen, in which case it could be decrypted almost in real-time? Maybe if you were concerned a nation-state or something was trying to get your private key, but you've got bigger fish to fry at that point.

Also, using TLS with Perfect Forward Secrecy (all modern ciphers), it's not possible to just capture the traffic and dectypt it later. You have to know the private key and do MITM.

Re: Using HTTP Basic Auth in 2022

#146

Post by scoopertrooper »

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.

Not theoretical, you can do it today.

https://www.npmjs.com/package/libopaque

Re: Using HTTP Basic Auth in 2022

#147

Post by gjsman-1000 »

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

How complex and unusual is the authentication system you are working on?

If it was a consumer-facing web app, it's not like your password is logged in a million different places. It's possibly logged by your web server software (nginx in my case), and it's possibly logged by your web app framework's requests handler. It's not terribly hard to ensure that these points where the password passes through do not have passwords in their logs, or to ensure that said passwords are not logged to begin with.

If it was a massive enterprise system, I would hope that you would use a single-sign-on system with a centralized login page rather than exposing passwords to every web app within it. And then, just ensure that said passwords are not stored in logs. This is what I meant by clean logs - anywhere the password is used, ensure there is no record. How much code and how many layers does a password need to go through?

And yes, maybe client-side hashing does resolve some attacks, but I remain convinced that it is overkill and less protective than it initially seems. And in the future we would move to Zero-Knowledge Proofs but we aren't there yet for general users.

Re: Using HTTP Basic Auth in 2022

#148

Post by Waterluvian »

smitty1e wrote: post #122
Waterluvian wrote: post #84

Earlier quoted context omitted.

After years and years of production experience with thousands of mobile robots that use this weird xml + yaml as configuration, I am 100% in the “just use code as configuration” camp.

I put stuff in config.py Then I just `import` at will. The need for a separate configuration format was what, again?

My probably wrong belief is that it was a misguided but noble idea of abstracting complexity.

Re: Using HTTP Basic Auth in 2022

#149

Post by gjsman-1000 »

staticassertion wrote: post #134
gjsman-1000 wrote: post #132

Earlier quoted context omitted.

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.

I meant, let's say I picked a framework. Django, Laravel, Express, similar.

How would I implement PAKE login for my users? How would I get every user to log in with PAKE? How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server?

It doesn't exist, AFAIK, on a user-facing front at this time in a secure way that a hacker couldn't just change the logic for.

Re: Using HTTP Basic Auth in 2022

#150

Post by gjsman-1000 »

indymike wrote: post #138
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.

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.
Post reply on HN