2-Factor Authentication (2FA)

[Przemek 54]

On 10/19/2022 at 10:52 PM, Luke said:

You might be able to do the same with our LDAP plugin.

I don't know how LDAP works.

[GWTPqZp6b 41]

18 minutes ago, Przemek said:

I don't know how LDAP works.

A primer. https://www.okta.com/identity-101/what-is-ldap/

[metsuke 27]

3 hours ago, Przemek said:

I don't know how LDAP works.

Have you looked at authelia? It would place auth in front of Emby, so users may need to log in twice, but at least you would have some security.

[Przemek 54]

On 10/22/2022 at 11:49 PM, GWTPqZp6b said:

A primer. https://www.okta.com/identity-101/what-is-ldap/

I'm to stupid for that. I don't understand that.

[Przemek 54]

On 10/23/2022 at 2:35 AM, metsuke said:

Have you looked at authelia? It would place auth in front of Emby, so users may need to log in twice, but at least you would have some security.

Authentik do the same as Authelia but it's easier to install and configure.

[toddaniels 7]

Sheldon/Luke already stated that adding it directly to emby is not as simple as people want to believe. I imagine that also means it's low on the priority list. I'd suggest this thread shifts to (or maybe in another thread entirely) ways of accomplishing 2FA outside the emby server application. If you really need it now, just use any of the stated workarounds: ssh tunnel, apache/duo, nginx, e.g.

