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

301–310 of 345 posts

Re: Using HTTP Basic Auth in 2022

#301

Post by thisoneistheone »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

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

No post body was provided.

Re: Using HTTP Basic Auth in 2022

#302

Post by lolc »

peanut-walrus wrote: post #220
staticassertion wrote: post #131

Earlier quoted context omitted.

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

And how exactly would having the hash in the log versus having the password in the log be an improvement? If someone gets that hash it's exactly the same as having the password, as it is the hash that gets sent to your server in the http request. Edit: alright, I saw that you mentioned password reuse in another reply, fair enough, it does help against that.

Proper client-side hashing uses a nonce generated by the server. The transmitted hash is only valid in that session. Even if the nonce and the hashed product are logged, you can't reuse it, because the nonce will be different for your login attempt.

Re: Using HTTP Basic Auth in 2022

#303

Post by mholt »

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.

It means that if someone sees your config file, they can't log into your sites and impersonate users (unless they have a LOT of money/resources and can reverse secure hashes -- one account at a time). It makes attacks impractically expensive.

Re: Using HTTP Basic Auth in 2022

#304

Post by mholt »

eyelidlessness wrote: post #279
nvllsvm wrote: post #246

Earlier quoted context omitted.

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.

... for one account. It takes N times as many more resources to do that for N more accounts. The attacks are impractically expensive for most attackers.

Re: Using HTTP Basic Auth in 2022

#305

Post by cookiengineer »

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…

Imagine a HTTP Basic Auth workflow that has another "Token: ..." header that is based on TOTP. This would help make things so much better compared to what's the situation right now.

The stuff we see nowadays is mostly hacks that upgrade legacy systems with things like "the password is actually your-password#token" and "oh yeah, if you use # in your password, it crashes the server ... so don't do that".

Something like a standardized HTTP-based authentication workflow (Basic Auth + maybe parts of the Web AuthN spec) could make things so much easier in regards to maintainability. Then we could finally get rid of stupid workarounds like JWT which weren't designed for this purpose.

Re: Using HTTP Basic Auth in 2022

#306

Post by diarrhea »

pronoiac wrote: post #234
diarrhea wrote: post #141

Earlier quoted context omitted.

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.

Have you checked if the secret path leaks in referrers?

It doesn't seem so. Clicking a random link from inside the Vaultwarden webpage (which is never used anyway, in favor of the Bitwarden browser plugins) and following the requests in Firefox's Browser Console, no request has a Referer HTTP request header. Vaultwarden does not send the Referer header cross-origin:

https://github.com/dani-garcia/vaultwarden/blob/920371929bc8...

My home server uses Caddy and its JSON logs. These are incredibly easy to parse of course. Through the dynamic DNS solution I use (Docker image qmcgaw/ddns-updater), I have a list of all of my own IP addresses. Add to that others like my work's IPv4 block, and I get a collection of 'known', i.e. harmless IP addresses. Filtering these in a little pandas-based Python tool leaves all requests reaching the secret endpoint. Logs reach back around a week. Another tool 'enriches' each log entry with IP lookup info from ipinfo.io. Their free API tier is enough for my uses. That way, I can filter for request origin countries, hostnames, etc.

The entire pipeline is automated, but triggered manually on-demand. So far, no hits from unknown IPs to the endpoint!

Re: Using HTTP Basic Auth in 2022

#307

Post by ibic »

oconnore wrote: post #83
gjsman-1000 wrote: post #67

Earlier quoted context omitted.

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

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

I don't think this is a major concern here, many websites pass username and password in plain text and rely on https for security (Just take a look at HN's log in form). If I'm not wrong, J2EE's login is implemented using plaint text also for password.

Re: Using HTTP Basic Auth in 2022

#308

Post by andreareina »

nirui wrote: post #270
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…

Is there any chance to go even further than this? I'm imaging a public key based authentication scheme. The user submit their public key to the server first, then in the feature logins, server will generate a challenge for client to decrypt and respond. Of course the browser can apply some UX magic at the client end, for example displaying a pop window to allow user to select a public key for the authentication proce…

Isn't that basically client certificates?

Re: Using HTTP Basic Auth in 2022

#310

Post by cobbzilla »

merlinscholz wrote: post #161
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…

Please do not add logo customization. This will end with prompts asking you for your Apple and Microsoft passwords which are difficult to differentiate from official prompts (at least for end users).

What if the icons are NFTs with automated browser verification? I’m only half joking— could this actually be doable?
Post reply on HN