Often times you will want to scramble data before you store it in an LDAP directory or a database. The quickest method is to simply obfuscate the data by replacing each character in the original data with different ones, of course by using a known algorithm. For example, shifting the characters over two places on the ASCII scale before replacement. Once this is done, you would then Base64 encode the data. Not the most secure of methods, but it will work and make the data look like something it is not.
A different method would be to write a piece of ECMAScript code or compile your own Java Class to actually encrypt the data using a known seed. The problem with the ECMAScript method is that the seed and the encryption algorithm is open and could enable a malicious User to figure out the method used; it’s ‘in the clear’ ECMAScript source code after all. Of course, the seed could be stored in a Named Password on the IDM Driver or IDM DriverSet, but this does not provide an uncrackable solution. The Java Class method is one Belkast has used in the past, but this requires yet another JAR file to be placed on the IDM server. When moving code from Development to Test and from Test to Production, things get left behind and this can often lead to broken code. I think everyone has been in that situation before!
The method that Belkast prefers when working with data encryption is to use the Public Key from a self-signed certificate. It does involve writing a little bit of ECMAScript code, but what it means is that:
- The encrypted output of the same value is different every time (just like SSL)
- The original cleartext value cannot be retrieved unless a malicious User has the certificates Private Key
As a use case, we encrypted the value Belkast123 (a valid password) two times, and the resultant encrypted values are shown below. As you can see, the results are different; therefore making it more difficult for a malicious User to determine what the initial value was.