SSH Tunnel (my recommended solution)
Pros: it's way more secure than having your emby server exposed to the general internet. it's two factor (ssh key + username/password). Revocation of keys is super-simple. works with roku and other emby-aware clients.
Cons: setup is more complicated (but this is a one-time thing). requires a tunnel-capable device on each side (i've done it with pfsense, raspberry pi, ubuntu server/desktop, windows 10 with putty, windows 10 with openssh server, windows 10 with ssh client. should work with openwrt). Probably not scalable if you have a lot (20+) of remote users (I have 4 active now and it was not too difficult to set up for them).

If the community has enough interest, I can write something up and post it. Let's discuss first though before I sink time into something the community doesn't want or can't use or that won't solve the problem adequately.

 

[raudraido 43]

11 minutes ago, toddaniels said:

Sheldon/Luke already stated that adding it directly to emby is not as simple as people want to believe. I imagine that also means it's low on the priority list. I'd suggest this thread shifts to (or maybe in another thread entirely) ways of accomplishing 2FA outside the emby server application. If you really need it now, just use any of the stated workarounds: ssh tunnel, apache/duo, nginx, e.g.

SSH Tunnel (my recommended solution)
Pros: it's way more secure than having your emby server exposed to the general internet. it's two factor (ssh key + username/password). Revocation of keys is super-simple. works with roku and other emby-aware clients.
Cons: setup is more complicated (but this is a one-time thing). requires a tunnel-capable device on each side (i've done it with pfsense, raspberry pi, ubuntu server/desktop, windows 10 with putty, windows 10 with openssh server, windows 10 with ssh client. should work with openwrt). Probably not scalable if you have a lot (20+) of remote users (I have 4 active now and it was not too difficult to set up for them).

If the community has enough interest, I can write something up and post it. Let's discuss first though before I sink time into something the community doesn't want or can't use or that won't solve the problem adequately.

 

I was also worried because my Emby is exposed to the internet, but I moved to Emby docker container, which do not have direct access to host network and only has read only access to media library. So, I'm not worried at all. Even if someone could mess up Emby setting thru some Emby security vulnerability, I could roll back docker container and I'm good again

Edited October 24, 2022 by raudraido

[toddaniels 7]

1 hour ago, raudraido said:

I was also worried because my Emby is exposed to the internet, but I moved to Emby docker container, which do not have direct access to host network and only has read only access to media library. So, I'm not worried at all. Even if someone could mess up Emby setting thru some Emby security vulnerability, I could roll back docker container and I'm good again

Sounds like a good upgrade. I imagine you're willing to forego 2FA entirely with this setup?

[raudraido 43]

19 hours ago, toddaniels said:

Sounds like a good upgrade. I imagine you're willing to forego 2FA entirely with this setup?

Yes, If Emby has 2FA, I would not enable it. I have no personal data in Emby.

[rbjtech 4223]

5 hours ago, raudraido said:

Yes, If Emby has 2FA, I would not enable it. I have no personal data in Emby.

Many people appear to be missing the entire point of 2FA for emby, believing it's magically going to stop the bad guys - the simple answer is it's not, not even close.

If you are naive enough to use the same password for multiple systems, then 2FA is going to get you some more protection when (not if) your password is available from a data breech.

But the real risk to emby is not it's data or media, it's simply an 'entry point' into your home network that is now available and for the bad guys to wait for an 'emby toolset' vulnerability.  It could be the emby web server, ffmpeg, it's database etc - if one of those gets compromised and remote code is executable from the internet - then bang,  the attacker has access to whatever network your emby server is on.

For those with experience on cyber security/networks - yes there are all sorts of extra protections available - Reverse Proxies, VPN's, Isolated DMZ networks, IPS etc - these would all sit 'in front' of the emby web service - which should sit 'inside' a reasonable protected perimeter 'defence'.

So going back to the question - is 2FA going to add protection - my personal belief is it's not a priority - especially when HTTPS is not enforced, password strength is not enforced, brute force lockouts are not enforced etc.    These are things which could be done with relative ease - and provide better basic security out the box.  Once the basics are done - THEN maybe think about 2FA for the Admin account ..

Just my 2p.

[raudraido 43]

1 hour ago, rbjtech said:

Many people appear to be missing the entire point of 2FA for emby, believing it's magically going to stop the bad guys - the simple answer is it's not, not even close.

If you are naive enough to use the same password for multiple systems, then 2FA is going to get you some more protection when (not if) your password is available from a data breech.

But the real risk to emby is not it's data or media, it's simply an 'entry point' into your home network that is now available and for the bad guys to wait for an 'emby toolset' vulnerability.  It could be the emby web server, ffmpeg, it's database etc - if one of those gets compromised and remote code is executable from the internet - then bang,  the attacker has access to whatever network your emby server is on.

For those with experience on cyber security/networks - yes there are all sorts of extra protections available - Reverse Proxies, VPN's, Isolated DMZ networks, IPS etc - these would all sit 'in front' of the emby web service - which should sit 'inside' a reasonable protected perimeter 'defence'.

So going back to the question - is 2FA going to add protection - my personal belief is it's not a priority - especially when HTTPS is not enforced, password strength is not enforced, brute force lockouts are not enforced etc.    These are things which could be done with relative ease - and provide better basic security out the box.  Once the basics are done - THEN maybe think about 2FA for the Admin account ..

Just my 2p.

Yes, I agree. This is exactly why I do not think that 2FA is necessary for me.

I'm pretty confident, when my Emby server gets compromised, not much can be done inside docker container bridge network with read only access to media.

I'm willing to take that risk, if Docker gets a security hole, I'm F***ed, but still I'm pretty confident that patch arrives before someone's trying to hack my system thru emby-docker combined vulnerability.

[toddaniels 7]

2 hours ago, rbjtech said:

Many people appear to be missing the entire point of 2FA for emby, believing it's magically going to stop the bad guys - the simple answer is it's not, not even close.

Preach, brother!! That's why I recommend using an ssh tunnel. If the attacker can't even get to the process bound to the tcp port, it's more secure. I also think rauraido's approach is at least significantly more secure than emby outside a docker where all the exploits you mention above are a much bigger concern.

[adrianwi 237]

Security is all about layers.  MFA would add another one, so not a bad thing.

[rbjtech 4223]

39 minutes ago, adrianwi said:

Security is all about layers.  MFA would add another one, so not a bad thing.

Yes but the priority of the layers is important.  Zero point having MFA with HTTP - as any competent attacker will just inject 'Authenticated=Yes' into the HTTP response for example.  Same with password complexity, little point having a highly complex / high entropy password if you can just snoop it on the wire.    HTTPS is now a 'basic' requirement - my firm belief is emby should not allow remote access over http any longer - it is irresponsible and putting the users home network at risk.   Users are not even warned of this ...

[Cheesegeezer 3086]

28 minutes ago, rbjtech said:

Yes but the priority of the layers is important.  Zero point having MFA with HTTP - as any competent attacker will just inject 'Authenticated=Yes' into the HTTP response for example.  Same with password complexity, little point having a highly complex / high entropy password if you can just snoop it on the wire.    HTTPS is now a 'basic' requirement - my firm belief is emby should not allow remote access over http any longer - it is irresponsible and putting the users home network at risk.   Users are not even warned of this ...

I have been following this thread and taking a lot in, because my knowledge of e-security is very limited. And I would like to thank all you knowledgable people for educating me.

But i think that you hit the nail on the head just with that statement. I hope that Core Devs push this requirement

Quote

HTTPS is now a 'basic' requirement - my firm belief is emby should not allow remote access over http any longer - it is irresponsible and putting the users home network at risk.

 

[raudraido 43]

1 hour ago, rbjtech said:

Yes but the priority of the layers is important.  Zero point having MFA with HTTP - as any competent attacker will just inject 'Authenticated=Yes' into the HTTP response for example.  Same with password complexity, little point having a highly complex / high entropy password if you can just snoop it on the wire.    HTTPS is now a 'basic' requirement - my firm belief is emby should not allow remote access over http any longer - it is irresponsible and putting the users home network at risk.   Users are not even warned of this ...

 

I can not see how someone is able to set up internet access to Emby server and somehow skips HTTPS, I think this problem is just theoretical.

[Painkiller8818 203]

I am a professional security specialist or lets say IT guy in general and i understand your statements and most of them make sens but there are a few things you can't decide for the peoples.

1. Force HTTPS and don't allow access over HTTP

This is something a user has to decide, you shouldn't force users to open port 443 on their routers and add certificates etc... There are still a lot people using emby locally only and even if not, you only can give people security hints and lead them on how to make their systems more secure but there will always be a lot people just ignoring it.
The other thing is, just having https does not really means your system is secure, almost every website does have forced HTTPS but they get hacked almost every day
So forcing https seems not to be the solution at all, but giving them the option to use it is the best you can do.


2. MFA also is not the holy grail but giving the users the option to have it is better than always finding some "security reasons" why you won't give them what they asking for by telling them 100 other possible scenarios their server may be insecure, so why don't you just give them the OPTION to have MFA. 

It is not your job to make sure that the users' servers are 100% secure otherwise you should have checked and enforced various dependencies during installation. 
If a users server gets hacked, who cares, you are not responsible for it, but if i could have a better security and an additional layer for security which MFA is, it is in your hands to give users the ability to use it, and it seems like you refuse to offer this possibility to the users at any price.

I know it is a lot work to make MFA working for all different systems but just telling people should think about and fix all other "possible" other security issues you could start implementing it.

Sure we can talk about some apache, nginx or database exploits and so on but thats not the point.

So please think about it and just give them what they are asking since almost 5 years now.

thanks

 

Edited October 26, 2022 by Painkiller8818

[Cheesegeezer 3086]

17 minutes ago, Painkiller8818 said:

I am a professional security specialist or lets say IT guy in general and i understand your statements and most of them make sens but there are a few things you can't decide for the peoples.

1. Force HTTPS and don't allow access over HTTP

This is something a user has to decide, you shouldn't force users to open port 443 on their routers and add certificates etc... There are still a lot people using emby locally only and even if not, you only can give people security hints and lead them on how to make their systems more secure but there will always be a lot people just ignoring it.
The other thing is, just having https does not really means your system is secure, almost every website does have forced HTTPS but they get hacked almost every day
So forcing https seems not to be the solution at all, but giving them the option to use it is the best you can do

 

I think the point is that access emby using the remote should force https.... i think this is wise

BTW - good luck getting into my server im on CGNAT hahahaha and i would have to set up VPN, Virtual Servers and god knows what else to be able to access my Emby from outside my local network.

17 minutes ago, Painkiller8818 said:

2. MFA also is not the holy grail but giving the users the option to have it is better than always finding some "security reasons" why you won't give them what they asking for by telling them 100 other possible scenarios their server may be insecure, so why don't you just give them the OPTION to have MFA. 

It is not your job to make sure that the users' servers are 100% secure otherwise you should have checked and enforced various dependencies during installation. 
If a users server gets hacked, who cares, you are not responsible for it, but if i could have a better security and an additional layer for security which MFA is, it is in your hands to give users the ability to use it, and it seems like you refuse to offer this possibility to the users at any price.

I know it is a lot work to make MFA working for all different systems but just telling people should think about and fix all other "possible" other security issues you could start implementing it.

Sure we can talk about some apache, nginx or database exploits and so on but thats not the point.

So please think about it and just give them what they are asking since almost 5 years now.

thanks

 

 

[sydlexius 240]

5 hours ago, Painkiller8818 said:

1. Force HTTPS and don't allow access over HTTP

This is something a user has to decide, you shouldn't force users to open port 443 on their routers and add certificates etc... There are still a lot people using emby locally only and even if not, you only can give people security hints and lead them on how to make their systems more secure but there will always be a lot people just ignoring it.
The other thing is, just having https does not really means your system is secure, almost every website does have forced HTTPS but they get hacked almost every day
So forcing https seems not to be the solution at all, but giving them the option to use it is the best you can do.

As an it person, you should know that TLS <> port 443. Port 443 requires TLS (or weaker SSL), however Emby offers TLS over port 8920.  Many other secure ports also offer TLS (and even HTTPS!). Emby and it's developers don't force you to map any external ports. The operator does so when they decide they want to stream off-network. Anyone performing this step ought to educate themselves on the benefits vs risk.

 

Like @rbjtech  I feel allowing insecure access is a bad practice. Meanwhile, the person with admin access to their router can kill their mapping to 8096.

[Painkiller8818 203]

10 minutes ago, sydlexius said:

As an it person, you should know that TLS <> port 443. Port 443 requires TLS (or weaker SSL), however Emby offers TLS over port 8920.  Many other secure ports also offer TLS (and even HTTPS!). Emby and it's developers don't force you to map any external ports. The operator does so when they decide they want to stream off-network. Anyone performing this step ought to educate themselves on the benefits vs risk.

 

Like @rbjtech  I feel allowing insecure access is a bad practice. Meanwhile, the person with admin access to their router can kill their mapping to 8096.

sure i know but it is the default https port and as most people here are no tech guys it is more easy to understand for them.

But funny you all are complaining about some phrases of my comment but not seeing that adding MFA is an additional security layer, you don't have to fear your server would have weaker security with this option available, it is an improvement if you like it or not.

[sydlexius 240]

2 minutes ago, Painkiller8818 said:

sure i know but it is the default https port and as most people here are no tech guys it is more easy to understand for them.

But funny you all are complaining about some phrases of my comment but not seeing that adding MFA is an additional security layer, you don't have to fear your server would have weaker security with this option available, it is an improvement if you like it or not.

If you bothered to look at the initial request, you'd see that I voted for this feature. MFA has its place, but as has been so astutely pointed out by others, it's just security theater if other underlying security issues remain to be addressed. I want this feature in due time.

[metsuke 27]

Would http be as bad for you if you used a service like Cloudflare as SSL and only allowed connections from Cloudflare? What about if you used a reverse proxy and terminated SSL there?

I'm giving these as rhetorical examples of how http can be ok on the server side, though of course you really have to trust Cloudflare (and your ISP) or your proxy (though you always putting your faith in something when using technology that you don't 100% understand every bit of...and even then). https should not be forced, but there should be a litany of warnings and suggestions about it if you do not.

Since https support is already provided, that issue is taken care of in my mind. Setting up services to be exposed by WAN is not for people who don't understand the repercussions of this action. There are hosted services that can do this for you, but I've yet to see any self-hosted platforms for people with no IT knowledge. It is the world we live in, and deviating from the status quo often means relinquishing flexibility, like a walled garden. Those projects often die fast because people with the knowledge to set things up properly don't like the single way that is required by the app. There is probably another larger platform to solve that problem with, but I don't think it should be an every-individual-all kind of issue to solve.

I would argue that some years ago, MFA became a basic feature. All other web services or self-hosted apps that I expose have MFA, because it is recognized universally in the industry as needed in order to stem the inherent issues with passwords. If Emby has other security issues, that's fine, fix them, but that does not negate the need for additional protection for the admin account. 8-character passwords can be cracked in under an hour now. MFA makes that information negligible.

Edited October 26, 2022 by metsuke

[sydlexius 240]

Just now, metsuke said:

Would http be as bad for you if you used a service like Cloudflare as SSL and only allowed connections from Cloudflare? What about if you used a reverse proxy and terminated SSL there?

I'm giving these as rhetorical examples of how http can be ok on the server side, though of course you really have to trust Cloudflare or your proxy (though you always putting your faith in something when using technology that you don't 100% understand every bit of...and even then). https should not be forced, but there should be a litany of warnings and suggestions about it if you do not.

