[Bug]: Password Reset URLs printed to User.log without masking

[matthewjhands]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

When a user requests a password reset email, the complete contents of the mail is logged to Cronicle's User.log log file.

This includes the password reset link, which to my mind should be handled as securely as a password itself, and so shouldn't be printed to Cronicle's logs without being masked, as anyone who had access to those logs could reset any user's password to gain access to their account.

Could we add masking to these logs please?

https://cwe.mitre.org/data/definitions/532.html

Operating System

RHEL8

Node.js Version

v18.20.6

Cronicle Version

v0.9.73

Server Setup

Multi-Primary with Workers

Storage Setup

NFS Filesystem

Relevant log output

[1739960231.842][2025-02-19 11:17:11][$HOST][63577][User][debug][6][Email sent successfully][{"name":"recover_password","data":"To: $USER_EMAIL\nFrom: $CRONICLE_EMAIL\nSubject: Forgot your Cronicle password?\n\nHey $FULL_NAME,\n\nSomeone recently requested to have your password reset on your Cronicle account.  To make sure this is really you, this confirmation was sent to the e-mail address we have on file for your account.  If you really want to reset your password, please click the link below.  If you cannot click the link, copy and paste it into your browser.\n\nhttps://$HOST/#Login?u=$USERNAME&h=24XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9d\n\nThis password reset page will expire after 24 hours.\n\nIf you suspect someone is trying to hack your account, here is the information we gathered from the request:\n\nDate/Time: 2/19/2025, 11:17:11 AM\nIP Address: 10.XX.XX.XX\nUser Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36\n\nRegards,\nThe Cronicle Team\n"}]


NOTE that I have redacted the output by hand!

Code of Conduct

• I agree to follow this project's Code of Conduct

[jhuckaby]

Well, honestly this is "as designed" behavior. That is a debug log entry, for debugging purposes. If you are running Cronicle in production, you should drop your debug level way down so it doesn't log those kinds of things:

https://github.com/jhuckaby/Cronicle/blob/master/docs/Configuration.md#debug_level

You can go all the way down to level 1 which is the quietest. The good thing about this system is that it will still log all transactions and errors (the important stuff), but only quiet down the debug entries.

That should prevent any private info from being logged.

[mikeTWC1984]

@jhuckaby curious is it possible to mute transaction logging, just print errors?

[jhuckaby]

@mikeTWC1984 Not currently, but that functionality could be added fairly easily.

[matthewjhands]

Thanks for the insight @jhuckaby .

In that case then I'd suggest that config.json has a lower debug level "by default", so that unsuspecting new users of Cronicle don't start logging secrets in PROD unintentionally.

Would it be possible add a flag in config.json to mask secrets in all logs conditionally? Or can I add a custom mask (using a regex) somewhere?

[jhuckaby]

That's fair I guess. I suppose I have the debug_level defaulting to 9 because it REALLY helps me diagnose and troubleshoot my users' issues. But I suppose I could just ask them to increase their debug level and reproduce their issue.

I have just released Cronicle v0.9.75 which has the following changes:

• The default debug_level is now set to 5. This will only take effect for new installs. Cronicle does not touch any existing config files on upgrade.
• The bin/debug.sh script will now temporarily set the debug level to 9 for that session, so if you run it in debug mode in the Terminal (which should never happen on production) it will log everything.
• I bumped pixl-server to v1.0.45 which comes with a new log filtering feature:

https://github.com/jhuckaby/pixl-server#log-filtering

While this doesn't have a full regexp filter, you can use it to omit entire log components or categories. For example:

"log_filters": {
	"component": {
		"*": true,
		"User": false,
		"WebServer": false
	}
}

This would log everything except the [WebServer] and [User] components. I believe this would also prevent most if not all "secrets" from being logged.

[matthewjhands]

Many thanks. As always thanks for writing/supporting such a great product and for turning around changes so quickly.

What secrets are you aware of in the WebServer log? I just had a look in mine and couldn't see any.

[jhuckaby]

What secrets are you aware of in the WebServer log? I just had a look in mine and couldn't see any.

Oh, I guess it depends on what you consider to be secrets. I was thinking of things like API Keys, which if sent as HTTP headers would be logged in the WebServer log (depending on the debug level of course).

If you also consider user session IDs to be secret, I believe those may also be logged under the [API] component.