

Yup, but most of that is easily solvable by being consistent, e.g. always use lowercase and your email (even if it’s not the login for that site). But yes, you need to know to be consistent so it’s a good point to make.
Yup, but most of that is easily solvable by being consistent, e.g. always use lowercase and your email (even if it’s not the login for that site). But yes, you need to know to be consistent so it’s a good point to make.
It’s strange how I never see this mentioned anywhere, but there’s a way to get unique secure passwords for every site/app without needing to store them anywhere. It’s called LessPass, and essentially generates passwords based on 3 fields (site, username, master password) and works relatively well, because the advantages are quite obvious I’ll list the potential downsides:
Another vote for Silverbullet, it allows you to write your code blocks in a certain manner that you can query them, so it suits very well the use case.
Depends on what you want the server to do. A Minecraft server and a Pihole server have vastly different requirements. As a general rule, any old laptop or desktop will do, think on requirements for your grandma and that should cover most (except gaming servers) needs.
Lots of questions, let’s take it one step at a time. You have a domain, now you can point it to your public IP, so that whenever someone tries to access example.com they ask their DNS server and it replies with 10.172.172.172 (which btw is not a valid public IP). Now that request will hit your router, you need to configure your router to redirect ports 80 and 443 to 192.168.200.101, that way the request to example.com gets to your local machine.
Ok, so now you need your local machine to reply on that port, I recommend using Caddy it’s very easy to setup, but NGIX is the more traditional approach. A simple Caddy config would look like:
example.com {
respond "Hello"
}
jellyfin.example.com {
handle {
reverse_proxy http://192.168.200.101:1020/
}
}
So after the request reaches Caddy it will see that the person tried to access, example.com and respond with a “Hello”.
If instead you had tried jellyfin.example.com the DNS would have sent you to 10.172.172.172, your router would send that to 192.168.200.101, Caddy would then send it to 192.168.200.101:1020, which is Jellyfin so that would get returned.
There are some improvements that can be made, for example if both caddy and Jellyfin are docker you can share a network between them so Jellyfin is only exposed through caddy. Another possibly good idea is to add some authentication service like Authelia or Authentik to harden stuff a little bit. Also as you might have noticed Caddy can forward stuff to other computers, so you can have one machine on your network exposing multiple services on multiple machines.
Use docker, once you’re comfortable with it then switch to Podman. Podman has a few more complications, so it’s easier to get the base thing running using the most common tool, and work from there.
My point is that of those 120 probably 110 have never been compromised nor forced you to change the password due to expiration policies. The remaining 10 are the ones that require some mental gymnastics, so while the problem exists it’s not as serious as it sounds. I probably have more than 120 identities using this method since I’ve been using it for years, and I don’t think I ever had to use the counter, it’s a matter of being consistent in how you think about websites, for example if you know how you refer to a site slugify it and use that for the field, so you would use spotify, netflix, amazon-prime.