this post was submitted on 20 Aug 2024
64 points (97.1% liked)

Selfhosted

60253 readers
531 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

Basically every local service is accessed via a web interface, and every interface wants a username and password. Assuming none of these services are exposed to the internet, how much effort do you put into security here?
Personally, I didn't really think about it when I started. I make a half-assed effort at security where I don't use "admin" or anything obvious as the username, and I use a decent-but-not-industrial password - but I started reusing the u/p as the number of services I'm running grew. I have my browsers remember the u/ps.
Should one go farther than this? And if so, what's the threat model? Is there an easier way?

you are viewing a single comment's thread
view the rest of the comments
[–] TCB13@lemmy.world 1 points 2 years ago

Too much pieces that can potentially break. I've been looking at http://nginx.org/en/docs/http/ngx_http_auth_request_module.html and there's this https://github.com/kendokan/phpAuthRequest that is way more self contained and simple to maintain long term. The only issue I'm facing with that solution is that I'm yet capable of passing a token / username in a header to the final application.