Flood: Make authentication optional

[onedr0p]

I know this is well rooted in your app but I would very much like to disable auth / passport and use basic auth on my reverse proxy instead.

Thanks!

[ghost]

+1

[jfurrow]

I'll consider making this optional in the future, but I think the vast majority of users benefit from the included authentication.

Right now there are higher priority issues for me to work on, but if any of you are willing to submit a PR for optional JWT authentication, I'll gladly review it!

[ghost]

OP You can always use a basic auth before accessing the flood login #useless

[jfurrow]

I'm going to close this for now, but feel free to submit a PR for optional JWT auth!

[onedr0p]

okay :(

[jfurrow]

I'm reopening this as it's been requested by multiple users. Let's make the authentication optional, but enabled by default.

[jkaberg]

An simple and optional config value in config.js with something like auth = disabled (which defaults to true if not defined) would be very nice indeed.

In my case I'm hideing most stuff behind an reverse proxy with 2FA, so additional authentication in Flood is just cumbersome :smile:

[sachaw]

Might be easy to just pass plaintext credentials to the server behind the scenes if an option in the config (like mentioned above) is set, this removes any potential exploit that may arise from editing the security system to allow for sessions to be generated without proper authentication.

[dcousens]

FWIW, the passphrase can be left blank as is.

[sachaw]

Bonus, just pass the username then.

[1activegeek]

Hoping to help revive an older thread. While I don't know enough to help code this, I would definitely like to see this. As someone already mentioned, I have better auth already built into my nginx RP setup. I'd love to be able to remove the extra auth screen.

[dcousens]

~The simplest approach for this might be to have the config file provide some "defaulted" credentials and an immediate re-direct.~

edit: I think I meant something else, but this is a bad idea as written

[noraj]

Let's make the authentication optional, but enabled by default.

I think this is the better approach.

Because making some default credentials and a lot of users will never change them. Make them forced to change the password bu the default account name will be the same everywhere and bad guy will have no pain to bruteforce weak password.

It's maybe more work do make authentication optional but it seems more secure than providing default credentials. And this will be cleaner.

[GottZ]

from a security standpoint: would you say the flood login is tamper proof? if you cannot say „yes“ being 100% sure about it, making this optional might be a wise decision.

i'll most likely audit the login part of floods code in a few days.
after all i run this publicly available on my home server with just an nginx with basic auth and ssl in front of it.

so to be explicit:
to me, using basic auth in nginx in front of flood is just a prevention of yet another possible attack vector.
in addition to that, it does not reveal what's behind a certain sub domain one could publicly request since all it shows is a basic auth prompt.

i don't even reveal server tokens.

PS:
well. who knows. if during my audit i realise the style of code in flood is tempting to start contributing to this project, you might find some pull requests by me in future ;)

[jfurrow]

@GottZ No, unfortunately I cannot say with any confidence that Flood is 100% tamper proof. I'm not a security expert, so your audit would be greatly appreciated!

if during my audit i realise the style of code in flood is tempting to start contributing to this project, you might find some pull requests by me in future ;)

Let's hope so! 🤞

[noraj]

From my POV, I don't see the interest of disabling Flood auth for enabling basic auth in most cases except for hiding the app when it is exposed on internet or if basic auth is coupled with PAM auth.
To get a stronger auth system a nice idea the user can deploy, is desabling Flood auth (when it will be available) and configure Client Side Certificate Authentication.

[Daiyousei]

I think It would be better to allow Flood to trust the reverse proxy in front of it (if any).

We could use it for exemple if we have some kind of auth in front of it (Basic/SAML/Certificate, whatever, you name it), it would be good to be able to use it for the fearue #216

[GottZ]

so far my audit tells me you have pretty old dependencies in use.
passport and passport-jwt are what you use for authentication. fine by me but not up2date.
feel free to test and merge this pull request: https://github.com/jfurrow/flood/pull/650
obviously i could not upgrade from webpack 3 to 4 aswell as react 15 to 16 and d3 from 3 to 5 without actually doing big changes to the code base.
but oh well.. looking good so far.

hint hint: node-check-updates

[noraj]

Note: by disabling user authentication (IF you don't replace it with another authentication method like PAM for example) you will also disable multi-user capabilities.
So if you have 3 users and you suddenly change the config to disable authentication, what should happen? Keep the 1st user and remove all others? No, this is nonsense.
I think it should not be possible to disable authentication but only to switch to another mechanism like PAM or authentication forwarding to a reverse proxy like nginx.

[noraj]

I don't think that the debate should be around disabling authentication but rather for supporting Alternative authentication methods. What do you think @jfurrow?

[wopian]

What if you don't use the multi-user feature (they all show the same torrent list anyway). No point in password protection if the Flood instance is local only and not accessible externally.

[GottZ]

nginx auth_request works fine btw. https://share.home.gottz.de/2018/05/2018-05-27_01-47-17.mp4
it's just a bit hard to setup because you either have to setup a third party SSO provider, self host one or build one yourself. i kinda did the self made route now.
totally better than basic auth since it does not prompt you for login if you get a 401 from flood and you just need to login once for multiple sub domains / projects

[bbashy]

@wopian Personally, I think all services should have authentication, even if it is only LAN? DNS rebinding could well come into this: https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325

[GottZ]

that's why i'd recommend using nginx auth_request for all your home hosted things and do an internal redirect that's dns independent.

[1activegeek]

I think the bigger point here would be to create the option. To each his own on CHOOSING their level of security. Setting a _responsible_ default, is on the developer to "do security right", but creating the options that the users are looking for, is on the developer to "create good/flexible software". In this case, many of us are using some other mechanism to restrict access - or some don't want auth, period. Anyone making these decisions takes the risk balance into their own hands when changing from the _responsible_ default setting.

It's sort of like saying Windows shouldn't have an option to disable a password authentication to the machine. But there are use cases that dictate or necessitate the need of such a practice.

In my scenario, I'm using nginx to redirect to an auth server/service before anyone gains access to anything on the domain. So DNS rebinding is not an issue in this case, and auth is not a security issue as I've setup a different auth. For me, I'd to access this service without ANOTHER login required, even if it is typing admin with no password. The user experience is undesirable. And let's be honest, these days UX trumps all! 😆

[bbashy]

@GottZ @1activegeek Agreed. Does ruTorrent support multiple auth types? I've only used it with basic_auth.

[noraj]

I think this is no more a discussion, we more or less all agree that authentication should be enable by default and can be made optional bu user.

I'm not a dev, I don't know anything about node.js, I'm only here to manage issues. Jfurrow is the main dev but he is very busy and have only a few hours a month for this project.
Remember this is an open source project and that all contributions are made by member on their free time, so anyone wanting this feature can make a PR. We would proudly review and merge it.

[1activegeek]

Agreed - is there a way to just lock this thread? This way it doesn't go on, but can still be managed by the repo as a an enhancement, per the labeling?

[jesec]

Resolved by https://github.com/jesec/flood/commit/06e6d1e3f7bf2aef068d256b0c7a6dd1280567a0.

You may close the issue if it is no longer relevant.

[onedr0p]

Yep, thanks @jesec !