Sensitive Module Data #16

Closed
opened 2026-10-05 03:54:00 +02:00 by adam · 4 comments
Owner

As I just saw potentially sensitive data for user modules is stored as cleartext, eg. in the nickserv module.
Generally it's not that big a deal, since on a properly configured server, only few people should have access to the data.

Anyhow, it would be more secure to store any kind of password (if it has to be stored on HDD like Nickserv-Password apparently does) at least hashed.

Compare:

/home/$zncuser/.znc/users/$user/moddata/nickserv/.registry where the nickserv password, if entered ist stored as cleartext on a default ZNC setup..

As I just saw potentially sensitive data for user modules is stored as cleartext, eg. in the nickserv module. Generally it's not that big a deal, since on a properly configured server, only few people should have access to the data. Anyhow, it would be more secure to store any kind of password (if it has to be stored on HDD like Nickserv-Password apparently does) at least hashed. Compare: /home/$zncuser/.znc/users/$user/moddata/nickserv/.registry where the nickserv password, if entered ist stored as cleartext on a default ZNC setup.. <!-- github-sync-id:1322945 -->
adam closed this issue 2026-10-05 03:54:00 +02:00
Author
Owner

Nickserv module should send the password to erm... Nickserv of the given network.
Question: how to unhash the password from this hashed .registry?

Nickserv module should be able to login using your credentials, in some way (even if it's public/private key instead of password). So well, it should have access to these credentials.

Exception could be server-side configuring to give access to your IP. Some services support that.

Nickserv module should send the password to erm... Nickserv of the given network. Question: how to unhash the password from this hashed .registry? Nickserv module should be able to login using your credentials, in some way (even if it's public/private key instead of password). So well, it should have access to these credentials. Exception could be server-side configuring to give access to your IP. Some services support that. <!-- github-comment-id:1700417 -->
Author
Owner

Maybe it could be encrypted with the user's sha256 hash in znc.conf?

But then it could just be decrypted the same way, since having access to user/moddata/nickserv/ would likely mean you have access to znc.conf as well, so trying to encrypt it is useless.

Suggestion: use a randomly generated alphanumeric 25 character password for nickserv, and save it somewhere (like LastPass or 1Password). This way at least you're not using the same password everywhere and if your moddata/nickserv/ password is hijacked, the worst you could lose is your irc nick. And maybe you can even get that back since your email doesn't use the same password now.

Maybe it could be encrypted with the user's sha256 hash in znc.conf? But then it could just be decrypted the same way, since having access to user/moddata/nickserv/ would likely mean you have access to znc.conf as well, so trying to encrypt it is useless. Suggestion: use a randomly generated alphanumeric 25 character password for nickserv, and save it somewhere (like LastPass or 1Password). This way at least you're not using the same password everywhere and if your moddata/nickserv/ password _is_ hijacked, the worst you could lose is your irc nick. And maybe you can even get that back since your email doesn't use the same password now. <!-- github-comment-id:1701355 -->
Author
Owner

Isn't your suggestion really a best practices for the end user? Not really something for ZNC to implement? Honestly, there's only so much you can do if someone can access your file system.

Isn't your suggestion really a best practices for the end user? Not really something for ZNC to implement? Honestly, there's only so much you can do if someone can access your file system. <!-- github-comment-id:1706479 -->
Author
Owner

Yes, yes, and I agree.

Yes, yes, and I agree. <!-- github-comment-id:1709391 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#16