HashString comparison with SSHA256 hash algorithm

2
We have a change request in which it is said that: When a user changes his password, it should be password that he has not used in the past three months. I have added a new attribute DatePasswordChange to our Account-entity (a Generalization of System.User) and added a new Entity AccountHistory which can log the password changes (related to entity Account) having attributes Password (HashString) and DatePasswordChange. So now each time the user changes his password, it is also logged to the AccountHistory entity. The point is that I should also check on change that the new password does not occur in the AccountHistory. We use SSHA256 (the salted hash algorithm), so I know I cannot textually compare the hashvalues because of the salt. I know now that a Java-action is needed, but does anyone have working example of the Java-code to do this? I have searched through the forum, and though some topics come close, none of them really seemed to provide a working example.
asked
3 answers
4

You have to compare before commit, the unhashed value against the hashed SSHA256 value. You have to iterate (direct xPath/OQL query is not possible) through the history and call the Java compare function that looks something like this:

MendixHashString password = (MendixHashString ) __account.getMember(this.getContext(), "Password");
return password.verifyValue(this.getContext(), this.unhashedPassword);

There is no way to compare hashes after commit when you don't have the unhashed password because of the salt (only possible for not salted passwords as SHA-256, MD5, and so on).

answered
1

Hi, did you check the Community Commons app in the appstore for the Hash (Hashes a value using the SHA-256 hash algorithm) function?

answered
1

Hi Martijn,

We have the same functionality here, we use

    MessageDigest md = MessageDigest.getInstance("SHA-256");
    md.update(value.getBytes("UTF-8")); 
    return base64Encode(new String(md.digest()));

to get a hash. The password history is only accessible for the owner user and only used in a microflow to find whether a password is already used. So we don't need to protect these hashes because they can not be read and analysed outside the system.

answered