Password history

[w_bouwer]

Hi,

A client of ours requests to be able to verify the newly defined password against the previous 10 passwords that were used for that user. Passwords and historic passwords should be readable for no one, not even the user. Does anyone have any suggestion on how this can be done?

Regards,

Wesley

[john_andersen]

Last I researched this, this was not a trivial matter. ServiceNow generates a 1-way hash on their user passwords that causes the hash value to be different every time even if the same password value is used. I don't believe the code API is public that allows you to decrypt any portion of the hash to get at some common historic hash value.

[w_bouwer]

I was afraid that would be the case. We do have an MD5 hashing algorithm that should work sufficiently as a backup source for the password history, but it requires us to make some modifications to the instance. We would prefer to use a ServiceNow supported feature instead., but seeing the huge amount of enhancement tasks that are currently open in HI, I think we will have to implement our own feature instead 🙂

Thanks for the response though, the feedback is appreciated!

[tpalino]

It's actually not too hard to implement something like this while still using their password hashes as-is, but Service-Now refuses to provide the information that you need to do it. The piece of information they won't provide (and I've asked) is what digest is used (looks like SHA-1, but I don't have confirmation) and how are the salt and password combined when hashing. I'm not sure if they think it's a security risk (it's not - unless their hashing method is REALLY insecure).

With that information, you could store a history of the user_password strings in a separate table (using a business rule on the user table), and when the user changes their password, just hash it with each of the salts in the history and compare to the password digests before they're allowed to submit the form. If you get a match, tell the user and reject the form submit.

They gave us the same answer about putting in an enhancement request. Which is essentially "we hope you'll forget about this request".

[w_bouwer]

The suggestion you make is actually the one we implemented. We use a seperate table to store our own hashed versions of the password. We used an implementation of a javascript MD5 hash to store and check these passwords. This was sufficient for our customer.

For the algorithm you can check: http://pajhome.org.uk/crypt/md5/. Works like a charm.

Regards,

Wesley