Allow password-less accounts which cannot be looged into without a module authorizing #222

New Issue

2026-10-05T04:05:59+02:00

adam commented

2026-10-05 04:05:59 +02:00

Similar to the unix passwd -l account to only allow su logins. Need this to do my SSO system properly.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Similar to the unix passwd -l account to only allow su logins. Need this to do my SSO system properly. ## <bountysource-plugin> Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/286465-allow-password-less-accounts-which-cannot-be-looged-into-without-a-module-authorizing?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

2026-10-05 04:05:59 +02:00

adam commented

2026-10-05 04:06:00 +02:00

Also, this could be used in conjunction with the certfile and cyrus modules.

Also, this could be used in conjunction with the certfile and cyrus modules.

adam commented

2026-10-05 04:06:01 +02:00

Uhm, just do a big hack and set a "broken" password hash? E.g. pUser->SetPass("Disabled", CUser::HASH_MD5);

(A little less ugly approach would be to add a new value to that eHashType enum which means "disabled", dunno if that is worth it)

P.S.: passwd -l just does the same: It "breaks" the password hash by prefixing it with a "!".

Uhm, just do a big hack and set a "broken" password hash? E.g. pUser->SetPass("Disabled", CUser::HASH_MD5); (A little less ugly approach would be to add a new value to that eHashType enum which means "disabled", dunno if that is worth it) P.S.: passwd -l just does the same: It "breaks" the password hash by prefixing it with a "!".

adam commented

2026-10-05 04:06:01 +02:00

I took a leaf from the Cyrus module and did just that. Would be nice to have the proper web/status hook.

I took a leaf from the Cyrus module and did just that. Would be nice to have the proper web/status hook.

adam commented

2026-10-05 04:06:02 +02:00

@md-5 what did you do to accomplish your implementation?

The cyrusauth module does to SetPass on generic creations, the problem is that a user can still come back and set a password, thus invalidating the pass through.

https://github.com/znc/znc/blob/2b8e3f997f5d1a154e9c6e8c8efb9c115834afda/modules/cyrusauth.cpp#L137-L140

@md-5 what did you do to accomplish your implementation? The cyrusauth module does to SetPass on generic creations, the problem is that a user can still come back and set a password, thus invalidating the pass through. https://github.com/znc/znc/blob/2b8e3f997f5d1a154e9c6e8c8efb9c115834afda/modules/cyrusauth.cpp#L137-L140

adam commented

2026-10-05 04:06:03 +02:00

I did the same as cyrus above

I did the same as cyrus above

adam commented

2026-10-05 04:06:03 +02:00

ok. so how are you preventing them from changing their passwords and thus bypassing your backend's password system

ok. so how are you preventing them from changing their passwords and thus bypassing your backend's password system

adam commented

2026-10-05 04:06:04 +02:00

I'm not.

I'm not.

adam commented

2026-10-05 04:06:05 +02:00

do you care? (bring serious, not snide)

do you care? (bring serious, not snide)

adam commented

2026-10-05 04:06:05 +02:00

Not really, if they want to break their SSO that is their decision :p

Not really, if they want to break their SSO that is their decision :p

adam commented

2026-10-05 04:06:06 +02:00

Logging in again with their SSO password will set their hash back to :: and make them require that pass.

Logging in again with their SSO password will set their hash back to :: and make them require that pass.

adam commented

2026-10-05 04:06:06 +02:00

I wish that loging back in via SSO would reset it back to the ::, but it doesnt as far as i can see.

Also, it sounds nice to let breaking SSO be their decision, but typically your SSO system has enforced password policies, including change frequency. If they bypass it here they can 'make it easier' for their IRC config, while lowering your security posture.

I wish that loging back in via SSO would reset it back to the ::, but it doesnt as far as i can see. Also, it sounds nice to let breaking SSO be their decision, but typically your SSO system has enforced password policies, including change frequency. If they bypass it here they can 'make it easier' for their IRC config, while lowering your security posture.

adam commented

2026-10-05 04:06:07 +02:00

I wish that loging back in via SSO would reset it back to the ::, but it doesnt as far as i can see.

My addon does

> I wish that loging back in via SSO would reset it back to the ::, but it doesnt as far as i can see. My addon does

adam commented

2026-10-05 04:06:08 +02:00

I noticed i'm on 1.4 (i install from epel) and so I'm gonna eval the 1.6 release as soon as I can.

That being said, in the scenario i listed they would have to reason to log back in with their SSO password, and thus it would never reset, so that is a mute point. It seems that a better security posture would be achieved by disabling local auth explicitly if using external auth method.

I noticed i'm on 1.4 (i install from epel) and so I'm gonna eval the 1.6 release as soon as I can. That being said, in the scenario i listed they would have to reason to log back in with their SSO password, and thus it would never reset, so that is a mute point. It seems that a better security posture would be achieved by disabling local auth explicitly if using external auth method.

adam commented

2026-10-05 04:06:08 +02:00

It seems that a better security posture would be achieved by disabling local auth explicitly if using external auth method.

Easily done with a small tweak to your SSO addon

> It seems that a better security posture would be achieved by disabling local auth explicitly if using external auth method. Easily done with a small tweak to your SSO addon

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#222