Re: Encryption algorithm used for the IBMi OS passwords.

[Patrick Botz <pcbotz@xxxxxxxxx>]

Passwords are hashed, not encrypted. There is no way to reproduce the
original cleartext from a hashed password.

I don't remember the exact process for hashing. I do recall, however, that
the process involves multiple hash and encryption operations.

At the time, IBM research (who recomended the process) was very confident
that they were only susceptible to brute force attacks. The reason for
multiple hash and encryption operations was to increase the number of CPU
cycles required to execute a brute force attack.
On Mar 31, 2016 5:14 PM, "Roger Harman" <roger.harman@xxxxxxxxxxx> wrote:

> At security level 50, I believe IBM i is DOD C2 Certified.  Think that's
> good enough for them?
>
> Roger Harman
> COMMON Certified Application Developer - ILE RPG on IBM i on Power
>
>
>
>
> ________________________________________
> From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> on behalf of
> JWGrant@xxxxxxxxxxxxxxx <JWGrant@xxxxxxxxxxxxxxx>
> Sent: Thursday, March 31, 2016 3:06 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Encryption algorithm used for the IBMi OS passwords.
>
> I did find this tidbit on the IBM 7.2 Knowledge center that I found
> interesting.
> It does not disclose the algorithm used bit I did find in interesting.
>
> Jim
>
> Password Encryption and Storage on IBM i
> IBM i password encryption does not use a "hardcoded" encryption key in
> either of the password encryption algorithms so there is no key that needs
> to be stored or protected. The encryption algorithms use the USERID and
> the PASSWORD itself in the encryption algorithm. Before actually
> encrypting and/or hashing (depending on the setting of the QPWDLVL system
> value), there are a few additional steps that are performed to essentially
> drop off a few of the bits that make up the clear text password followed
> by an "exclusive or" operation on the password string (this helps protect
> the password). This password string is then used to encrypt or hash the
> user ID in order to create the encrypted password. Since the password
> itself becomes the key, things are very secure as a key does not need to
> be stored anywhere on the system. When it is time to authenticate a user,
> the system takes the clear text password that the user entered (on the
> signon screen, etc.) and runs the same algorithm, then compares that
> encrypted result with the encrypted result that was created and saved when
> the password was changed. There is never a comparison that is done with
> the clear text password itself since the encryption algorithms are both
> one-way, meaning you can never decrypt and get back the clear text
> password.
> The user profile passwords are stored in an internal control block that is
> protected with the strongest mechanism available to the IBM i operating
> system running on the Power® hardware. A capability that is called
> Hardware Storage Protection (HSP) is used to protect the control block.
> The HSP capability is protection that is built into the Power hardware and
> enforced by the hardware itself. The HSP value that is used is called "no
> access from user state" and "protect at all security levels". This HSP
> protection value keeps all user level code out of the control block (no
> read or write access) but allows the operating system to read/write the
> control block. This protection is always activated as the control block is
> protected at all security levels. If user level code tries to access the
> control block, the hardware would send an exception and the Licensed
> Internal Code would send an error to the user level code (and access would
> be denied).
> If someone has the encrypted password could they decrypt it to get the
> clear text password?
> No, but a brute force attack is possible, basically running all potential
> passwords through the algorithm and comparing the encrypted results. So it
> is important to protect your SAVSYS and SAVSECDTA tapes and data by using
> encrypted backup with tape hardware capable of encryption. The operating
> system protects the passwords by storing them in an internal control block
> that is protected with the strongest mechanism available to the operating
> system on the Power hardware. HSP is used to protect the control block.
> But the passwords are saved on media during a SAVSYS and SAVSECDTA so the
> media needs to be protected (encrypted backup and physical security).
> One thing to be aware of is that the system has two IBM i APIs, set
> encrypted password (QSYSUPWD) and retrieve encrypted password (QSYRUPWD )
> that were implemented to allow the High Availability (HA) business
> partners the ability to move user profile changes from the production
> machine to the target side backup server. These APIs allow the retrieve
> and set of the encrypted password for a user profile but the APIs are only
> callable by a security officer (*ALLOBJ and *SECADM special authority
> required). These APIs do return the encrypted password string so this data
> and the use of the API need to be well controlled. The HA partners use
> these APIs to move the password to the target server when a password
> changes on the production server in order to keep the password change in
> sync. The encrypted password string, and other information, returned by
> the QSYRUPWD API have a cyclic redundancy check (CRC) created to ensure
> the password itself is not modified (either intentionally or accidentally)
> when being moved from system to system. The CRC is checked by the QSYSUPWD
> API to ensure that the string is the same as when it was returned by
> QSYRUPWD. This CRC does not provide any protection for the encrypted
> password itself, it just ensures that the string isn't changed before
> setting the password on the target server. To protect the encrypted
> password in the HA environment (along with all data flowing from source to
> target), an encrypted session between the source and target system is
> recommended.
>
>
> Jim W Grant
> Senior VP, Chief Information Officer
> Web: www.pdpgroupinc.com
> Email: JWGrant@xxxxxxxxxxxxxxx
>
>
>
>
> From:   Nathan Andelin <nandelin@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   03/31/2016 05:34 PM
> Subject:        Re: Encryption algorithm used for the IBMi OS passwords.
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> My dad worked on the encryption algorithms for U.S. military missile and
> rocket guidance systems.. He passed away, but I wonder how he would
> respond
> to "auditors"?
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.