4.8.0.80 Required pass on local network option

[thekingswolf 48]

I miss that.  New version is cool, but why remove the user account setting checkbox that allows me to log in to accounts without a pass when I'm on the local network?

[Luke 42077]

Hi, authenticating in different ways based on network location has turned out to not be a great security practice.

We have replaced it with something that we think will be even better, which is a new profile pin system so that you can quickly change users without having to enter a full password. Have you tried that?

You will have to login once, but then after that you can use the profile pin to come back.

[thekingswolf 48]

thanks Luke, I did see the new PIN system but wasn't sure about how it functions.  if I set a PIN there, I assume that will activate on the profile across all devices, not just on my local network

[K1ng_Lear 237]

11 minutes ago, thekingswolf said:

thanks Luke, I did see the new PIN system but wasn't sure about how it functions.  if I set a PIN there, I assume that will activate on the profile across all devices, not just on my local network

You have to log in once with your full credentials on every device. Afterwards you can come back to this device with you PIN and you don't need your credentials until the device is deleted from the device list on your server.

[Luke 42077]

1 hour ago, thekingswolf said:

thanks Luke, I did see the new PIN system but wasn't sure about how it functions.  if I set a PIN there, I assume that will activate on the profile across all devices, not just on my local network

Correct, it can be used everywhere. No longer limited to the local network.

[Ninko 78]

So you have to enter your PIN EVERY time when switching profiles on the local network?

[kingy444 117]

I dont want to be forced to PIN my accounts even if they are remembers - and specifically neither does my wife or children.

If the network configuration  has the ability to identify if I am local or not why can we not continue to utilise a feature that has existed for a long time

I completely understand if you wish it to not be the default but if the user is willing to accept the associated risk for the convenience I really hope this is something we can bring back.

This is actually something that should it been clearer in the upgrade logs i may have just stayed on 4.7. Upgrade logs were very vague on disappearing features. his is extremely disappointing and i would normally test on a docker or similar first but given how long this has been in beta i skipped that part.

I already secure all my accounts with a strong password for when I decide to allow remote connectvity (this is not always active and i login manually) - Only i knew this password because locally "Allow logins from local network" allowed the login thorugh

Now the only way to allow my wife and children to login easily is to remove all passwords from the account

So can i ask a further question:

If it is more secure to require a Password/PIN over the ability to "Login locally without password" - Why do i have the ability to have an account that simply has no password

Surely a passwordless account is even less secure than what we had before?

I will add a disclaimer here that i do agree this is more secure, but I also believe that as the end users we should be empowered to make the decision on the security risk and not have it made for us.

 

Essentially now instead of having my accounts secured by a password, I have had to remove the passwords completely

Can we please bring back the local network login?
Disclaimer it that this is not recommended etc etc if you need to but this really is a approval factor for EMBY.

Last I checked even Plex does not force this on its users and I really hope EMBY team listens to this feedback

 

Edited February 3, 2024 by kingy444

[adrianwi 279]

6 hours ago, Luke said:

 

We have replaced it with something that we think will be even better

This is the problem!  How do you know this is better for everyone?  How about giving people a choice rather than you deciding what works best for everyone?

Plex started making decision like this for its users which is why I switched to emby.  Is it time to switch again?

[Clackdor 109]

1 hour ago, adrianwi said:

This is the problem!  How do you know this is better for everyone?  How about giving people a choice rather than you deciding what works best for everyone?

Plex started making decision like this for its users which is why I switched to emby.  Is it time to switch again?

They made this change as allowing accounts to have no password on the local network introduced a potential security hole if the server was exposed remotely. Either through a reverse proxy misconfiguration, or forging headers it was possible to have a remote connection appear it came from a local network. If an account has no password on local networks then anyone could potentially access that account, which is very bad, especially if it's an admin account.

To close that hole they made a change in 4.7 to have emby ignore the http headers that allowed that to happen if they contained a local address. This also broke the server's ability to determine a client ip if accessed behind a reverse proxy in a local network. 

In 4.8 there is a configurable option to allow those http headers for local networks again, which fixes reverse proxy access for local networks. 

If they continued to allow no passwords for local access while providing that option to allow x-forwarded-for headers for local networks, that would potentially open up the security loophole again, which is a risk they're not willing to take. 

They made this change to increase the security of emby for all users, regardless of (mis)configuration.

Having no authentication on any self hosted service, or trying to differentiate authentication or lack thereof based on whether a client is local or remote is a bad security practice in general. I'm glad they made this change.

Plex has always required users to authenticate through their servers with no options for local user auth. That's always been the case. I tried it years and years ago and that was enough to make me not want to use it. Emby has and hopefully always will have local user/ldap authentication. Comparing emby to Plex is really a moot point in this regard.

 

 

 

 

 

 

 

[adrianwi 279]

But they've forced this on everyone, without even having an alternative solution (if PIN is actually an alternative) available in all of the clients yet.  How about giving users the choice to confiigure things as they want, with the approrpriate warnings for certainly configuration options?

[crusher11 1101]

4 hours ago, Ninko said:

