You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 31, 2021. It is now read-only.
The README already tells users to create a long, unique secret during setup, however this is not enforced by flood. It is also not immediately obvious how grave the security implications are if this is not done.
Expected Behavior
Flood should refuse to start or at least print a visible warning (maybe even in the UI) if the default secret has not been changed.
Current Behavior
Flood starts and runs without any warnings.
Possible Solution
Some ideas:
refuse to start (I would recommend this)
print a warning in the console (not very visible, some might ignore this)
show a warning header in the user interface to logged in users (requires a lot of extra work)
automatically create a random secret on the first start
Context
I think it would be really important to implement something like this because the security implications of running flood with the default secret are really bad and this might not be obvious to many.
If you know the secret, you can sign a JWT token for yourself and get full access to the webinterface, you don't even need to know the name a valid user. In combination with issue #588, this means if you don't change the secret, anyone can most likely take over your server and execute arbitrary code. It should really be ensured in code that this cannot happen. Many will only skim the README or simply forget to change the secret in their production configuration.
The text was updated successfully, but these errors were encountered:
jr64
changed the title
stop flood from starting or warn users if CONFIG.secret has not been changed
Stop flood from starting or warn users if CONFIG.secret has not been changed
Dec 17, 2017
If you provide a default, people WILL use it. It is a security
hazard if people use the default private psk to sign auth messages.
Flood usuaully has privileges to files. A potential intruder may
download files inside Flood and that will lead to arbitrary remote
code execution, not to mention rTorrent's rich and powerful script
interface.
This change makes sure there is NO default and build shall NOT pass
before user provides a secret.
Bug: Flood-UI/flood#589
The README already tells users to create a long, unique secret during setup, however this is not enforced by flood. It is also not immediately obvious how grave the security implications are if this is not done.
Expected Behavior
Flood should refuse to start or at least print a visible warning (maybe even in the UI) if the default secret has not been changed.
Current Behavior
Flood starts and runs without any warnings.
Possible Solution
Some ideas:
Context
I think it would be really important to implement something like this because the security implications of running flood with the default secret are really bad and this might not be obvious to many.
If you know the secret, you can sign a JWT token for yourself and get full access to the webinterface, you don't even need to know the name a valid user. In combination with issue #588, this means if you don't change the secret, anyone can most likely take over your server and execute arbitrary code. It should really be ensured in code that this cannot happen. Many will only skim the README or simply forget to change the secret in their production configuration.
The text was updated successfully, but these errors were encountered: