New password must not match previous 4 passwords

[Bhavani6]

Hi,

I need to implement this rule.
When a user resets the password, the new password must not match with the previous 4 passwords.
The point is glide records are not working in installation exits.

Please help.

[CapaJC]

I'm not quite sure what you mean about GlideRecords not working in installation Exits, since three of the out-of-box ones use GlideRecord variables and queries.

The challenge with comparing against old passwords is that you'll have to store the old passwords somewhere. And you can't just compare the new password hash with the previous ones (assuming you store them in new custom fields on the sys_user table or in some other custom table), since the same password stored at different times yields different hashed values.

What I don't know is if there is a *publicly* available method to compare two hashed passwords to see if they are the same. Hopefully someone else can chime in if they know for sure one way or the other.

[tpalino]

Comparing password hashes is easy, CapaJC. The format of a password string (and the one that is used in the user_password field) is: $(hash signature)$(salt)$(password + salt digest). The hash signature identifies the function used to hash the password. In the case of SN, it is "s", which I can't find identified as a standard anywhere (for an example, SHA-256 would be "5"). The salt is a random string used to strengthen the password digest. In the case of SN, it appears to be a Base64 encoded string. The password+salt digest is what you get when you take the salt and the plaintext password and pass it through the hashing function.

The information that is needed from SN in order for a developer (non-SN) to implement a history function is the hashing function. Specifically, how the salt and plaintext password are combined and what cryptographic hash function the resulting string is passed through. Given that the salt and hash are both Base64 encoded 20-byte strings, SHA-1 would be a good guess without more information, but that still leaves the details of how the salt and password are combined.

Now, with that information, implementing a history is very easy:

1) Put a business rule on the sys_user table that watches for a change to the user_password field, and stores the tuple of the sys_user sys_id and the user_password field in a separate table (let's call that u_password_history). Also have that BR trim the list for the user to your specified history length (4 entries).

2) Add an onSubmit client script to the sys_user form view that watches for a value in the password field of the form. If there is a value in the field, retrieve the user's password history from u_password_history. For each entry, take the salt from the history entry and the new plaintext password and pass it through the hash function. Compare the resulting digest string to the digest string from the history entry. If they match, then the new password matches the password from the history. Reject the form submit and tell the user that they need to try again.

The problem here (and I have recently asked this question in HI) is that SN will not provide the needed information about the password hashing function. Unless the function is horribly insecure, there is no security risk in disclosing it (and if it is that insecure, someone had better be changing it anyways). Without that information, storing a password history becomes much more difficult.

[syed_faheem]

Hi Todd,

Did you find out any solution to this ?

We need to ensure that new password does not match previous 5 passwords or any password used by the User in the last 12 months.

Cheers

Syed.

[Mikkel Alimoot1]

Hi Syed.

Did you ever find a solution to this?

Regards

Mikkel