Secure Login Screen

[MSattler 387]

One of the things Plex does much better is that it keeps prying eyes from just getting straight to the user login screen.

 

The only way I can hide user information from my Emby login screen, is to set users to be hidden.  This however brings forth the issue that users now have to type in username, even if they are home and local.

 

Plex in this case makes the system owner authenticate each device that connects to it.  I don't think that wide a step is necessary.   Instead, what I would see is this:

 

Set an option to allow system owners to force authentication for a device the first time it connects.  Require it to authenticate with a known good password.

 

The webserver client for instance, would not show the list of users, only the browser has been authenticated.

 

This would make Emby much more secure.  Right now, to do that you have to hide the users which is a pain.   And if you don't hide your users, someone can simply brute force the account until the password is found.

 

 

[Luke 37094]

Where would the password come from?

[MSattler 387]

Where would the password come from?

 

Just something the System Owner sets.   Plex uses the System owners Plex Login.  While that works, it's not something you necessarily want to hand out?

 

In the plex world, I install Plex on a Nvidia shield and the Shield displays a code.  I go to the Plex Site when I authenticate, give it the shield's code, and then authorizes the device.

 

I think all that is overkill.   

 

Additionally there are some folks who run Emby and have 20+, 30+ users out there.  I think it would keep Emby from getting a reputation for being used for piracy type purposes, etc.

[Luke 37094]

How do we do this without adding an additional password to the system? The problem we face now is confusion over emby connect + local user login, so in essence we are paying a price for allowing Emby Connect to be optional. A third password would do more harm than good. The pin code system is something that would be more realistic, the first time from any given device.

[MSattler 387]

How do we do this without adding an additional password to the system? The problem we face now is confusion over emby connect + local user login, so in essence we are paying a price for allowing Emby Connect to be optional. A third password would do more harm than good. The pin code system is something that would be more realistic, the first time from any given device.

 

I suppose the Pin code system would work.  The biggest issue I see with this is that I personally have to approve each device, versus family members and such approving them.  In the end I don't want someone trying to brute force my Emby server.

[ebr 14921]

But then how does someone move between different users on the same device?

[MSattler 387]

But then how does someone move between different users on the same device?

 

?

 

Before a device can connect to a Emby Server and login, it needs to be authenticated by the System Owner.

 

Once the device is authenticated by the System Owner, you see the standard login screen.

 

Nothing changes except an additional authentication the first time a device connects to your server.

 

This is so that I can't just browse to your Emby server, see the list of users, pick one, and then just brute-force it until I find a working password.

[Luke 37094]

We could also just skip the pin code and go by the reported device id, and then just require manual approval for that device in the emby server dashboard before it can connect.

[MSattler 387]

We could also just skip the pin code and go by the reported device id, and then just require manual approval for that device in the emby server dashboard before it can connect.

 

That would work too.  How would that work with a browser?  Would you request access in the browser and then just wait for approval?

[Luke 37094]

the browser has no unique device id so we generate one and put it in local storage. that means when browsing data gets cleared you have to go through the process again. but the same thing would happen with a pin code though so it's not really different, e.g. in exchange for validating the pin code you get some token in return. that will be lost when browsing data is cleared, so it's the same limitation either way.

[ebr 14921]

Okay, I misunderstood the gist of your request.  Luke's suggestion would work - would need to be an optional "secure mode" of course and, with browsers, it will be a bit of a pain.

[MSattler 387]

the browser has no unique device id so we generate one and put it in local storage. that means when browsing data gets cleared you have to go through the process again. but the same thing would happen with a pin code though so it's not really different, e.g. in exchange for validating the pin code you get some token in return. that will be lost when browsing data is cleared, so it's the same limitation either way.

 

I think that is fine and that's the same way it works for plex.  

[Catsrules 17]

We could also just skip the pin code and go by the reported device id, and then just require manual approval for that device in the emby server dashboard before it can connect.

I like this idea.

Easy and simple

 

 

If we had unlimited resources this would be my perfect solution however it is more complicated but it might be more browser friendly.

 

 

Have two different login screens one for the external and another for the internal. 

 

The Internal login screen can be what we have now show all users names optional pin code login.

 

 

The external login screen will only be a login prompt similar to what we normally see with any online website. You need to enter in username and then a password, It should have brute force protection, you enter the password wrong X number of times the account gets locked out or the IP offending IP address gets blocked by Emby. It would also be a good idea and really cool to add 2 factor authentication. Once login the user has an option to enable trust this device, and the device will be added to the "trusted device list" and be autologin or be presented with the internal login screen from then on.