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 -->
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 -->
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 -->
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 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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..
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.
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.
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.
Yes, yes, and I agree.