So you have to enter your PIN EVERY time when switching profiles on the local network?

 

3 hours ago, kingy444 said:

I dont want to be forced to PIN my accounts even if they are remembers - and specifically neither does my wife or children

The PIN is not mandatory, it's simply an option. For example, if you have a children's account with limited access, and an adult's account with open access, and you want to avoid the child accessing the adult account, you can protect it with a PIN.

If you don't want to do that, you're free to have all accounts accessible without any PIN or password, locally or remotely. All you have to do is log in with the password once, to start with, then the account will be remembered. The PIN is simply a parental control/privacy option.

[adrianwi 279]

But you can't have a user with a password, that doesn't then need to use that password or a PIN to access a server on a local network, which you could previously.

[pwhodges 2012]

You have a user with a password, which is used once to log in on each device, which should be set to remember it.  The memory will be cleared if you log out; but if you change to another user using "change user" you can go back and forth without requiring any password on that device, or using a PIN if you select that option for any of the accounts concerned.

Paul

Edited February 3, 2024 by pwhodges

[Q-Droid 989]

2 minutes ago, pwhodges said:

You have a user with a password, which is used once to log in on each device, which should be set to remember it.  The memory will be cleared if you log out; but if you change to another user using "change user" you can go back and forth without requiring any password on that device, or using a PIN if you select that option for any of the accounts concerned.

Paul

I think one of the big questions is whether this functionality was added to all Emby clients on every platform at the time of or before the rollout of the 4.8 stable release. If not then there are many users caught off guard by this. It changes how they use Emby and there will be more coming here to express their frustration.

[rbjtech 5284]

11 minutes ago, adrianwi said:

But you can't have a user with a password, that doesn't then need to use that password or a PIN to access a server on a local network, which you could previously.

..and yet you are pressing for 2FA ?  You are aware the detection of a 'local/rfc 1918' network means absolutely nothing in terms of your location right ?    This is exactly how the original emby security vulnerability was used to gain access to those users with no password.    Emby have closed the vulnerability - with the slight one-off inconvienence of now having to enter a password once per device ... ?

Edited February 3, 2024 by rbjtech

[adrianwi 279]

I'm pressing for choice!  Users should have options how the want to configure their server, and not have things imposed.  If I am connecting to a local IP address, why does it need to enforce a password/PIN?  If I'm connecting remotely using SSL certificates, why can't I ask for 2FA? 

[ebr 16171]

6 minutes ago, adrianwi said:

If I am connecting to a local IP address, why does it need to enforce a password/PIN?

As has been mentioned multiple times already, the PIN is optional.  Once initially authenticated, you can freely switch between users on a device - locally or remotely now - without any password or PIN if you wish.

[adrianwi 279]

Not for all clients

[darkassassin07 652]

You've had since may last year to provide feedback on this change. It was made quite clear at the time, that this change was coming; both in the public and beta channel discussions, particularly around the time every effected emby server shut itself down alerting the operator and directing them here for further info.

Maybe you should have engaged in those discussions...

 

 

Changing the authentication requirements based on your apparent location (local vs wan) is a horrible practice that creates vulnerabilities that many won't even know to look for/avoid. Unfortunately in situations like that; you've gotta cater to the lowest common denominator.

Want no passwords at all? Remove the passwords and make the server inaccessible from WAN. Or leave it exposed and accept the risks.

 

Most of the clients are already updated to the new standards; the few that aren't are in review by their app distributors (some smart TVs for example). Have a little patience. Or side-load the latest version.

Edited February 3, 2024 by darkassassin07

[Clackdor 109]

2 minutes ago, adrianwi said:

I'm pressing for choice!  Users should have options how the want to configure their server, and not have things imposed.  If I am connecting to a local IP address, why does it need to enforce a password/PIN?  If I'm connecting remotely using SSL certificates, why can't I ask for 2FA? 

While I agree that choice is a good thing, and features should keep user choice in mind, there are tradeoffs between convenience and security.

As someone who has been self hosting services on my home server since the late 2000's, I can tell you there aren't many applications that don't require some kind of authentication to access them. Most self hosted applications require authentication because of the assumption that it may be exposed publicly.

Requiring a username and password is the bare minimum in terms of securing an application properly.

Now I'd be upset if they implemented 2fa as a requirement, but it would be nice to have the option.

[kingy444 117]

7 hours ago, darkassassin07 said:

You've had since may last year to provide feedback on this change. It was made quite clear at the time, that this change was coming; both in the public and beta channel discussions, particularly around the time every effected emby server shut itself down alerting the operator and directing them here for further info.

Maybe you should have engaged in those discussions...

Unfortunately this assumes that the general end user either trolls the forum or runs beta. I do not recall stable being directed here for anything related to local network configurations.

 

7 hours ago, ebr said:

As has been mentioned multiple times already, the PIN is optional.  Once initially authenticated, you can freely switch between users on a device - locally or remotely now - without any password or PIN if you wish.

7 hours ago, Clackdor said:

Requiring a username and password is the bare minimum in terms of securing an application properly.

7 hours ago, darkassassin07 said:

