Password Level (QPWDLVL)

The password level can be set to allow a passphrase as the password value. The term passphrase is sometimes used in the computer industry to describe a password value which can be very long and has few, if any, restrictions on the characters used in the password value. Blanks can be used between letters in a passphrase, which allows you to have a password value that is a sentence or sentence fragment. The only restrictions on a passphrase are that it cannot start with an asterisk (*) and trailing blanks will be removed. Before changing the password level of your system, review the section Planning password level changes.

Changing the password level of the system from 1-10 character passwords to 1-128 character passwords requires careful consideration. If your system communicates with other systems in a network, then all systems must be able to handle the longer passwords.

A change to this system value takes effect at the next IPL. To see the current and pending password level values, use the Display Security Attributes (DSPSECA) command .

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.