Disable password on local network missing

[smaxl 1]

6 minutes ago, ebr said:

Hi.  Because that's what authentication is.  ….
because the system believes the traffic is internal is a very bad idea.

Okay, fair enough…. 

but if one user is fully authenticated - maybe a admin user - on one device… so the device is „trusted“ and other users can login with or maybe without pin !? 
 

would be great 

[smaxl 1]

8 minutes ago, darkassassin07 said:

Initial setup can be a bit of a pain; but once users are signed into the shared clients (tvs), they can just freely switch between them

I am totaly with you. But why do i have to sign in all users…. pain

[Q-Droid 989]

3 minutes ago, smaxl said:

I am totaly with you. But why do i have to sign in all users…. pain

Only you know that answer. But really, do you have to sign all users in to all TVs? In a family environment with young kids one shared account without password or simple password could be enough. Young kids are not likely to have or need remote access. A shared family account also with a simple password or none and without remote access could also work while separating the kids stuff from older content. Older kids and adults can sign in themselves. Adults needing help could probably do with a local only simple login as well. If they need help then likely not watching remotely either.

 

[johenning 5]

On 6/4/2024 at 11:35 PM, ebr said:

There are a lot of discussions on this forum explaining why assuming a different security posture just because the system believes the traffic is internal is a very bad idea.

So is having no password at all. You should enforce that each user has a password.
An insecure password is also a very bad idea. You should enforce >100bits of entropy.
Single factors are also bad practice, you should enforce two factor authentication.
Plain HTTP connections could be sniffed, its imperative that you disable any unencrypted connection. No self-signed certificates, TLS 1.3 and only modern ciphers, obviously.
 

 

 

Or maybe, just maybe, you don't know everything about the setup and you could leave this security consideration up to the person running the server. Have secure defaults by all means, but why force people into features that add no security whatsoever while impacting usability.

[Gilgamesh_48 1240]

While I understand the need for security I believe that every system need the ability to have absolutely no password. 

My system does not have any remote access enabled nor do I have any password locally except for those programs that will not install or run without them.
I also have exactly one user (me) for all my local systems. My network is protected by a very strong password as someone from outside might try to hack in but otherwise I am quite secure as there is no way in I can find for any bad actor unless I let them in or the actually break into my home. (In which case I have much worse problems than network security.

I am a firm believer in security but, if the physical security is good enough, my network is not vulnerable to outside attacks. 

I do NOT like being forced to have passwords on my local systems but, fortunately, Emby has a "don't require passwords on local network" options that allow me to mostly use Emby without the overkill of excessive password use and my computers have similar functionality. 

If you expose your system(s) to the outside then, yes, security is needed. But if it is impossible for anyone to get onto a network high security is not not needed while you are on it. 

Of course many people do not know where there network/system is truly vulnerable and they might need passwords all over the place but I do NOT and every program I run should have the option to not use passwords. Emby has such but there are a number of programs that do not. 

[johenning 5]

11 hours ago, Gilgamesh_48 said:

 fortunately, Emby has a "don't require passwords on local network" options

No, it doesn't. Thats what this thread is about

[pwhodges 2012]

But it's easy to set up your clients to remember the password after one entry, so that you don't have to use it repeatedly; you can even change users without using the password, so long as you do not actually log them out.

Paul

[Luke 42077]

Have your questions and concerns been resolved?

[johenning 5]

10 hours ago, Luke said:

Have your questions and concerns been resolved?

No. I'm still waiting on an answer to

  

On 2/18/2024 at 7:05 PM, johenning said:

Was it turned on by default, or how was it a security hole?

 

[rbjtech 5284]

1 hour ago, johenning said:

No. I'm still waiting on an answer to

  

 

https://emby.media/community/index.php?/topic/119524-full-disclosure-may-2023-security-incident-report/

[johenning 5]

33 minutes ago, rbjtech said:

https://emby.media/community/index.php?/topic/119524-full-disclosure-may-2023-security-incident-report/

Thanks for the context.

If I'm reading this correctly, this is only about admin accounts and the feature was not turned on by default. It seems unclear if this feature was exploitet or if the admin password was configured as emtpy. Either of which should be considered a security misconfiguration. Not sure I would call it a security hole if it requires the user to configure the system to be less secure.

So the fix was to not allow empty passwords for admin accounts and to remove the "Don’t require a password on the local network". 
It should have been obvious that this is not a feature to use on admin accounts, but I have no problem with it being restricted to lessen the possibility of accidental misconfiguration. But I don't see any security implications on non-admin accounts in this report, and AFAIK noone has asked to have the feature on admin accounts.

If unauthenticated access is a security hole, why can I still set emtpy passwords on non-admin accounts? And if only admin accounts are problematic, why can't I still not require a password locally for non-admin users?

Speaking of "gaping security holes" you can still set the admin passwords to be 1 character long.

[pwhodges 2012]

It was a security hole because an outside actor could connect remotely in a way that faked a local connection - so systems set up to be secure against outside access were not.

So it was decided that the local/non-local distinction was not sufficient for security.

Paul

[Q-Droid 989]

1 hour ago, johenning said:

If I'm reading this correctly, this is only about admin accounts and the feature was not turned on by default. It seems unclear if this feature was exploitet or if the admin password was configured as emtpy. Either of which should be considered a security misconfiguration. Not sure I would call it a security hole if it requires the user to configure the system to be less secure.

So the fix was to not allow empty passwords for admin accounts and to remove the "Don’t require a password on the local network". 
It should have been obvious that this is not a feature to use on admin accounts, but I have no problem with it being restricted to lessen the possibility of accidental misconfiguration. But I don't see any security implications on non-admin accounts in this report, and AFAIK noone has asked to have the feature on admin accounts.

If unauthenticated access is a security hole, why can I still set emtpy passwords on non-admin accounts? And if only admin accounts are problematic, why can't I still not require a password locally for non-admin users?

Speaking of "gaping security holes" you can still set the admin passwords to be 1 character long.

It was discussed ad-nauseam publicly and behind the scenes. It was not only about admin accounts. As posted by @pwhodges the exploit allowed an attacker to access Emby as if they were on the LAN along with everything that entails. Those who practice good security hygiene had zero to medium exposure. Those who don't, which is the vast majority of the Emby user base, had an open attack surface that was exploited in the wild.

The Emby team decided to close the hole and normalize authentication. At the time I didn't agree and felt there were other options available to mitigate the risk but when the house is burning you don't stop to discuss the ugly window shades. It was the right move on the dev team's part to just shut it then and now they are working on ways to simplify the login process while maintaining a consistent approach to authentication. My suggestions would still apply and I think some might be included but not all though Emby continues to evolve.

To all who are still complaining and questioning - That ship has sailed. Learn to live with the new and consistent way forward.

[johenning 5]

1 hour ago, pwhodges said:

It was a security hole because an outside actor could connect remotely in a way that faked a local connection - so systems set up to be secure against outside access were not.

I get what you are saying, but by that definition a VPN server is a security hole.

2 hours ago, pwhodges said:

So it was decided that the local/non-local distinction was not sufficient for security.

Well, I would have thought that was obvious from the beginning. Even if you didn't rely on headers, IP addresses can easily be spoofed as well. That IP-based authentication is flawed isn't really a new idea.
Its interesting that thats were you draw the line. I can see several other things that are not sufficient for security in Emby within just a few minutes of looking.

 

 

31 minutes ago, Q-Droid said:

It was discussed ad-nauseam publicly and behind the scenes. It was not only about admin accounts. As posted by @pwhodges the exploit allowed an attacker to access Emby as if they were on the LAN along with everything that entails. Those who practice good security hygiene had zero to medium exposure. Those who don't, which is the vast majority of the Emby user base, had an open attack surface that was exploited in the wild.

I just use Emby, I didn't follow any of the discussions on the topic. I came to this thread - as probably many in my position would - after upgrading and no longer having a feature I relied on. I would never expose Emby publicly, but I understand I might be an outlier here. As I said, its makes perfect sense to have secure defaults. But that in itself didn't explain the removal of the feature.

31 minutes ago, Q-Droid said:

The Emby team decided to close the hole and normalize authentication. At the time I didn't agree and felt there were other options available to mitigate the risk but when the house is burning you don't stop to discuss the ugly window shades. It was the right move on the dev team's part to just shut it then and now they are working on ways to simplify the login process while maintaining a consistent approach to authentication. My suggestions would still apply and I think some might be included but not all though Emby continues to evolve.

Fully agree with you here, thanks for the explanation. It was the first time in this thread I didn't feel gaslighted into believing that its awesome to enter randomly generated passwords on TV remotes.

31 minutes ago, Q-Droid said:

To all who are still complaining and questioning - That ship has sailed. Learn to live with the new and consistent way forward.

 Well, thats one way to look at it. I just looked back at my original question and stand by my solution and the implication the removal has for my usecase:

On 2/18/2024 at 7:05 PM, johenning said:

 The passwords only get used if connected via the VPN. Now I have to remove them entirely to get the previous flow back. So in fact it will now be less secure

 

 

 

[rbjtech 5284]

3 hours ago, johenning said:

Speaking of "gaping security holes" you can still set the admin passwords to be 1 character long.

Yep - strong password Entropy has not been implemented, but brute force deterrants have. 

But the simple fact is that the Auth is now being challenged - and this is enough defence to stop casual attempts - because the attacker has no idea if it's a single char or a complex 128bit password...  

(not that I'm suggesting to use a single char, I'm just illustrating that the attacker will be unaware of this so they will NEED to use brute force.) 

[pwhodges 2012]

1 hour ago, johenning said:

I get what you are saying, but by that definition a VPN server is a security hole.

They're certainly overrated by people who implement them with less knowledge than would be advisable; they're not magic...

Paul

[johenning 5]

1 hour ago, pwhodges said:

They're certainly overrated by people who implement them with less knowledge than would be advisable; they're not magic...

 

Quote

OpenVPN Server Release Notes - July 13, 2024

Fix(es):

• Removed remote connectivity because an outside actor could connect remotely in a way that faked a local connection - so systems set up to be secure against outside access were not.
• Test coverage is now 100%

[johenning 5]

One more suggestion: Its not uncommon for people to have very outdated installations. There might be lots of users that don't realize the feature is gone yet (like we saw in Gilgamesh_48's post). It might make sense to just have a FAQ on this.

For me this would have been enough to avoid lengthy discussions:

Quote

 What happened to the "don't require passwords on local network" option?

 This option was used by large parts of our community without the appropriate security considerations and actively exploited. We thus opted for removing the feature entirely.
 We recognize that entering complex passwords on local devices is less convenient, but we are constantly working on decreasing friction in the sign-in process.
 On most devices you only need to log-in once. For strong passwords but convenient re-authentication you can also configure a PIN [insert docu link].

 You can still configure non-admin accounts to use no password, but we strongly discourage it.

or something along those lines

[serpi 82]

21 hours ago, johenning said:

21 hours ago, johenning said:

OpenVPN Server Release Notes - July 13, 2024

Wow, they are way ahead in time!

[HairyBizRat 21]

ignore wrong thread

Edited August 15, 2024 by HairyBizRat

[serpi 82]

On 2/22/2024 at 4:52 PM, iiiJoe said:

Just curious, you’re using Emby as TV app?

Yes, on Samsung TV and Roku.