Skip to Main Content
IBM Power Ideas Portal

This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Delivered
Workspace IBM i
Categories Security
Created by Guest
Created on Sep 6, 2019

increase encrypted password hash algorithm

The request is to increase the complexity of the hashed password as it is provided by QSYRUPWD API.

Use Case:

Even if the API is provided with *EXCLUDE authority for *PUBLIC, for a user profile with *ALLOBJ special authority, this is easy to retrieve the hashed password of all users with a simple program using the API.
It becomes then possible to use the hashed password with public internet tools and decrypt the password to get it in plain text.

Idea priority High
  • Guest
    May 3, 2022
    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
  • Guest
    Jan 15, 2020

    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 ( 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.

  • Guest
    Jan 14, 2020

    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

    For more details about CAAC's role with RFEs, see

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Sep 17, 2019

    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.