Should I log that a user changed their password?

edruid 05/15/2018. 5 answers, 3.419 views
passwords logging password-reset

Are there any security concerns with logging that a user changed their password? I'm already logging whenever an admin changes a users password for audit purposes, but is there a reason to not have a log of when each user changed their own password?

Edit: Answers to questions below

What is your expected gain from this?

Mainly forensic. The ability to see who (user_id of admin or self) changed the password in case the user claims they were hacked.

Who would have access to these logs?

System administrators and possibly a small support team.

About what kind of accounts are we talking about?

User accounts on an e-learning platform i.e. teachers and students.

Also, do you have password expiration rules?

No. I'm talking about storing when every change of password was done, not only the last change.

5 Answers

Shane Andrie 05/15/2018.

To, answer your question, No, there is no security concerns by logging a password change, but be careful what you show.

What to log?

When designing logging for Security purposes you want to address these questions:

When did the event happen?

  • The date and time the event occurred (Use the common log format)

What was the event?

  • A short description of the event (e.g Password Change)

Who triggered the event?

  • The user id, name, email or some unique identifier

Why was the even triggered?

  • This is not the same as the "What" even though many people use it that way. This is the reason the event was executed. (e.g Password changed due to policy, User manually changed password, etc). This can really good for weeding out noise.


One of the best methods for discussing what to see is via scenarios and asking the team:

  • What information does the event provide?
  • Is the event required for compliance / legal?
  • Are we logging for detective reason? (e.g Triggering a SIEM) or for corrective? (e.g Forensics after the fact)
  • Who will be looking at the logs?
  • How will we protect the logs?


James is part of the IR team, which is responsible for Made-Up Company's critical application 'Non-Existence'. James want to be able to see all password changes in order to detect changes that occur outside the normal policy process. These events will trigger and investigation if a password change happens without an incident logged by the support team. Logs will be sent to the IR SIEM appliance which will use a rule set to trigger warnings to the IR team when an incident cannot be correlated to a password change outside of a required policy change.

(Obligatorily caution for using this at a workplace. I just made this example up.)

workoverflow 05/15/2018.

There is no reason NOT to log something, but be sure you log what you NEED to log.

You can theoretically log everything the users does, (down to mouse pointer movement, clicks, and when a window is the foreground or not).

But, do you NEED to log everything? Can you log everything without sacrificing performance? Can you store the logs for a useful period of time?

There is no reason not to log when the user changes his/her password. You can remind them on a failed login that they have changed their password X days ago. Or any feature that you can build on the history, habits, and patterns of password changing.

You can even correlate the password changing with major security breaches to determine how "techy" the user is.

Sangam Belose 05/15/2018.

You can log some message to indicate that the user has changed the password along with some information like ipaddress(to track if somebody has inadvertently changed his passsword) from where he has changed the password.

Please avoid logging PII information which will lead back to specific user if the log file is leaked.

Ghost8472 05/15/2018.

Not logging them is more of a security risk than logging them, but (as everyone else has said) be careful what/how you log the info.

Other answers point out that the logs will allow your admins to detect behavior from breaches, and sending notifications to users will allow them to detect breaches individually.

I think we are all assuming that you are storing your passwords as hashes with randomized salts. Just a reminder that using randomized salts will significantly slow down an attacker's ability to crack the hashed passwords, as they have to do the full cracking process for each unique salt (which is hopefully unique to each password in the system, and each time they are changed).

If you wanted to implement some new password policies, then you could:

  • keep records (maybe not "logs") of when passwords were changed
  • keep a hashed version of the password, with its randomized salt

These allow you to later implement policies for:

  • expiration, using just the timestamp portion
  • password history, by hashing the new password with each of the historical salts, and comparing to the historical hashes, to ensure the user isn't reusing old passwords

Sentinel 05/15/2018.

One of the above answers mentions this in passing and I will emphasize the two key things you should look at:

  1. Maintain the hash list to ensure user is not reusing old pwords.
  2. Do not store when, so hackers cannot work with pword longevity info. Eg. UserX resets pword end of every month.

Related questions

Hot questions


Popular Tags