Initial expired passwords

Author: Joseph Reynolds

Other contributors: None

Created: 2019-07-24

Problem Description

OpenBMC has a default password, connects to the network via DHCP, and does not have a mechanism to require administrators to change the BMC's password. This may lead to BMCs which have default passwords being on the network for long time periods, effectively giving unrestricted access to the BMC.

Background and References

Various computer systems ship with default userid and passwords and require the password be changed on the initial signon. This reduces the time window when the system is accessible with a default password.

Various BMC interfaces require authentication before access is granted. The authentication and account validation steps typically result in outcomes like this:

  1. Success, when the access credentials (such as username and password) are correct and the account being accessed is valid.
  2. Failure, when either the access credentials are invalid or the account being accessed is invalid. For example, the account itself (not merely its password) may be expired.
  3. PasswordChangeRequired, when the access credentials are correct and the account is valid except the account's password is expired (such as indicated by PAM_CHANGE_EXPIRED_AUTHTOK).

OpenBMC currently implements the first two outcomes; it treats PasswordChangeRequired the same as an account that is invalid for any other reason. Some servers (such as the OpenSSH server) handle the PasswordChangeRequired by implementing a "password change dialog".

The Redfish Specification version 1.7.0 section 13.2.6.1 ("Password change required handling") provides the ManagerAccount resource v1.3 with a PasswordChangeRequired property which supports a password change dialog.

Note the terminology: An "expired password" is a special case of "password change required".

The meaning of the term "access" varies by context. It could mean:

  1. Access to the BMC's network interfaces.
  2. Access to the BMC's authentication mechanisms together with correct credentials, whether or not those credentials have expired and must be changed.
  3. Access to the BMC's function via an authenticated interface, for example, such as establishing a session after you've changed your initial password.
  4. Access to the BMC's function via an unauthenticated interface such as host IPMI or physical control panel (example: power button).

This design uses meanings 3 and 4 except where indicated.

Requirements

The requirements are:

  • The BMC's initial password must be expired when the new EXPIRED_PASSWORD image feature is used.
  • An account with an expired password must not be allowed to use the BMC (except to change the password).
  • There must be a way to change the expired password using a supported interface.

The use case is:

  • The BMC automatically connects to its management network which offers administrative or operational interfaces (whether or not the BMC is normally operated via its host).
  • The BMC is operated from its management network.

Preconditions for the BMC include:

  • The BMC has at least one account with a default password built in.
  • The BMC can update the password; for example, the /etc/passwd file is writeable.

Proposed Design

This design has three main parts:

  1. There is a new image feature EXPIRED_PASSWORD. When EXPIRED_PASSWORD is enabled, the BMC's default password will initially be expired as if via the passwd --expire root command. This administratively expires the password and is not based on time. An account with an expired password is neither locked nor disabled.

    This feature is intended to be enabled by default, with a staging plan: the feature will be disabled to give time for the continuous integration (CI) and test automation efforts to adapt, then enabled for the overall project.

  2. The BMC's network interfaces (such as REST APIs, SSH, and IPMI) disallow access via an account which has an expired password. If the access credentials are otherwise correct and the reason for the authentication failure is an expired password (determined by the usual Linux practices), where possible, the interface should indicate the password is expired and how to change it (see below). Otherwise the usual security protocols apply (giving no additional information).

    The /login URI is enhanced. If it is used with correct credentials (userid and password) and the password needs to be changed the request will fail to create a session and indicate a password change is needed. If it is used with correct userid and incorrect password, or with an incorrect userid, the behavior must not change. Note the /login URI is deprecated.

    The '/redfish/v1/SessionService/Sessions/' and '/redfish/v1/AccountService/Accounts/' resources are enhanced to indicate PasswordChangeRequired per the Redfish spec.

    The ipmitool command treats an expired password the same as an invalid password. Note the RMCP+ standard, such as used for the BMC's network IPMI interface, does not support changing the password when establishing a session. The ipmitool is not being enhanced by this design.

    The Secure Shell access (via the ssh command) already correctly indicates when the password is expired. No change is needed. But see the next bullet for the expired password dialog.

  3. There is a way for an account owner to change their own expired password. This can be either from a network-facing or in-band password changing protocol. For example:

    • Redfish: This design adds the Redfish PasswordChangeRequired handling to BMCWeb. See below for details.
    • SSH server: The SSH servers may have an expired password change dialog. For example, OpenSSH implement this feature. However, the Dropbear SSH server announces the password is expired, but does not implement the dialog to change it.
    • Access via the BMC's host: for example, via the ipmitool user set password command when accessed in-band.

