increase encrypted password hash algorithm

The data in the buffer returned from the Retrieve Encrypted User Password (QSYRUPWD) API is now protected so that the one-way encrypted password values cannot be extracted from the buffer for use in brute force attacks.
Because of this change, the buffer returned from the Retrieve Encrypted User Password (QSYRUPWD) API is not compatible with previous releases. If the data must be sent from an IBM i 7.5 system to an IBM i 7.4 or 7.3 system, the appropriate PTFs (7.4 = SI76821, 7.3 = SI76822) must be installed so that the Set Encrypted User Password (QSYSUPWD) and Check Encrypted User Password (QSYCUPWD) APIs can process the QSYRURPWD buffer. Without the PTFs, QSYSUPWD and QSYCUPWD will return error
CPF4AB2 - "Receiver variable from QSYRUPWD has been altered".

IBM Power Systems Development

IBM does not intend to provide a solution to this request at this time, so it is being closed.

For clarification, the output from the QSYRUPWD API contains the hashed user profile password. These passwords are one-way hash values and cannot be 'decrypted'. The QSYRUPWD API is shipped with *PUBLIC *EXCLUDE authority and requires *ALLOBJ and *SECADM special authorities. *SECADM is not a commonly given special authority so few profiles should have access to the QSYRUPWD API.
The output from the API is known to be data that should be well protected to prevent access from unauthorized users. The Security Reference manual Password Level (QPWDLVL) topic (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzarl/rzarlnewpwdlevels.htm) includes a section titled "If someone has the encrypted password could they decrypt it to get the clear text password?" that describes why the API exists and the importance of controlling access to it.

Beyond restricting access to the API, the best defense customers can use against brute force is to run at Password Level 3 and require longer passwords with at least a minimum of 15 characters.

RFE 118459 tracks adding support for a newer hash algorithm. Of note however is that a newer algorithm with a larger hash size does not reduce the need to restrict access to the QSYRUPWD API.

The CAAC has reviewed this requirement and recommends that IBM view this as a high priority requirement that is important to be addressed. Any security weakness needs to be addressed.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Nancy Uthke-Schmucki - CAAC Program Manager

You are right, brute force is the concern.
Maybe I have used wrong description. The issue is that the hash can be compared to plain text with dictionaries, well-known passwords and brute force attacks.