WebSphere Commerce Password Management

Posted by Hariharan Vadivelu on
WebSphere commerce password management has not changed much as compared to the older versions, with the exception of KLF framework which was included in version 6 for additional PCI compliance.

In WCS all passwords are "one-way hashed using the SHA-1 hashing scheme and encrypted using a 128-bit key based on the merchant key". Merchant key is entered by the WCS admin during instance creation, this is typically a 16 digit hexadecimal number E.g 123456789abcdefg

WCS authentication commands never decrypts the password during authentication process and this one way hashing technique ensures that the passwords can not be decrypted by Admin as well.

"salt" is a unique key which is assigned to every user (mapped in userreg table) , WCS encryption utility makes use of the salt and merchant key to generate the password for a user. The idea behind using a salt based key is to make sure the encrypted passwords of two users having same plain text passwords will never match.

If you need to rotate the merchant key as part of your organization security policy, you should be using the MigrateEncryptedInfo utlity provided in WCS, this utility will make sure that all existing encrypted data which was generated using the old merchant key is re-encrypted. It is important to note that the users will be able to use their old plain text passwords without any issues.

WebSphere commerce comes with site default password policy, and this can be customized as per your requirements, some of the features of password policy are
  • Control password rotation by defining a password expiration rule
  • Define minimum and maximum length of a password.

Refer to Password Policy for more details.

The last thing I want to talk on this topic is Key Locator Framework (KLF) which was introduced in WCS 6 and later versions. by default the merchant key is stored in a configuration file which resides on the physical box hosting your WCS instance. KLF framework gives the ability to retrieve the merchant key from more secured external resource.

The most secure solution is to store the merchant key in a hardware device. A hardware solution takes care of matters such as secure storage and split knowledge of the merchant key.


  1. The Password Policy link above states : Password policies are enforced only if users are authenticated against the WebSphere Commerce database.

    If we have to authenticate against LDAP how the Password policies are going to work then?

  2. This comment has been removed by the author.

  3. Since a simple hash/salt can be broken in hours (per password), I'd like to see something along the lines of http://en.wikipedia.org/wiki/Bcrypt or the possibility to encrypt the whole users, address and userreg tables.

  4. 123456789abcdefg is not valid hexadecimal

  5. It was very nice blog to learn about SAP BASIS. Thanks for sharing.SAP basis

  6. But now I need to migrate from SHA1 hash to SHA256