Cyber Security LabsLabsIntermediate

Lab: testing password policies and MFA in your lab

By Mohamed Fayas 9 min readUpdated 8 October 2026

In short: Good password rules and multi-factor authentication (MFA) stop most account takeovers. In this lab you configure length and dictionary checks, account lockout, and TOTP-based MFA for SSH on your own lab machines, then test that weak passwords and single-factor logins are rejected.

Aim and what you need

The aim is to configure authentication the way current guidance recommends, then prove each control works by trying to get past it, using only your own test accounts. NIST SP 800-63B (Digital Identity Guidelines) recommends long passwords, checking against lists of breached or common passwords, no arbitrary composition rules, no routine forced changes, and MFA for anything important.

An Ubuntu Server VM (10.10.10.20) and a Windows VM in your isolated lab, each with a snapshot.
An authenticator app on your phone (any app that supports TOTP).
Test accounts only. Never test lockout or guessing against real accounts or systems you do not own.

Design

Figure 1. Modern guidance, such as NIST SP 800-63B, favours length, breach checks and MFA over complexity rules and forced expiry.

Figure 2. The lab server requires something you have (the private key) and a time-based code from your authenticator app.

Steps

Linux password quality. Install the quality module and set a minimum length with dictionary and username checks in /etc/security/pwquality.conf.

sudo apt install libpam-pwquality
sudo nano /etc/security/pwquality.conf

minlen = 15
dictcheck = 1
usercheck = 1
enforce_for_root

Windows lockout and length (administrator prompt):

net accounts /minpwlen:14 /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15
net user testuser <temporary-long-passphrase> /add

SSH with key plus TOTP. Key-only SSH must already work (see the Linux hardening lab). Install the PAM module, enrol as your user by scanning the QR code with your app, then require both factors.

sudo apt install libpam-google-authenticator
google-authenticator -t -d -f -r 3 -R 30 -w 3

Add this line near the top of /etc/pam.d/sshd, and comment out @include common-auth so a password is not also requested:

auth required pam_google_authenticator.so

Then add to /etc/ssh/sshd_config.d/50-hardening.conf and reload:

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

sudo sshd -t
sudo systemctl reload ssh

Verify

Run each test and write down the result. Success means every weak or single-factor attempt fails.

passwd
sudo chage -l labadmin
ssh [email protected]
net accounts

Setting a short or dictionary password with passwd is refused with a reason such as "too short" or "dictionary word".
SSH asks for a verification code after the key is accepted; a wrong code is rejected; the right code lets you in.
Five wrong passwords for testuser on Windows lock the account for 15 minutes.

Compare passphrases with the password strength checker, create test ones with the password generator, and see how codes are calculated with the TOTP tool.

Troubleshooting and clean-up

Codes always rejected: TOTP depends on time. Check the server clock with timedatectl and turn on NTP synchronisation.
Still asked for a password: @include common-auth is still active in /etc/pam.d/sshd.
Locked out of SSH: use the VM console, which does not go through SSH.
Policy not applied on Windows: domain Group Policy overrides local settings on joined machines.

Store the emergency scratch codes that google-authenticator prints somewhere safe, or delete ~/.google_authenticator when you finish. Remove the test account with net user testuser /delete and restore snapshots to repeat. At work, prefer phishing-resistant MFA such as passkeys or FIDO2 security keys for administrators.

Practice

Why does current guidance discourage forced password changes every 90 days?

Forced changes push people towards predictable patterns; changing only after suspected compromise gives better passwords.

Your TOTP codes are always rejected. What is the first thing to check?

The clock on the server and phone; TOTP codes are only valid within a short time window.

What does AuthenticationMethods publickey,keyboard-interactive require?

Both a valid SSH key and a successful keyboard-interactive step (here the TOTP code) in that order.

Key takeaways

Favour long passphrases, breached-password checks and MFA over complexity and expiry rules.
pam_pwquality enforces length and dictionary checks on Linux.
net accounts sets local length and lockout on Windows.
Key plus TOTP gives two factors for SSH; keep a console route in case of lockout.
Test controls only with your own lab accounts.

Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author