Passwords and other sensitive data that is encrypted must determine the character set of the clear text to accurately interpret the result when it is decrypted, or when hash values are compared during authentication.
For example, a client connects to Adaptive Server using isql and establishes a new password. Regardless of the character set used in the client, characters are always converted to the server’s default character set for processing within Adaptive Server. Assuming the Adaptive Server default character set is “iso_1,” consider the command:
alter login loginName with password oldPasswd modify password newPasswd
The password parameters are varchar, and are expressed as a quoted string and stored with “iso_1” encoding before encryption. If the Adaptive Server default character set changes later, the encrypted password remains an encrypted string of characters encoded with the original default character set. This may result in authentication failure due to mismatched character mapping. Although changing the default character set is a rare occurrence, it becomes more important when migration occurs between platforms.
Adaptive Server converts the clear text password to canonical form before encryption so that the password can be used across platforms, chip architectures, and character sets.
To use canoncial form for storage in syslogins:
Convert the clear text password string to UTF-16.
Convert the UTF-16 string to network byte order.
Append a small buffer (the salt) with random bytes to the password.
Apply the SHA-256 hash algorithm.
Store digest, salt, and version in the password column.
At authentication time:
Convert the clear text password string to UTF-16.
Convert the UTF-16 string to network byte order.
Append the salt from the password column in syslogins to the password.
Apply the hash algorithm.
Compare results with password column in syslogins, if they match then authentication is successful.
