48

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.

We are not using this to support any password managing schemes such as forced password change or disallowing password reuse.

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.

What info are you storing? (not actually asked but implied)

We are storing the user id of the user whos password was changed, the user id of the user doing the change (it could be an admin or a students teacher), the time the password was changed and the URI used to change the password.

Improve this question
7
  • 5
    What is your expected gain from this? Who would have access to these logs? About what kind of accounts are we talking about?
    – Tom K.
    Commented May 15, 2018 at 13:07
  • 1
    Also, do you have password expiration rules? (If so the answer is likely obvious.)
    – msanford
    Commented May 15, 2018 at 13:08
  • 1
    Not only log it but make sure to inform the user that this change happened. This might help a user to detect that something unwanted is happening. Of course this only makes sense when the notice is send via an uncompromised channel.
    – Noir
    Commented May 15, 2018 at 14:16
  • 1
    as @msanford says, the fact that password expiration rules exist and are even recommended in some scenarios suggests that there are no downsides in storing the time of the last password change
    – BgrWorker
    Commented May 15, 2018 at 14:28
  • 1
    If someone else is capable of changing a user's password, that action should be logged - if for no reason other than to offer support to confused users.
    – Jon
    Commented May 16, 2018 at 23:23

5 Answers 5

Reset to default
51

To, answer your question, Yes, you can and SHOULD log password-changes, and there's nothing fundamentally wrong with doing so, as long as you don't e.g. record the password itself"

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 event 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 be really good for weeding out noise.

Scenarios

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?

Example:

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.)

[edit] - Updated the initial answer to be more clear. Thanks to @SeldomNeedy for the suggestion.

Improve this answer
7
  • 16
    I hope it goes without saying, but I'll say it anyway, do not log the password itself. Logging the event of a password change is fine, but not as "User jsmith changed their password to f00Bar!"
    – JesseM
    Commented May 15, 2018 at 17:26
  • 28
    @JesseM unless you work at Twitter or GitHub, of course.
    – user2752467
    Commented May 15, 2018 at 18:54
  • 11
    @JustinLardinois Or unless you are an NSA agent working at Twitter or Github and pretending to be prone to making silly logging bugs.
    – Sentinel
    Commented May 15, 2018 at 21:15
  • 2
    Could you rephase the first line of your answer, here? The subject for the question reads "Should I log that a user changed their password?" to which you answer "No...". Given the additional grammatical error "there is no security concerns by logging" (as opposed to "there are no security concerns" I had to reread twice to make sure I was understanding that you actually meant "Yes, you can and SHOULD log password-changes, and there's nothing fundamentally wrong with doing so, as long as you don't e.g. record the password itself"
    – Seldom 'Where's Monica' Needy
    Commented May 16, 2018 at 18:45
  • 1
    It may also be useful to log the IP address of the actor that changed the password. It can be useful in identifying abuse.
    – corsiKa
    Commented May 17, 2018 at 1:58
9

I can't give you a reason not to log something; you have to give me a reason why you need to log it.

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 prevent the users from changing their password too often. 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.

Improve this answer
11
  • 12
    Please be aware that under the GDPR you must have the right to log certain things. and some things when logged are an immediate security breach (think clear text password of a user)
    – LvB
    Commented May 15, 2018 at 13:33
  • 8
    User actions are data, and potentially highly invasive data.
    – R.. GitHub STOP HELPING ICE
    Commented May 15, 2018 at 15:15
  • 23
    -1 for "There is no reason NOT to log something". There are very good security and privacy reasons not to log things you don't need to log. Anything logged/saved is potentially readable by an attacker or hostile authority.
    – R.. GitHub STOP HELPING ICE
    Commented May 15, 2018 at 15:16
  • 9
    -1 - "There is no reason not to log something" is bad advice from a security point of view. In general you should only ever implement something if there IS a reason to do it, not merely because of the absence of a reason not to. Many security breaches happen because of some scenario you didn't think of when you implemented something.
    – Jon Bentley
    Commented May 15, 2018 at 16:33
  • 4
    Please do not tell the user upon a failed login that they changed their password X days ago. That's giving way too much information to a brute force attacker.
    – schroeder ♦
    Commented May 15, 2018 at 18:45
5

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.

Improve this answer
5
  • 6
    As GDPR seems to think that a full IP address is PII I'll avoid logging that (but might add the first 24 bits or something like that)
    – edruid
    Commented May 15, 2018 at 15:30
  • 1
    A hash of the IP should suffice.
    – workoverflow
    Commented May 16, 2018 at 6:55
  • Hashing won't do: since there are very few IP addresses, it's very easy to reverse the hash.
    – Étienne Millon
    Commented May 16, 2018 at 7:39
  • 2
    The reason to store the IP address would be to be able to get a sense of where in the world the password change was made, so 24 bits of the IP address should give a general idea of where the change originated without pinpointing a specific household.
    – edruid
    Commented May 16, 2018 at 9:13
  • OP seems to already be proposing logging PII via an account identifier for the user account that triggered the password change. An IP address more or less doesn't change the fact that these logs will contain PII as defined by GDPR.
    – user
    Commented May 16, 2018 at 12:28
2

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
Improve this answer
2

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.
Improve this answer
3
  • 1
    Maintaining a hash list is very risky. It multiplies the damage caused by a stolen database.
    – forest
    Commented May 15, 2018 at 23:27
  • 1
    Could you elaborate on what the dangers of storing the timestamps are? What can a hacker do with the longevity data?
    – edruid
    Commented May 16, 2018 at 8:54
  • 1
    @edruid If attacker has account credentials, attacker may prioritise on whose accounts are going to remain accessible longest without the user knowing the account is compromised. If attacker does not have account credentials, attacker may prioritise on when and where to deploy keyloggers etc.
    – Sentinel
    Commented May 16, 2018 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .