Passwords, Credential Storage and Policy

Updated

October 31, 2026

A correct-looking username does not guarantee a password login. A local password may be locked, expired or subject to account policy; a service may use another authentication method entirely. Inspect the relevant status without exposing password hashes.

Use the disposable bl04-accounts-lab clone and the retained learner administrator console. This chapter creates a separate blpass test user and leaves it for the next PAM exercise. Keep the original bl02 shut down while the clone runs. Do not experiment with the only working administrator account.

Passwords are not stored as login text

A local system normally stores a password verifier, not the plaintext password. A verifier includes parameters and a salt that allow a candidate password to be checked. Salting makes identical passwords produce different verifier values; a stolen verifier can still be attacked offline. A password hash is therefore sensitive even though it is not the plaintext.

On this Ubuntu-style local-account setup, /etc/shadow contains protected password and aging fields. The shadow manual documents their semantics. Do not print or copy its contents into a ticket, book notes or a shared terminal recording. A locked password field prevents use of that UNIX password but does not automatically disable SSH keys, other credentials or already running sessions.

Use status tools to inspect a known local account instead:

sudo passwd -S learner
sudo chage -l learner

These report status and aging information; do not change learner’s password or aging for the exercise. chage reports local shadow information and may not describe policy applied by an external identity provider. The chage manual explains password and account expiration fields.

Separate the controls

Control What it addresses What it does not automatically do
Password change Replaces a local password verifier Revoke every other credential or active session
Password lock Prevents use of that password verifier Disable keys, tokens or every service
Password aging Determines when a password must be changed Define the account’s full lifetime
Account expiration Restricts account use according to the enforcing service Terminate all running processes or revoke external identities
Authentication policy Defines how a service checks a credential Prove the user is authorized for every requested operation

Strong unique passwords, controlled enrollment, secure storage and recovery procedures all matter. Password policy applies to a specific identity source and login flow: local shadow settings do not define a remote directory’s rules. Do not assume a particular hashing algorithm, cost or automatic-update policy from a distribution name; inspect the installed configuration and relevant package documentation when making a change.

Lab: create an account and observe its policy

First verify the new account and private-group names and home path are unused:

getent passwd blpass
getent group blpass
test ! -e /home/blpass

Check each result. Both lookups should return no record with status 2, and the path test must succeed. An existing identity, path or lookup error is a stop condition. Create the account and set a unique lab password interactively:

sudo useradd -m -U -s /bin/bash blpass && sudo passwd blpass

If either command fails, inspect partial state before retrying. Never pass the plaintext as an argument or store it in shell history. Confirm status without displaying the verifier:

getent passwd blpass
sudo passwd -S blpass
sudo chage -l blpass

From the ordinary learner shell, run su - blpass, authenticate using the new password, run id, and exit. This confirms the particular local su flow and session at that time, not every login service.

Set a bounded maximum password age for this disposable user:

sudo chage -M 30 blpass
sudo chage -l blpass

Record the displayed maximum and resulting dates. A policy change in /etc/login.defs can affect defaults for account creation, but is not evidence that existing records were updated; the login.defs manual documents the shadow suite’s settings. PAM and a remote identity provider can apply additional policy. Do not edit global policy to perform this lab.

Keep blpass for the next chapter’s controlled authentication failure. Its 30-day value is a teaching example, not a recommended universal rotation period. For real users, choose policy based on the environment, current guidance, credential type and incident recovery requirements.

Diagnose and recover a failed password login

  1. Identify the service, exact user, time and observed message without recording the password.
  2. Verify the account resolves through getent and determine whether it is local or externally managed.
  3. For the local test account, inspect passwd -S and chage -l; distinguish locked password, password expiration and account expiration.
  4. Check the service’s authentication and account policy and the relevant logs. Do not reveal stored verifiers.
  5. Use an authorized recovery process and retest the same login path. An administrator password reset is a credential change; protect the new secret and verify the user can use it.

Repeated failed attempts can trigger a configured lockout or alert. Avoid guessing credentials. Preserve the existing administrator session and documented console recovery route before changing authentication policy.

Recall card

  • Verifiers, even salted hashes, require protection.
  • Password locking, password aging and account expiration are separate controls.
  • A successful local login test proves only that specific authentication flow.
  • Inspect status and service policy without exposing secrets.