search

9p4 / jellyfin-plugin-sso

This plugin allows users to sign in through an SSO provider (such as Google, Microsoft, or your own provider). This enables one-click signin.
GNU General Public License v3.0
590 stars 27 forks source link

Update configPage.html - Provider description #177

Open v3DJG6GL opened 5 months ago

v3DJG6GL commented 5 months ago

I just accidentally discovered that the recommended default provider setting can cause a serious security issue: If Jellyfin.Server.Implementations.Users.DefaultAuthenticationProvider is used, every newly created user has no password by default. Therefore, passwordless login is possible for all these users. I think it would be wise to at least mention this as it is not really mentioned at all.

In addition, I think it would be good to mention Jellyfin.Plugin.LDAP_Auth.LdapAuthenticationProviderPlugin as another option that might be more suitable for most use cases.

9p4 commented 5 months ago

Huh, the newly created user should have a random password:

https://github.com/9p4/jellyfin-plugin-sso/blob/2724d64de86c35f686f83bb02655d5c3c1a1475f/SSO-Auth/Api/SSOController.cs#L746

djsime1 commented 5 months ago

I just checked on my instance and confirmed SSO users have no password, this is a serious security issue. JF 10.8.13, SSO 3.4.0.0

9p4 commented 5 months ago

Your plugin seems a few years out of date. Can you please update to 3.5.2.3?

djsime1 commented 5 months ago

So much for the plugin updater task, my bad.

9p4 commented 5 months ago

Please let me know if new users continue to not have a password.

v3DJG6GL commented 5 months ago

Could it be that an older version from around the middle of last year had a bug where no random password was generated? I've done some further analysis and it seems that accounts created between mid-2023 (where I had my Jellyfin instance set up) and towards the end of the year have no passwords.

Another account created two months ago does not seem to be affected by this issue.

Also, all these older Jellyfin accounts do not seem to generate a random password even now if the provider is set to Jellyfin.Server.Implementations.Users.DefaultAuthenticationProvider - even though the current version of the SSO plugin is used.

Only when the provider is changed to Jellyfin.Plugin.LDAP_Auth.LdapAuthenticationProviderPlugin and these users log in again, they get a random password set.

9p4 commented 5 months ago

The version released Aug 5, 2023 (3.5.0.0) fixed the issue.

Sorry for the previous response, I just got your reply right before I hit send.

Also, all these older Jellyfin accounts do not seem to generate a random password even now if the provider is set to Jellyfin.Server.Implementations.Users.DefaultAuthenticationProvider - even though the current version of the SSO plugin is used.

The password is only set when new users are being created. Since the users are already existing, the plugin does not touch their passwords.

Only when the provider is changed to Jellyfin.Plugin.LDAP_Auth.LdapAuthenticationProviderPlugin and these users log in again, they get a random password set.

That is weird. I wonder why that happens.

Maybe this PR can be updated to mention the LDAP provider string instead of the security warning?

v3DJG6GL commented 5 months ago

Sorry for the previous response, I just got your reply right before I hit send.

No worries, thanks for your fast replies :)

The version released Aug 5, 2023 (3.5.0.0) fixed the issue.

hmmm... I wonder how many users were created while using with SSO plugin versions affected by this bug and didn't realize it until today that their accounts are accessible without password...

The password is only set when new users are being created. Since the users are already existing, the plugin does not touch their passwords.

That is weird. I wonder why that happens.

I don't know it either. But how about implementing a similar mechanism for the default provider to set a random password at least once with the next update? EDIT: If no password is set at all I'm a bit worried about how many Jellyfin users might not be aware of this issue....

Maybe this PR can be updated to mention the LDAP provider string instead of the security warning?

Yes, for sure! I'll update the PR since this doesn't seem to affect recent plugin versions.

9p4 commented 5 months ago

I don't know it either. But how about implementing a similar mechanism for the default provider to set a random password at least once with the next update?

I think that this is a good idea.