Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: Protect GUI with an optional simple user/pass login. #1726

Closed
tubalainen opened this issue Sep 7, 2021 · 42 comments
Closed

FR: Protect GUI with an optional simple user/pass login. #1726

tubalainen opened this issue Sep 7, 2021 · 42 comments
Labels
enhancement New feature or request stale

Comments

@tubalainen
Copy link
Contributor

Describe what you are trying to accomplish and why in non technical terms
Protect the GUI from unauthorized access with a simple username/password login.

Describe the solution you'd like
Protect the events in Frigate from being deleted by non authorized users.

Describe alternatives you've considered
Network segmentation seems a bit drastic.

@tubalainen tubalainen added the enhancement New feature or request label Sep 7, 2021
@mitchross
Copy link
Contributor

Just use authelia with ngnix. https://mitchross09.medium.com/how-i-self-host-my-own-sites-and-applications-with-unraid-docker-authelia-and-cloudflare-1f0d8e6f8912

@xiki808
Copy link

xiki808 commented Sep 9, 2021

+1

Would be nice to have some type of auth for API too.

@mitchross
Copy link
Contributor

+1

Would be nice to have some type of auth for API too.

You don't need it. Just use authelia. Don't reinvent the auth wheel.

@xiki808
Copy link

xiki808 commented Sep 10, 2021

Thanks for the suggestion. IMO that's an overkill. Unfortunately I'm not very familiar with python, but I would assume there are libraries to manage token based auth.

@tubalainen
Copy link
Contributor Author

+1
Would be nice to have some type of auth for API too.

You don't need it. Just use authelia. Don't reinvent the auth wheel.

Well, the auth wheel using Autheria and ngnix is not a "simple plugin" in Home Assistant Supervised. Like Frigate after adding your cameras to the config.

Again, sorry for not having the correct data at hand. But isnt the majority of the frigate users Home Assistant users running Home Assistant Supervised if that is true - then how would our mainstream majority group of users go about protecting their frigate install?

Frigate uses ngnix if I am not mistaken, are you suggesting to implement yet another ngnix and autheria and put that in front of Frigate?

A agree with xiki808, its way overkill.

Frigate is becoming a new and up-and-coming "NVR++" solution. And we cannot protect the installation with just a few parameters in the config file.

@mitchross
Copy link
Contributor

+1
Would be nice to have some type of auth for API too.

You don't need it. Just use authelia. Don't reinvent the auth wheel.

Well, the auth wheel using Autheria and ngnix is not a "simple plugin" in Home Assistant Supervised. Like Frigate after adding your cameras to the config.

Again, sorry for not having the correct data at hand. But isnt the majority of the frigate users Home Assistant users running Home Assistant Supervised if that is true - then how would our mainstream majority group of users go about protecting their frigate install?

Frigate uses ngnix if I am not mistaken, are you suggesting to implement yet another ngnix and autheria and put that in front of Frigate?

A agree with xiki808, its way overkill.

Frigate is becoming a new and up-and-coming "NVR++" solution. And we cannot protect the installation with just a few parameters in the config file.

Its not really overkill. You are using ngnix reverse proxy manager to listen to a sub domain. Then using authelia to front the incoming request. Its two docker containers and a supporting MySQL db. https://docs.ibracorp.io/all-guides-in-order/documentation/authelia

I believe you can use https://www.cloudflare.com/teams/access/ too

Otherwise if you can try trafiek + https://github.com/thomseddon/traefik-forward-auth

Finally, the simplest but most insecure -> https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

@stale
Copy link

stale bot commented Oct 12, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 12, 2021
@stale stale bot closed this as completed Oct 15, 2021
@Ocramius
Copy link

Landing here, throwing in my 2 cents.

I don't use nginx (way too complex and super-annoying to configure), but I do use docker-compose and traefik:2.x.

