Emby baseline security concerns

[ray-finkle 10]

Hello,

 

I've been working on building out an Emby instance with security in mind, which has led me to discover some major weaknesses:

1. While I can enforce username/password credentials for a user, which is good; there is no minimum password length requirement!
   1. This leads the portal wide open to be bruteforced with ease. (most people will generally use the bare minimum password requirement)
   2. Due to this I will likely need to run an LDAP service which is honestly way to over-complicated for this.
   3. Fail2ban with strict rules is now also basically mandatory.
2. Emby connect defaults to plain http
   1. Emby connect is great for device ease-of-setup and I'd like to consider using it, but not in it's current state. (I'm aware of the reasoning for this from other posts)

 

For those reasons I hope to see these features implemented:

1. Admin definable minimum password length requirements
2. Modify Emby connect to be more secure
   1. My ideal (wishful) solution would be to make Emby connect even less centralized (and always https). High level process flow like this:
      1. Rather than prompt for username and password at app.emby.media, just ask for the server URL
      2. The web app can then query that server for an access code which the user can then input on another device
      3. Links the new device to the user account used to input that code.
      4. Obviously more considerations to be made...
   2. Otherwise, the server either needs to be SSL enabled by default (semi-automagically) or simply part of the configuration requirements... It's 2020; plain http should not be enabled on any public facing web service.

My only other gripe with Emby is still the speed to load images still doesn't compare to Plex after all these years.

 

Open discussion encouraged and I'm interested to hear thoughts from the devs and other similar minded folk.

[Luke 42083]

 

 

Emby connect defaults to plain http

1. Emby connect is great for device ease-of-setup and I'd like to consider using it, but not in it's current state. (I'm aware of the reasoning for this from other posts)

 

Hi, actually this not true. It defaults to whatever your remote address is listed as on your server dashboard. So if you configure https for your Emby Server, then it will use that.

[ebr 16187]

1. 1. 1. Rather than prompt for username and password at app.emby.media, just ask for the server URL

 

Emby Connect is really just a simplified way to reach your server without having to know the URL.  If you want to give your user's your server url directly, then you don't need to use Connect at all.  Just create users with strong passwords and give your user's those credentials.

[saltedhash 4]

I don't go through Emby Connect, but provide all of my users direct https url for my server. I also have a fully functional reverse proxy in front of it and only allow HTTPS. Some users may only use their instance locally and may not care about security on the LAN and don't want to be bugged with the ssl errors and don't understand self signed certs or going through the CA process. I believe most applications have an http instance for general connectivity, but this can usually be disabled.

 

As long as you configure it the right way, you should be fine   I do agree password policies would be nice, though.

[Luke 42083]

Yes the password policy is a request that I can understand and we can certainly improve there. Thanks for the feedback.

[ray-finkle 10]

Hi, actually this not true. It defaults to whatever your remote address is listed as on your server dashboard. So if you configure https for your Emby Server, then it will use that.

Luke - I'm a little confused on how this is functioning then.

 

When loading emby.media (which redirects to https) and clicking "Sign In" which takes you to http://app.emby.media/#!/startup/welcome.html. After clicking next you are at http://app.emby.media/#!/startup/connectlogin.html which is where the actual Emby Connect authentication occurs. Isn't this open to be easily snooped and therefore grant access to whichever servers the accounts are linked to?

[Luke 42083]

Ok that's just the online web app. That is not emby connect. So yes for that one app, if your server supports https then you will probably want to use https://app.emby.media

But if your server supports https, then the communications with your server are still over https.

[PhantomCircuit 6]

Can i also suggest to have 2FA option on login?

[Luke 42083]

I think that's a good idea, but not something that will be easy as it will require development in every single app. But yes it is possible for the future.

[ray-finkle 10]

I don't go through Emby Connect, but provide all of my users direct https url for my server. I also have a fully functional reverse proxy in front of it and only allow HTTPS. Some users may only use their instance locally and may not care about security on the LAN and don't want to be bugged with the ssl errors and don't understand self signed certs or going through the CA process. I believe most applications have an http instance for general connectivity, but this can usually be disabled.

 

As long as you configure it the right way, you should be fine   I do agree password policies would be nice, though.

I'm also setup behind a reverse proxy and have gone thru testing to define a secure set of headers as well. Additionally, I've rolled my own docker container for caddy w/addons, Google Oauth (for other services), and fail2ban, all built to run as a non-root user (unlike many popular container images).

 

Regardless, I can still set my password to "hi" which really is kind of silly. There should be some controls around the length and complexity minimums, even if it's an "advanced" type functionality that needs to be done outside the admin GUI.

[ray-finkle 10]

Ok that's just the online web app. That is not emby connect. So yes for that one app, if your server supports https then you will probably want to use https://app.emby.media

But if your server supports https, then the communications with your server are still over https.

Does this not mean that auth to emby connect thru the online web app in unencrypted then? Also, if the web app must work this way wouldn't all the apps likely have to be designed to behave the same way?

[Luke 42083]

The authentication requests still happen over the https protocol. It's the HTML for the app that is http if you are accessing the http version of the web app.

[ray-finkle 10]

Luke - I understand now after doing a little digging in my browser for verification. Thanks for squashing this concern.

 

 

TLDR reiterated for others: The authentication request is sent over https (to emby connect) even though the web app (app.emby.media) itself is loaded over http.

[Luke 42083]

Right, when the day comes that all Emby Servers have https all of the time, then we will no longer need the online web app to use http. Until then we have to support it.