Starting in OpenVOS Release 18.0, VOS System Administrators will be able to select one of 3 new password encryption algorithms. This post provides an overview of these changes.
The existing, legacy VOS encryption algorithm is a proprietary, one-way hash function that incorporates the original DES algorithm as a portion of its work. See this writeup. Because of advances in computing power, it is now possible to use brute force attacks against it that simply were infeasible when it was first written. So it is time to introduce a new password encryption algorithm. In fact, for compatibility with other operating systems, we’re adding support for 3 new algorithms, while retaining support for the legacy VOS algorithm.
Stratus has spread the deployment of the additional encryption algorithms over 2 releases. OpenVOS 17.2 adds the underlying kernel support, new APIs, and data structures that are necessary to support multiple encryption algorithms, but it does not allow you to start using the new algorithms. The new APIs are described here. OpenVOS 17.2 is a transitional release; we encourage users to convert their software over to the new APIs as they use it. But you aren’t required to use OpenVOS 17.2; you can skip it, and do the work on OpenVOS 18.0.
OpenVOS 18.0 allows (but does not require) you to start using the new algorithms. In order to use the new algorithms, all modules in a multi-module VOS system must be running 17.2 or 18.0, and all user software that calls s$encipher_password or s$get_registration_info must be updated to use the new APIs (s$encipher_password2, s$get_registration_info with a version 8 structure). The master module must be running OpenVOS 18.0. Certain layered products from Stratus must also be updated (e.g., Samba, ISP, others); basically, any layered product that deals with user passwords must be upgraded. All of the affected layered products have a base release of 17.2 or 18.0. Finally, the System Administrator must run the sync_password_info command to populate the change_password.sysdb file with both the legacy encrypted value and the new, standard encrypted value. At this point, the administrator can change the encryption algorithm, and then any user that subsequently changes his or her password will have their encrypted password stored using the current algorithm.
Once a user has a password that is encrypted using one of the new algorithms, the copy of the password that was encrypted with the legacy algorithm is deleted. This is necessary to ensure that an attacker that gains access to the password data file can’t figure out the password by attacking the weaker legacy algorithm. But the fact that we delete the legacy encrypted password also means that older releases will no longer work with that password file; hence the requirement that all modules run at least OpenVOS 17.2.
There is no requirement to use the new encryption algorithms. A customer can continue to use the legacy algorithm forever. A customer can even try out one of the new encryption algorithms, and if they run into problems, can revert back to the legacy algorithm. The only requirement is that any user who changed their password while the new algorithm was in effect will have to change it again, because the only time that we encrypt a password is when it is changed (because that’s the only time we know its plaintext value).
The new algorithms are taken from the set implemented by libc on GNU/Linux or FreeBSD systems, and are based on the MD5, SHA256, and SHA512 hash functions. None of them use DES or 3DES. Given the same algorithm and the same plaintext password, the VOS code produces the same ciphertext as the Linux or FreeBSD code (in fact, we used the FreeBSD code in our implementation). We made this decision to strengthen the interoperability of open-source software between Linux and OpenVOS systems.
If you do not make use of the multi-module capabilities of VOS, then as soon as you upgrade your module to OpenVOS 18.0, you can begin the processs of switching to one of the new password encryption algorithms. But as mentioned earlier, this is an option, not a requirement.
Customers are not required to install OpenVOS 17.2 first; they can upgrade directly from a previous release to 18.0. Nor are customers required to stay on Release 18.0; they can downgrade back to 17.2 at any time (although all users who had changed their password while the new algorithm was in effect will have to change it again in this case).
All of these features are fully documented in the SRB and manuals for 17.2, and will be documented in the 18.0 manuals once the release is available.
I recommend that customers who are planning to switch to the new password encryption algorithms contact their Customer Assistance Center ahead of time to verify that their plan of action is complete and correct.
If you have any questions about this post, please post them to the comments section, below, or contact a Stratus representative or the CAC.
Company