It's possible to configure an authentication HTTP middleware for frigate by adding labels to your services:

    labels:
      - "traefik.enable=true"
      - "traefik.port=80"
      - "traefik.http.routers.frigate.rule=Host(`my.exposed.host.name`)"
      - "traefik.http.routers.frigate.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=myusername:<my-hashed-pass>"
      - "traefik.http.services.frigate.loadbalancer.server.port=5000"
      - "traefik.http.routers.frigate.tls.certresolver=le"
      - "traefik.http.routers.frigate.tls=true"

That should give you TLS + HTTP basic auth :-)

@mitchross
Copy link
Contributor

Landing here, throwing in my 2 cents.

I don't use nginx (way too complex and super-annoying to configure), but I do use docker-compose and traefik:2.x.

It's possible to configure an authentication HTTP middleware for frigate by adding labels to your services:


    labels:

      - "traefik.enable=true"

      - "traefik.port=80"

      - "traefik.http.routers.frigate.rule=Host(`my.exposed.host.name`)"

      - "traefik.http.routers.frigate.middlewares=auth"

      - "traefik.http.middlewares.auth.basicauth.users=myusername:<my-hashed-pass>"

      - "traefik.http.services.frigate.loadbalancer.server.port=5000"

      - "traefik.http.routers.frigate.tls.certresolver=le"

      - "traefik.http.routers.frigate.tls=true"

That should give you TLS + HTTP basic auth :-)

How are you hashing your password? That step might be needed to be explicitly stated in case someone runs by this thread.

@Ocramius
Copy link

In my case, I run php -e 'echo password_hash("my-password-here", PASSWORD_DEFAULT);'

Here's what the output looks like:

https://3v4l.org/uQD3j

Not sure if there are better alternatives out there, but PASSWORD_DEFAULT is a decent default value, as it gets upgraded with newer algorithms, when available.

@zombielinux
Copy link

This looks like a valid solution, it looks like the required hashing is MD5, SHA1, or BCrypt. Its been a while since I've seen how secure those hashes are, but traefik also supports a file that one could use in its place.

@MartnIV
Copy link

MartnIV commented Aug 31, 2022

Landing here, throwing in my 2 cents.

I don't use nginx (way too complex and super-annoying to configure), but I do use docker-compose and traefik:2.x.

It's possible to configure an authentication HTTP middleware for frigate by adding labels to your services:

    labels:
      - "traefik.enable=true"
      - "traefik.port=80"
      - "traefik.http.routers.frigate.rule=Host(`my.exposed.host.name`)"
      - "traefik.http.routers.frigate.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=myusername:<my-hashed-pass>"
      - "traefik.http.services.frigate.loadbalancer.server.port=5000"
      - "traefik.http.routers.frigate.tls.certresolver=le"
      - "traefik.http.routers.frigate.tls=true"

That should give you TLS + HTTP basic auth :-)

Would you have a complete guide on how to put this in motion?
Im intressted to secure it but im a complete noob on this.

Does this prevent randoms to use the local ip as well?

@Ocramius
Copy link

Would you have a complete guide on how to put this in motion?

This is documented in Traefik's docs

Does this prevent randoms to use the local ip as well?

Yes: I currently also use a middleware to perform OAuth login via Google/GitHub, and it applies to other family members too. They need to log in with their account, before accessing locally exposed web services.

@MartnIV
Copy link

MartnIV commented Aug 31, 2022

@blakeblackshear
Is this request been refused?
Even a password written clear on the docker config would be something.

@mitchross
Copy link
Contributor

@blakeblackshear Is this request been refused? Even a password written clear on the docker config would be something.

Frigate shouldnt be responsible for auth. You can do auth in Home Assistant. If you using ngnix or traefik, they each have their own auth modules. A simple google search for traefik / ngnix auth, or traefik / ngnix http basic auth.

https://ahmet.im/blog/docker-http-basic-auth/

@MartnIV
Copy link

MartnIV commented Aug 31, 2022