Since https support is already provided, that issue is taken care of in my mind. Setting up services to be exposed by WAN is not for people who don't understand the repercussions of this action. There are hosted services that can do this for you, but I've yet to see any self-hosted platforms for people with no IT knowledge. It is the world we live in, and deviating from the status quo often means relinquishing flexibility, like a walled garden. Those projects often die fast because people with the knowledge to set things up properly don't like the single way that is required by the app. There is probably another larger platform to solve that problem with, but I don't think it should be an every-individual-all kind of issue to solve.

I would argue that some years ago, MFA became a basic feature. All other web services or self-hosted apps that I expose have MFA, because it is recognized universally in the industry as needed in order to stem the inherent issues with passwords. If Emby has other security issues, that's fine, fix them, but that does not negate the need for additional protection for the admin account. 8-character passwords can be cracked in under an hour now. MFA makes that information negligible.

Personally, I'm fine with having HTTP for local traffic, or for the purpose of setting up reverse proxy.  Additionally, some mechanism of tunnelling (VPN, WireGuard, ZeroTier, Tailscale, etc) pointing to HTTP is also fine (who wants to pay double-encryption compute and bandwidth costs needlessly?).

HTTPS support is provided, and is a good solution for those who are willing to open Emby up to external access.  My chief complaint with it as it currently stands is that there is no universally simple way to setup your certs.  There are a couple of good guides available, but IMO it would be nice to have native support for Let's Encrypt (if you would like this too, please vote for it!) so that your average user has to jump through fewer hoops to utilize that feature.

