Suggestion about default authentication

A long long while ago I came across someone’s sonarr in google (accidently), and, wanting to help, I logged in and created some items that I hoped the person might see, saying something like “YOUR SONARR IS IN GOOGLE ADD A PASSWORD”.

Today it came up on reddit, and this time I tried a google search that I thought might lead to some sonarrs, and it did, a pagefull. I didn’t log in to any of these, but it made me realize, although this isn’t really sonarr’s problem, maybe the defaults can be adjusted in a better way to prevent this so that someone REALLY has to TRY to shoot themselves in the foot to get there.

Maybe default access should only be on the local subnet by default? I understand that no password is probably handy from a support point of view, since users are sure to lock themselves out, not be able to get in, etc, especially when installing for the first time.

Is there another way to address this? I mean, it’s not the end of the world but still it’s disturbing.

Well, it happened a couple of months ago as well. Back then I considered checking using our server whether the user setup is publicly accessible. But I felt that could be construed as dialing-home.

Atm, I’m thinking about using uPnP to check whether there’s a port forward in place in a health check.

But refusing access if the remote IP is not on the local sub is actually an option.

Still, ppl usually find a way to leave their front door open. We can only go so far.

Local network only when no password is set sounds reasonable, until someone wants it available on first start and they don’t have a local network.

Markus: I think you’re reaching, but maybe my imagination is failing me. I’m having trouble imagining someone to have local access to install the software, but not local access to configure it? And then we’re talking about … how many installations (of, I suspect, a more tech savvy demographic) then let’s contrast that against the much more massive demographic of people who (obviously) don’t know what they are doing really and are just happy to get a port forward to work.

If you wanted to pursue local network only distinctions, that would only have to be in the situation that no password is set, as well. I’m failing in thinking of a way to work around this without having some user input in the installation though. But really, why not have two or three tick boxes in the installer (possibly including ‘set credentials’ to enable/disable/secure remote access utilizing the options that have just come up in this thread?

EDIT: I realized that I silently included some assumptions in my thinking but didn’t articulate them - if I can find 10 in google in 30 seconds, that suggests to me the problem is actually far, far, more widespread, meaning that real bad actors that actually port scan are likely to find scads and scads of these. Maybe my assumptions about this are overblown though.

  1. It’s only exposed if the user deliberately set his computer as DMZ or added a port forward.
  2. If we default to local network only if not authed, ppl installing sonarr remotely on a vps would not have access to the UI to configure it.

We’re considering a health check to warn ppl of these scenarios but it’s not easy to cover all of them properly.
From my point of view this would be a courtesy, not a responsibility, citing point 1.

But don’t worry, we’ll think of something eventually.

We’ve talked about a setup wizard (once Sonarr is running), which could definitely have the option to set a password which will put it in their face a bit more, but doesn’t solve anything, people that don’t want a password won’t set one and they’ll end up in the same spot.