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

91–100 of 345 posts

Re: Using HTTP Basic Auth in 2022

#91

Post by gjsman-1000 »

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…

> "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 could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection.

It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript.

In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.

Re: Using HTTP Basic Auth in 2022

#92

Post by [deleted] »

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…

[deleted]

Re: Using HTTP Basic Auth in 2022

#93

Post by lukevp »

jeofken wrote: post #34
SavantIdiot wrote: post #10

Earlier quoted context omitted.

But if you are rolling your own auth, you still need to create the signup, change password, reset password, confirm account, delete account, etc. pages. What's one more? Given that a logon form is >5% of the total amount of work to roll auth, seems kinda pointless to use this.

Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret= . This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every…

So anyone who compromised the cookie can login as this user forever? There’s no expiration or revocation in this protocol. Once you layer on expiration, this is basically sending someone a link with a JWT in the get request. Or you can hit the DB to check a secret key that’s in the email, and if it has expired, but this is worse than JWT because it requires a DB to verify the identity, where JWTs can be verified without interaction with the issuing system .

Re: Using HTTP Basic Auth in 2022

#94

Post by justsomehnguy »

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 which I could open the default https://pfsense.tld/ just fine and see the WebGUI. Without the cookie there was just 404 for everyone.

It wasn't the best realisation (and some parts of webgui didn't like it) but it worked and allowed me to access it even on the smartphone.

Re: Using HTTP Basic Auth in 2022

#95

Post by almost »

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…

Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password.

But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.

Re: Using HTTP Basic Auth in 2022

#96

Post by devmunchies »

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`).

It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the same token generation infra for APIs too so its pretty dynamic.

I've basically moved away from JWTs in favor of this simpler approach.

[1]: (list of auth schemes) https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica... [2]: (Bearer auth spec) https://datatracker.ietf.org/doc/html/rfc6750

Re: Using HTTP Basic Auth in 2022

#97

Post by jeroenhd »

xnaas wrote: post #63
kogir wrote: post #46

My big problem with HTTP basic auth in 2022 (squints at Netgear router) is that in Edge/Chrome 1Password can’t auto complete it. It gets really annoying really quickly.

Bitwarden has 0 issues 'autofilling' basic auth. It just passes the login credentials on connection and you never see a basic auth prompt.

That's actually a gripe I have with Bitwarden, because you can't turn that feature off. If an attacker can take over a single endpoint, Bitwarden will happily send your credentials to an iframe from a malvertiser without ever telling you.

It's a fine feature and the WebExtension API won't let them solve basic auth in any other way, but it's a security risk in my opinion. I'd much rather see browsers provide an API to HTTP Basic auth prompts instead so the user can select an identity from the list if they've got a saved username/password combo that matches a given set of requirements.

Re: Using HTTP Basic Auth in 2022

#98

Post by mholt »

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!

Thanks for the kind words!

Re: Using HTTP Basic Auth in 2022

#99

Post by g_p »

hasel wrote: post #80
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…

Is this supposed to be used to put entire domains behind basic auth or should you use it for specific end points?

You can do this for specific endpoints in Caddy, or whole domains/sites.

If you create a matcher like

@wp-admin {

  path /wp-admin\*

  path /wp-login\*
}

Then you can just service up that handler's endpoints:

handle @wp-admin {

    basicauth {

       username pwhash_goes_here

       username2 pwhash2

    }

    # reverse proxy config etc, e.g.

    reverse_proxy http://127.0.0.1:8080
}

And now only the wp-admin and wp-login endpoints are protected, but the rest of the site is unaffected.

Re: Using HTTP Basic Auth in 2022

#100

Post by zorr »

loevborg wrote: post #32
nuccy wrote: post #12

I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-…

I do the same, e.g. to expose static resources like API docs in an S3 bucket to the world (you can configure CloudFront to check Basic Auth). However, at some point you run into issues (doesn't work well with password managers, how do new team members learn the password, no easy way to rotate passwords when offboarding, etc.). Now I want to upgrade to a proper OAuth wall. Some server needs to act as a reverse proxy t…

I used vouch-proxy with nginx for something like this.

The nginx auth_request module authenticates each request against vouch-proxy before it executes the proxy_pass. Vouch-proxy can be configured to authenticate users against google apps or other oauth/iodc providers. And there are some options to pass along username, groups or other data as headers to the proxied service.

Post reply on HN