Actually, i dont understand when you say Frigate should not be responsible of it. Not that I take anything as granted. Just generaly speaking of hosted tools, I dont see much tools not having any auth system even if they do not hold sensitive data.
The nginx/traeffik way seems more the exception than the rule.

Thanks for the link, im hosting frigae on its own, without HA, without nging or treffik either. Ill try to install one of these and try to secure it like this.

To come back to the question, it is just a question about a closed request that doenst seems to have any proper anwser.
Or none that I can see here.

@NickM-27
Copy link
Collaborator

At this time we are not interested in implementing a first party auth system. To build an auth system that is secure and up to par with standards would take a lot of work and maintenance; especially as more requests would be made on top of the initial system to add analogous features.

Meanwhile, through existing options like NginxProxyManager, Traeffik, etc, secure access can easily be setup (also easily setup for more than just frigate with the same service).
On top of that, there are options like Oauth2proxy which make sign in with third party companies (like Google) a breeze which illustrate the many options already available.

We don't want to duplicate efforts that are already available in a solution that fully works with frigate. This is one of the many advantages of frigate being built in docker.

@Ocramius
Copy link

My 2 cents: even if frigate implemented authentication, I wouldn't trust it, and would rather defer to a gateway.

This is not mistrust in the maintainers, but rather encouragement of letting them work on what they do best 💪

@MartnIV
Copy link

MartnIV commented Sep 1, 2022

@NickM-27 I understand. Ill check how to implement one of these solutions.

@Ocramius For a local protection with my local network context, I would. Of course I'm not talking about a security level enough to open the port to the outside.

@skupi20
Copy link

skupi20 commented Jan 20, 2023

As others said it would be nice to have simple user authentication, not for outside connection. It can be done with different solution. But for different privileges for specific user. At least for configuration, logs, deleting media, access for specific camera etc..

@heisenberg2980
Copy link

heisenberg2980 commented Mar 9, 2023

Landing here, throwing in my 2 cents.

I don't use nginx (way too complex and super-annoying to configure), but I do use docker-compose and traefik:2.x.

It's possible to configure an authentication HTTP middleware for frigate by adding labels to your services:

    labels:
      - "traefik.enable=true"
      - "traefik.port=80"
      - "traefik.http.routers.frigate.rule=Host(`my.exposed.host.name`)"
      - "traefik.http.routers.frigate.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=myusername:<my-hashed-pass>"
      - "traefik.http.services.frigate.loadbalancer.server.port=5000"
      - "traefik.http.routers.frigate.tls.certresolver=le"
      - "traefik.http.routers.frigate.tls=true"

That should give you TLS + HTTP basic auth :-)

Does this solution with traefik avoid someone within your network being able to access Frigate using its local ip address and port 5000 or do you need an extra layer to achieve that? could you share your docker-compose.yml file?

@Ocramius
Copy link

I don't expose frigate on port 5000: only via HTTPS through traefik.

Unless a malicious actor gets access to the docker network itself, it should be OK.

Generally don't leave stuff with open ports lying around, even if in LAN 😁

@heisenberg2980
Copy link

You can do auth in Home Assistant

