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

271–280 of 345 posts

Re: Using HTTP Basic Auth in 2022

#271

Post by gsich »

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.

Because pass the hash only works for the current server. People reuse passwords, so without brute-forcing you are out of luck.

Re: Using HTTP Basic Auth in 2022

#272

Post by spiffytech »

IggleSniggle wrote: post #243
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…

I’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps? Not trying to be intentionally dense, genuine confusion/question.

If an attacker compromises your stored plaintext passwords, they can test those username+password pairs against other online services, since lots of users reuse passwords. If you store hashes instead of the actual passwords, the attacker doesn't get the user's credentials.

You have to use hash functions appropriate for passwords (like bcrypt; don't use hashes like sha256 for this). And if you hashed correctly, it's still practical for an attacker to brute-force simple/common passwords. But at least users with hard-to-guess passwords get protected from your breach facilitating credential stuffing attacks.

Re: Using HTTP Basic Auth in 2022

#273

Post by santa_boy »

kij wrote: post #165

I am very happy with the this caddy extension: https://github.com/greenpau/caddy-auth-portal . Sorts this precise use case for me, need for common login provider. Without the banality of basic auth.

thank you! this gave me an idea to look for something similar for nginx ... https://github.com/vouch/vouch-proxy

lots of my issues on authentication for various apps can perhaps be handled now!

Re: Using HTTP Basic Auth in 2022

#274

Post by rixed »

w3ll_w3ll_w3ll wrote: post #145
gjsman-1000 wrote: post #110

Earlier quoted context omitted.

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.

> You have to know the private key and do MITM.

Which can safely be assumed to happen whenever the equipment is provided by another party such as an employer. All in the name of security, just not that of the user.

Re: Using HTTP Basic Auth in 2022

#275

Post by Thorrez »

amluto wrote: post #263
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…

PAKE is highly phishing resistant. If you type your password for an important website into a browser-controlled PAKE UI, but you’re being phished and the browser tries to authenticate to a malicious website, the worst the website can do is guess one single password. It can’t relay the password to the real website.

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/01/14/the-line-of-death/

Re: Using HTTP Basic Auth in 2022

#277

Post by joelbondurant »

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…

No post body was provided.

Re: Using HTTP Basic Auth in 2022

#279

Post by eyelidlessness »

nvllsvm wrote: post #246
IggleSniggle wrote: post #243

Earlier quoted context omitted.

I’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps? Not trying to be intentionally dense, genuine confusion/question.

It's essentially impossible to reverse the hashed password. This is particularly helpful for users who reuse the same password for everything online.

> It's essentially impossible to reverse the hashed password.

It’s essentially a nontrivial unit of work to brute force the hash (or exploit collisions for a compromised hashing algo). That’s not impossible but it’s important not to overstate its safety too.

Post reply on HN