MFA, in principle is a very good addition to the security tool belt.  However, it still allows for insecurity (cf: SMS- and phone-based authentication), and can still suffer from human error (evil iFrames, "MFA Fatigue" attacks).  IMO, any remote administrative work should correctly integrate MFA...but only if other sensible security practices are leveraged first (secure connectivity, strong password complexity, etc).  There are also other practices/technologies like conditional access, but that's an entirely separate topic (and doesn't necessarily need to be implemented in Emby).

[rbjtech 4223]

tbh, I think MFA is only ever going to work with an HTTPS connection anyway - anybody asking a 2FA provider if they can provide their service over HTTP is going to be destined for the comedy club ...

MFA is good idea for the Admin account - nobody is disagreeing here - implement it for https - great - but if this is higher on the 'priority' list than sorting out basic security 101 then I stand by what I said above - the priority is wrong.

Re - http for local traffic within your own control - then yes, this is generally fine (no PI or confidential data to speak of).  But would I trust a 3rd party such as CF with my unencrypted traffic ?  Personally, no I wouldn't.

[horstepipe 356]

On 10/24/2022 at 11:28 AM, Przemek said:

Authentik do the same as Authelia but it's easier to install and configure.

Just a question to understand that correct;

these apps put mfa in front of web apps, so you can secure emby‘s webUI with them.

But you can‘t secure the emby apps themself with it is that correct?