Password Level (QPWDLVL)
The password level of the system can be set to allow for user profile passwords from 1-10 characters or to allow for user profile passwords from 1-128 characters.
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.
|0||The system supports user profile
passwords with a length of 1-10 characters. The allowable characters
are A-Z, 0-9 and characters $, @, # and underline.
|1||QPWDLVL 1 is the equivalent support
of QPWDLVL 0 with the following exception: IBM i NetServer LAN manager passwords
for Windows 95/98/ME clients
will be removed from the system. The LAN manager password is used
to communicate with IBM i Support
for Windows Network Neighborhood (IBM i NetServer)
product and only affects Windows 95/98/ME
clients. The LAN manager passwords have been disabled by Windows since Vista so removing them will
not affect current versions of Windows.
Unless the Windows 95/98/ME clients are configured to use NTLMv2 passwords, you cannot use QPWDLVL value 1 to connect those clients to the IBM i NetServer product. QPWDLVL 1 improves the security of IBM i platforms by removing all IBM i NetServer LAN manager passwords from the system.
|2||The system supports user profile
passwords from 1-128 characters. Upper and lower case characters are
allowed. Passwords can consist of any character and the password will
be case sensitive. QPWDLVL 2 is viewed as a compatibility level. This
level allows for a move back to QPWDLVL 0 or 1 as long as the password
created on QPWDLVL 2 or 3 meets the length and syntax requirements
of a password valid on QPWDLVL 0 or 1.
|3||The system supports user profile passwords from
1-128 characters. Upper and lower case characters are allowed. Passwords
can consist of any character and the password will be case sensitive.
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.