@mitchross I was able to protect Frigate using basic authentication with Caddy just to realise the Home Assistant Frigate card (https://github.com/dermotduffy/frigate-hass-card) doesn´t work as it requires Frigate with port 5000 exposed to be able to show the video/snapshots/recordings in Home Assistant

@Ocramius do you use Home Assistant and this card by any chance? any idea how to make it work without exposing port 5000?

@Ocramius
Copy link

@heisenberg2980 no home assistant: that's something you should report on the card's project

@heisenberg2980
Copy link

heisenberg2980 commented Mar 12, 2023

@Ocramius thank you for the quick response, I will try to report it in the Home Assistant Frigrate integration project, but as Frigate doesn´t have any authentication on its own, I guess it is normal that anything that connects to Frigate (like Home Assistant Frigate integration) is not prepare to manage authentication and it just accesses Frigate using its local IP and port

EDIT: issue open to Home Assistant Frigate integration: blakeblackshear/frigate-hass-integration#449

@heisenberg2980
Copy link

heisenberg2980 commented Mar 14, 2023

@Ocramius as I expected, the answer I got in the issue I created for the Home Assistant Frigate integration has been answered with "this is not an issue with the integration, the backend (Frigate) needs to support authentication, or the integration cannot use it" and I think that is correct.

Taking into consideration the popularity of Frigate and how many people have it running at home (and I suspect this will only increase as it is an amazing piece of software), I think some basic authentication should be added to the UI. Having something with a port exposed in your local network without any type of authentication, and specially Frigates which manages camera feeds, is a bit worrying. Just as an example, any device within the network (including IOT devices) could access Frigate and send all the data (real time video, snapshots, recordings, etc) to an internet server, and this device would only need to do a quick scan of the network to find an IP address with port 5000 open, so this is basically an open door for scammers.

@NickM-27 any thoughts?

Note: I am happy to be corrected here, but I believe none of the solutions proposed (i.e. adding a reverse proxy and blocking port 5000) can be implemented without loosing access to other components connected to Frigate (like the Home Assistant integration).

@tubalainen
Copy link
Contributor Author

Hi guys.
Our fearless coders does not want to implement basic auth to the existing container leaving Frigate exposed to port 5000 for all networks with access to that host. @NickM-27 was quite clear on his standpoint here. Basic auth would be followed by other requests and "analogous features".

Frigate as a "secure NVR solution", especially in bigger networks and/or non-home context will be quite hard hence clips can be removed, configuration altered and the Frigate NVR-system taken down by anyone with the ip/hostname and port. Just navigate to http://:5000

If exposed to a public network such Internet its a no-brainer to ensure some sorts of auth, for example via a RevProxy solution etc.

I would personally love for a simple "basic auth" solution to be built in to Frigate to protect it from misuse. NGINX is part of the architecture so it would be quite easy feat. If we decide to "stop with Basic Auth".
https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

@Ocramius
Copy link

@Ocramius as I expected, the answer I got in the issue I created for the Home Assistant Frigate integration has been answered with "this is not an issue with the integration, the backend (Frigate) needs to support authentication, or the integration cannot use it" and I think that is correct.

Oof, this is why I don't use custom integrations in Home Assistant: it will basically open up anything to the outside, often unauthenticated.

That's why I put Traefik in front of my HA instance, and it cannot get out of its own little VLAN corner, where it shall be stay in punishment forever.

Putting Traefik in front of your services is good practice.

@NickM-27
Copy link
Collaborator

Having something with a port exposed in your local network without any type of authentication, and specially Frigates which manages camera feeds, is a bit worrying. Just as an example, any device within the network (including IOT devices) could access Frigate and send all the data (real time video, snapshots, recordings, etc) to an internet server, and this device would only need to do a quick scan of the network to find an IP address with port 5000 open, so this is basically an open door for scammers.

This is an example of poor network design if you are trying to be conscious of security. It's being presented as of this is the way it has to be done but that's not true.

There are many tools including VLANs, docker networking tools, reverse proxies, etc. which provide security, restrict network communication, remove unrestricted access to devices on the network, etc. which are highly recommended if you are trying to create a secure local network, and recommended even if frigate did also have an auth system.

I'm not saying there's NO reason for frigate to have this, but presenting it as though it's the only option to secure frigate is incorrect and unrealistic. Even a simple auth system (frontend and API) is a lot of work and requires continuous testing / verification which is time that maintainers of frigate may not have. IMO a bad / rushed auth system is worse than none as it creates a false sense of security for users.

@blakeblackshear
Copy link
Owner

Having basic auth without TLS is like setting up a password protected system and just putting the password on a sticky note on the monitor. The small fraction of frigate users who are running TLS for their local network surely also know how to setup wireguard or something similar to secure communication between machines on their local network.

@mitchross
Copy link
Contributor

Cloudflare Tunnels and https://developers.cloudflare.com/cloudflare-one/applications/ is a very simple way to add sso with very minimal configuration.

@heisenberg2980
Copy link

heisenberg2980 commented Mar 16, 2023

@NickM-27 @blakeblackshear what I am trying to say is Frigate is not following the standard basic authentication mechanism that almost all other products (i.e. pihole, portainer, influxdb, just to name some examples) are using, and while it is true that basic authentication without TLS is not secure, it is much better than no authentication (in the same way that a password protected system with the password on a sticky note in the monitor, while really poor security it is better than no password at all, as at least avoid remote attacks and it requires the attacker to be physically present in the room).

With basic authentication an hypotetical IOT devices in the network trying to send Frigate data to an internet server would need to sniff the traffic between other device and Frigate during the login negotiation to be able to extract the credentials, which is not trivial and increases the complexity of the attack by various order of magnitude in comparison to just scan devices in the network with port 5000 open.

I am still trying to figure out how to secure my Frigate instance without loosing the Home Assistant integration, so my guess is most people with a similar setup won´t even bother and will just have frigate with port 5000 exposed in their networks

@NickM-27
Copy link
Collaborator

Like has been said, there are many tools to restrict which devices can communicate and how the network(s) can be used to alleviate this concern. It seems the issue is being presented as if no security at all or frigate providing its own auth are the only two options which is simply not the case.

@blakeblackshear
Copy link
Owner

With basic authentication an hypotetical IOT devices in the network trying to send Frigate data to an internet server would need to sniff the traffic between other device and Frigate during the login negotiation to be able to extract the credentials

This isn't even how basic authentication works. Credentials are sent in a header on every request. It is trivial to sniff that traffic. If we implement auth in the future, it will be something worth implementing.

@ehn
Copy link
Contributor

ehn commented Mar 18, 2023

This is an example of poor network design if you are trying to be conscious of security. It's being presented as of this is the way it has to be done but that's not true.

Counterpoint: Network design and application security are orthogonal. Every application should be secure in and of itself regardless of the network, which should enable and allow end-to-end connectivity and not get involved in application access control.

This doesn't mean that authentication and link layer encryption necessarily has to be done by Frigate itself. It could still be handled by something that "encapsulates" Frigate.

@OnFreund
Copy link
Contributor

OnFreund commented Oct 5, 2023

I realize this is most likely a lost battle, but I'd like to add my 2 cents on why I think Frigate should have an authentication system:

  1. The HA integration doesn't work well with external auth.
  2. Securing the access from HA to Frigate via network means is independent of auth, and is not enough (could be circumvented through IP Spoofing, etc...)
  3. Some of the solutions proposed do not prevent access inside the local network.
  4. HTTP Basic auth, which is the most practical external auth, is just not good enough, and definitely not user friendly (the password needs to be re-entered in many cases).
  5. I realize this is very long term, but it would make sense to also have authorization at some point. People who can view cameras and recordings, shouldn't necessarily be able to manipulate configuration. Even if it's the same person, there's a reason we don't work as root. An internal authentication mechanism would make authorization easier to develop and support.
  6. While I acknowledge and respect the concerns about rolling a robust and secure authentication system, there are many open source solutions out there that could fit. Also, this doesn't come at the expense of additional security measures when exposing Frigate to the internet.
  7. Going back to point 1 - the choice today is between a secure environment and a usable environment. I think a more nuanced trade-off is better.

Now, if the answer is "we don't have the time and resources to build something like this", I can totally understand it, but perhaps others in the community would like to step in and help (I know I would). Currently the answer is "we don't want it at all", which means no one is going to build it.

To be more practical, if I managed to convince anyone, I can suggest the following plan:

  1. Allow customization of nginx through env vars, so that ssl and basic auth could be added.
  2. Add basic auth support to the HA integration.
  3. Consider a longer term approach to replace basic auth.

Happy to hear any thoughts.

@mitchross
Copy link
Contributor

I realize this is most likely a lost battle, but I'd like to add my 2 cents on why I think Frigate should have an authentication system:

  1. The HA integration doesn't work well with external auth.
  2. Securing the access from HA to Frigate via network means is independent of auth, and is not enough (could be circumvented through IP Spoofing, etc...)
  3. Some of the solutions proposed do not prevent access inside the local network.
  4. HTTP Basic auth, which is the most practical external auth, is just not good enough, and definitely not user friendly (the password needs to be re-entered in many cases).
  5. I realize this is very long term, but it would make sense to also have authorization at some point. People who can view cameras and recordings, shouldn't necessarily be able to manipulate configuration. Even if it's the same person, there's a reason we don't work as root. An internal authentication mechanism would make authorization easier to develop and support.
  6. While I acknowledge and respect the concerns about rolling a robust and secure authentication system, there are many open source solutions out there that could fit. Also, this doesn't come at the expense of additional security measures when exposing Frigate to the internet.
  7. Going back to point 1 - the choice today is between a secure environment and a usable environment. I think a more nuanced trade-off is better.

Now, if the answer is "we don't have the time and resources to build something like this", I can totally understand it, but perhaps others in the community would like to step in and help (I know I would). Currently the answer is "we don't want it at all", which means no one is going to build it.

To be more practical, if I managed to convince anyone, I can suggest the following plan:

  1. Allow customization of nginx through env vars, so that ssl and basic auth could be added.
  2. Add basic auth support to the HA integration.
  3. Consider a longer term approach to replace basic auth.

Happy to hear any thoughts.

There are like 5 billion guides on the internet about how to secure your services with ngnix . Frigate does not need a auth system.

https://nginxproxymanager.com/guide/#quick-setup
https://www.youtube.com/watch?v=IWNypK2WxB0
https://youtu.be/4UKOh3ssQSU?si=oFGShpw5BrXqduJg
https://www.youtube.com/watch?v=P3imFC7GSr0
https://www.youtube.com/watch?v=8T68pB_Fkm4

@OnFreund
Copy link
Contributor

OnFreund commented Oct 5, 2023

There are like 5 billion guides on the internet about how to secure your services with ngnix . Frigate does not need a auth system.

I disagree, and listed 7 reasons why. I count at least 3 of those 7 that an external authentication system won't address. Additionally, Frigate is already using nginx - asking people to setup yet another instance, and try to secure it themselves, is not going to lead to a more secure outcome.

@OnFreund
Copy link
Contributor

OnFreund commented Oct 5, 2023

Also, ironically that 1st project you referenced does roll its own authentication and authorization mechanism

@fgoodwin
Copy link

If nothing else, the all or nothing approach to access is not good.
I see no issue with an using an external service for auth, but at the very least it should;

  • Support RBAC so you can grant different users different access. Even just distinct User and Admin accounts would be very helpful.
  • Be included in the basic install area of the documentation so that the recommended out of the box config is not open to the network.

@rvenson
Copy link

rvenson commented Nov 24, 2023

I comprehend that the developers would like to focus on the core implementation, but let's face the current situation: anything that gets access to the application port will have access to the configuration of the server, logs, system info, events, recordings, camera feeds and the HTTP API. For a so sensitive application, is critical the separation of concerns between multiple users, as is implemented in other systems, if there's any goal to make Frigate more mature. None of the solutions presented here can easily help with this. So, please, do not reject so strongly the implementation/integration of an Authorization system to Frigate.

@blakeblackshear
Copy link
Owner

This is a duplicate of #1074

Repository owner locked and limited conversation to collaborators Nov 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request stale
Projects
None yet
Development

No branches or pull requests