When Redfish creates a session with PasswordChangeRequired, every response contains a PasswordChangeRequired message. The session effectively has only the ConfigureSelf privilege which allows it to only change the password and terminate the session. The usage pattern is:

  1. Create a session.
  2. If the PasswordChangeRequired message is present:
    1. PATCH the new password into the ManagerAccount object.
    2. Any other use of the session will get HTTP status code 403 Forbidden.
    3. DELETE the Session object to terminate the session.
    4. Create a new session and continue.

This design is intended to cover any cause of expired password, including both the BMC's initial expired password and password expired for another cause such as aging or via the passwd --expire command.

This design is intended to enable the webui-vue web application to implement a password change dialog for the signon screen.

Per the above design, when the web app uses either /login or /redfish/v1/SessionService to establish a session and the account has an expired password:

  • If the /login URI was used, the HTTP response indicates the password must be changed, and will not establish a session. In this case, the web app must use the Redfish API to establish a session.
  • POST to /redfish/v1/SessionService/Sessions will establish a session which will have the PasswordChangeRequired message.
  • At this point the web app can display a message that the password is expired and must be changed, then get the new password.
  • PATCH the password to the account specified in the PasswordChangeRequired message.
  • DELETE the Session object to terminate the session.
  • Create a new session and continue.

Alternatives Considered

The following alternate designs were considered:

  • Unique password per machine. That approach requires additional effort, for example, to set and track assigned passwords.
  • Default to having no users with access to the BMC via its network. When network access is needed, a technician would create or modify the userid to have network authority and establish a password at that time. This may be through the BMC's host system or via the BMC's serial console. That approach requires the tech to have access, and requires re-provisioning the account after factory reset
  • Disable network access by default. That approach requires another BMC access vector, such as physical access or via the BMC's host, to enable network access.
  • Provision the BMC with a certificate instead of a password, for example, an SSH client certificate. That approach suffers from the same limitations as a default password (when the matching private certificate becomes well known) and requires the BMC provide SSH access.
  • Require physical presence to change the password. For example, applying a jumper, or signing in via a serial cable. That approach is not standard.
  • Have LDAP (or any authentication/authorization server) configured and have no local users which have default passwords configured in the BMC firmware image. That approach requires the customer have an LDAP (or similar) server. Also, how we can configure the LDAP, as we don't know the customer LDAP server configuration?
  • Have a new service to detect if any password has its default value, and write log messages for that condition, with the idea to alert the system owner of this condition. That approach doesn't solve the problem and burdens BMC resources.

Warning. This design may leave the BMC with its default password for an extended period of time if the use case given in the requirements section of this design does not apply. For example, when the host is operated strictly via its power button and not through the BMC's network interface. In this case, the alternatives listed above may mitigate this risk. Another alternative is a design where the BMC is initially in a provisioning mode which does not allow the BMC to operate its host. The idea is that you have to establish access to the BMC (which includes changing its password) before you can leave provisioning mode.

The BMCWeb Redfish server could be enhanced so that when the Password is successfully patched, the session no longer asserts the PasswordChangeRequired condition and re-asserts the user's usual authority immediately without requiring a new session. This is allowed by the Redfish spec, but was not implemented because it would be more difficult to code and test.

Impacts

Having to change an expired password is annoying and breaks operational procedures and scripts. Documentation, lifecycle review, and test are needed. Expect pain when this is enabled.

To help with this, the REDFISH-cheatsheet will be updated with commands needed to detect and change an expired password.

This design does not affect other policies such as password aging.

Testing

Scenarios:

  1. Ensure that when the BMC is in its initial state:
    • All available network interfaces deny access.
    • Selected interfaces allow the password to be changed.
  2. Ensure factory reset resets the password to its initial expired state (repeat the tests above).
  3. Ensure the password change is effective for users entering from all supported interfaces. For example, change the password via the Redfish API, and validate that the old password does not work and the new password does work via IPMI for the same user.
  4. Handle BMC code update scenarios. For example, (A) Ensure code update does not cause a previously set password to change to default or to expire. (B) Validate what happens when the BMC has a default password and does code update to a release which has the default expired password design (this design).
  5. Ensure the BMC continues to operate its host, for example, when the BMC is factory reset while the host is running. Ensure the power button can be used to power off the host while the BMC's password is expired.
  6. Test on BMC using Linux PAM both with and without LDAP or ActiveDirectory configured.
  7. Validate you can to change an IPMI user's expired password, such as with: ipmitool user set password 1 NEWPASSWORD. This can be from another IPMI user's session or from unauthenticated access.