Want no passwords at all? Remove the passwords and make the server inaccessible from WAN. Or leave it exposed and accept the risks.

Having no password configured on an account is not the answer and is even worse in my opinion than what existed before. I am ok with ADMIN level users requiring further locking but a general user who can only view media shouldnt be forced to.

 

8 hours ago, Clackdor said:

Having no authentication on any self hosted service, or trying to differentiate authentication or lack thereof based on whether a client is local or remote is a bad security practice in general. I'm glad they made this change.

This option hasnt been removed though - you can still have no password on the account. 

 

7 hours ago, darkassassin07 said:

Changing the authentication requirements based on your apparent location (local vs wan) is a horrible practice that creates vulnerabilities that many won't even know to look for/avoid.

It is common practice especially in government. Internal authentication will require a single factor, external requires MFA. You have an internal 'Trusted Network' and outside that MFA is required.

All beit that we are talking zero factor local and 1 factor remote a 'Trusted Network' is not an uncommon practice.

Previously we could have 0 factor on local network and 1 factor remote.
Now we are forced into either 1 factor local and remote, or 0 factors local and remore. There is an arguement here that without the implementation of 2FA we are actually in a worse situation now (as we allow users to have 0 password and be exposed remotely)

 

Personally, I thinkit should be a REQUIREMENT for a password on remote connections. No Password on the account, no remote access. Want to improve security there, enforce passwords of 14 characters or more too.

 

There are plenty systems that use a Trusted Network, I am not a network specialist but i know they exist. Microsoft Azure and VMWare Workspace Access are systems I have configured this in before so I am aware that these technologies work and can be secure.

 

8 hours ago, Clackdor said:

To close that hole they made a change in 4.7 to have emby ignore the http headers that allowed that to happen if they contained a local address. This also broke the server's ability to determine a client ip if accessed behind a reverse proxy in a local network. 

In 4.8 there is a configurable option to allow those http headers for local networks again, which fixes reverse proxy access for local networks. 

Doesnt this statement equate to the hole was closed ?If so, little confused what the issue is having "No password on Trusted Networks"

[Luke 42077]

12 hours ago, adrianwi said:

Not for all clients

Right but we will get there. One of which should be available soon when it gets through LG review.

[Clackdor 109]

@kingy444The reason why they removed the option is directly related to the security issue from last year. Either through reverse proxy misconfiguration or forging x-forwarded-for http headers, accounts with no password required on local networks could be accessed remotely even if a password was set for remote connections. 

The workaround they implemented in 4.7 was to have emby completely disregard x-forwarded-for headers if they contained a local address, thus closing the security hole at that time.

I personally run emby behind a reverse proxy, even on the local network. After they implemented the workaround I was no longer able to see the actual client ip's for devices connecting inside the network through the reverse proxy as the headers were being ignored. This was quite annoying to deal with, but I understood why they disabled it at that time and didn't allow for it to be a configurable option while still having passwordless access for local users.

In 4.8 there is now an option to configure how emby responds to x-forwarded-for headers. For users like myself that run a reverse proxy internally, it's desirable to have them enabled for local addresses.

Having that option creates the potential for that security hole to be opened back up if they continued to differentiate between whether a password is required for local access. It could easily be misconfigured, or intentionally set by a user that isn't aware of the security implications of having emby respond to x-forwarded-for headers for local addresses while also not requiring a password on local networks.

While it's still possible to have an account with no password in 4.8, that is done at the server admin's discretion, and the security implications of doing so should be blatantly obvious to basically anyone, especially if allowing remote access. 

 

 

 

 

 

 

 

[kingy444 117]

3 hours ago, Clackdor said:

The workaround they implemented in 4.7 was to have emby completely disregard x-forwarded-for headers if they contained a local address, thus closing the security hole at that time.

Thanks for the detailed explanation of the reasoning - but as you said this was also not an issue after the mitigation of 4.7

Could we simply not have the same mitigation in 4.8

Disclaimer on the “Allow no password on local network” would read along the lines of “By enabling this option all x-forwarded-for headers will be ignored. This will mainly affect users of a reverse proxy. Refer to documentation (insert link) for further detail”

 

edit: on second thought - the disclaimer probably makes more sense on the networks screen as someone setting that value probably knows more about the impact. But 4.7 shows it’s not an all or nothing and there is room for compromise here.

disclaimer could then read “enabling x-forwarded-for headers will enforce passwords and pin on all accounts regardless of what is set on user profiles”

Edited February 4, 2024 by kingy444

[Guest CodeCat5]

22 hours ago, ebr said:

As has been mentioned multiple times already, the PIN is optional.  Once initially authenticated, you can freely switch between users on a device - locally or remotely now - without any password or PIN if you wish.

This still doesn't solve the issue for those of us who were previously using a PIN to login locally and keep kids out of our accounts. Now the PIN feature is completely broken on the Android TV app, and the only solution provided is to side load the standard app. That could almost be a solution, but the standard app isn't secure at all after the initial login and still automatically logs you back in after closing it, which kinda defeats the purpose of having a PIN in the first place.