49

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.

edruid
  • 571
  • 1
  • 4
  • 11
  • 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. May 15 '18 at 13:07
  • 1
    Also, do you have password expiration rules? (If so the answer is likely obvious.) – msanford May 15 '18 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 May 15 '18 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 May 15 '18 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 May 16 '18 at 23:23
  • Why does an admin need to change the password to log in as user? No assume functionality? – Anemoia Jul 03 '18 at 05:46
  • @Snake An admin can set passwords as a part of importing batches of users with passwords sent from the school (I know this is an insecure way of doing things, but some schools require us to do this...) – edruid Jul 03 '18 at 14:30

5 Answers5

52

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.

Shane Andrie
  • 3,780
  • 1
  • 13
  • 16
  • 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 May 15 '18 at 17:26
  • 28
    @JesseM unless you work at Twitter or GitHub, of course. – user2752467 May 15 '18 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 May 15 '18 at 21:15
  • There are no negative security concerns with logging it, but there are (limited) concerns with not logging it, which, from your post, seems like you're aware of those instances. (Also, change the response to Yes, you should log it, the question is "Should I log" this, not "are there security concerns", i misread the response at first) – IceMage May 15 '18 at 21:21
  • 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 May 16 '18 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 May 17 '18 at 01:58
  • Be completely and utterly aware that any personally identifiable information you log will probably fall under the GDPR and need to be erased on request - this means logging such things as email, username, IP address etc may become a *huge* problem for you later on. As the answer suggests, give the user record a non-personal identifier and only log that in permanent logs - anything else should be stored against the user record in the database and thus easily destroyable. – Moo May 17 '18 at 09:16
10

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.

Community
  • 1
workoverflow
  • 241
  • 1
  • 4
  • 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 May 15 '18 at 13:33
  • 2
    I was referring to logging user actions, system responses, and software state. Logging data is strongly discouraged. – workoverflow May 15 '18 at 14:05
  • 8
    User actions **are data**, and potentially highly invasive data. – R.. GitHub STOP HELPING ICE May 15 '18 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 May 15 '18 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 May 15 '18 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 May 15 '18 at 18:45
  • @JonBentley "not merely because of the absence of a reason not to" Agree. I failed to properly explain that. What I really meant I meant was I can't give you a reason not to log it, you have to give me a reason to log it. – workoverflow May 16 '18 at 07:09
  • @schroeder When I fail to login, it shows like you changed your password 15 days ago and like that. – Suraj Jain May 29 '18 at 17:04
  • @SurajJain I used a dummy Google account to replicate the effect. It does say "x number of days" This is a poor security practice, in my opinion. – schroeder May 29 '18 at 17:11
  • @schroeder That is giving too much info is it?? – Suraj Jain May 29 '18 at 17:11
  • @schroeder Do you know about SOP?? I have some doubts, that are troubling me. – Suraj Jain May 29 '18 at 17:13
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.

Sangam Belose
  • 160
  • 6
  • 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 May 15 '18 at 15:30
  • 1
    A hash of the IP should suffice. – workoverflow May 16 '18 at 06:55
  • Hashing won't do: since there are very few IP addresses, it's very easy to reverse the hash. – Étienne Millon May 16 '18 at 07: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 May 16 '18 at 09: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 May 16 '18 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
Ghost8472
  • 61
  • 2
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.
Sentinel
  • 188
  • 5
  • 1
    Maintaining a hash list is very risky. It multiplies the damage caused by a stolen database. – forest May 15 '18 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 May 16 '18 at 08: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 May 16 '18 at 09:01