Version 7.5 of their IBM I platform introduces a new value for QPWDLVL, 4 which uses PBKDF2 with HMAC-SHA512 to hash passwords. But how secure is this new approach? In this article I will expose two vulnerabilities arising from IBM’s cryptographic choices.
With its release on 2022, IBM I 7.5 introduced various security changes including a new Password level (QPWDLVL) value of 4. This new level makes use of PBKDF2 with HMAC-SHA512 which is a significant improvement over the previous SHA-1 approach that was used. The specification of the algorithm can be seen in section 5.3 of this RFC4777bis draft.
Unfortunately, PBKDF2 has been around since the 2000s, since then a lot of research has been made, including the password hashing competition which was won by Argon2. Argon2 was created to avoid speed-ups caused by FPGAs and ASICs by using a memory-hard hashing function. I.e. a function that needed random access to a relatively large amount of memory to be computed efficiently.
The first issue arises directly from the choice of PBKDF2. Due to its nature, PBKDF2 can be highly pipelined on an ASIC or FPGA design to quickly compute password hashes. This is worsened by the relatively low choice of iterations made being only 10022 (and an extra sha256 hash used to generate the initial salt from the username and the last 4 bytes of the password). This is 20046 SHA-512 block hashes when using the HMAC salt precomputation speed up caused by the HMAC keys always being the same. It is therefore not unfeasible to see how a highly pipelined FPGA with a single stage for each of the SHA-512 hash steps could be synthesized to reach a cracking performance of one hash per cycle.
Furthermore, the SALT is derived exclusively from the user name and the password last 4 characters, this is done in order to allow for some kind of client-side password hashing. As explained by the Clipaha paper, to provide security, the generated SALT must be globally unique although it can be derived from a mix of globally and locally unique identifiers. Unfortunately, the parameters used to derive the SALT: the username and the password last characters, are not globally unique. The username is locally unique which means that the SALT will be unique for the same user across systems (if the last password bytes remain the same too). This means that it is still possible to create rainbow tables for common usernames like the most privileged user on a IBM I system: QSECOFR. This is caused by the fact that the SALT will be always composed from the username and its password which will be calculated using the rainbow table procedure. I.e. a rainbow table for user u can be created by iterating the function H(U,P) which uses PBKDF2 as defined in the IETF draft and then using the result to calculate the next value of P.
The solution is relatively simple, using a proper client-side password hashing algorithm like the one proposed by Clipaha with a modern and secure password hashing function and strong security parameters. This unfortunately will require updating the related network protocols to make use of these new approaches.