# 3. Password Management — Test Cases

User Type: **Student**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: password_management.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature, expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 3.1 Password Reset | "Forgot password?" entry point on the login screen | TC-ST-01-03-001 |
| 3.1 Password Reset | Reset request: enter registered email, receive a single-use, time-limited reset link | TC-ST-01-03-002 |
| 3.1 Password Reset | Reset link validation (single-use, time-limited) with expiry handling | TC-ST-01-03-003 |
| 3.1 Password Reset | New password entry with strength validation and confirm field | TC-ST-01-03-004 |
| 3.1 Password Reset | All existing sessions invalidated on successful reset | TC-ST-01-03-005 |
| 3.1 Password Reset | Rate limiting on reset requests per account and per IP | TC-ST-01-03-006 |
| 3.1 Password Reset | Generic response for unknown emails (no account enumeration) | TC-ST-01-03-007 |
| 3.1 Password Reset | Reset event logging (requested, link sent, link used, expired, failed) | TC-ST-01-03-008 |
| 3.1 Password Reset | Audit logging of the password reset | TC-ST-01-03-009 |
| 3.1 Password Reset | Rule: The reset link is single-use and time-limited; reusing or expiring it produces a reissue path. | TC-ST-01-03-001 |
| 3.1 Password Reset | Rule: The response to a reset request is identical whether or not the email is registered (prevents account enumeration). | TC-ST-01-03-002 |
| 3.1 Password Reset | Rule: Reset requests are rate-limited per account and per IP to prevent abuse. | TC-ST-01-03-003 |
| 3.1 Password Reset | Rule: A successful reset invalidates all existing sessions for the account. | TC-ST-01-03-004 |
| 3.1 Password Reset | Rule: The new password must meet the strength policy and cannot be the same as the previous password. | TC-ST-01-03-005 |
| 3.1 Password Reset | Rule: Reset events (requested, link sent, link used, expired, failed) are logged with timestamp and IP. | TC-ST-01-03-006 |
| 3.1 Password Reset | Rule: The password reset is audit-logged with the account, the outcome, and the timestamp. | TC-ST-01-03-007 |
| 3.2 Password Change | "Change password" entry point in Profile → Security | TC-ST-01-03-010 |
| 3.2 Password Change | Current password verification before accepting a new password | TC-ST-01-03-011 |
| 3.2 Password Change | New password entry with strength validation and confirm field | TC-ST-01-03-012 |
| 3.2 Password Change | "Cannot reuse previous password" check | TC-ST-01-03-013 |
| 3.2 Password Change | Immediate application on success | TC-ST-01-03-014 |
| 3.2 Password Change | Optional invalidation of other sessions on change | TC-ST-01-03-015 |
| 3.2 Password Change | Change event logging (success, wrong current password, weak new password) | TC-ST-01-03-016 |
| 3.2 Password Change | Audit logging of the password change | TC-ST-01-03-017 |
| 3.2 Password Change | Rule: The current password must be verified before a new password is accepted. | TC-ST-01-03-010 |
| 3.2 Password Change | Rule: The new password must meet the strength policy and cannot be the same as the current or recent previous passwords. | TC-ST-01-03-011 |
| 3.2 Password Change | Rule: Changing the password does not sign out the current session by default, but can invalidate all other sessions. | TC-ST-01-03-012 |
| 3.2 Password Change | Rule: A wrong current password produces a specific "current password incorrect" message (the Student is already authenticated, so enumeration is not a concern). | TC-ST-01-03-013 |
| 3.2 Password Change | Rule: Change events (success, wrong current password, weak new password) are logged with timestamp. | TC-ST-01-03-014 |
| 3.2 Password Change | Rule: The password change is audit-logged with the account, the outcome, and the timestamp. | TC-ST-01-03-015 |
| 3.3 Password Policy Enforcement | Minimum length requirement (e.g., 8 characters) | TC-ST-01-03-018 |
| 3.3 Password Policy Enforcement | Character class requirements (uppercase, lowercase, number, symbol) | TC-ST-01-03-019 |
| 3.3 Password Policy Enforcement | Blocked common passwords list | TC-ST-01-03-020 |
| 3.3 Password Policy Enforcement | Personal information check (password must not contain the Student's name or email) | TC-ST-01-03-021 |
| 3.3 Password Policy Enforcement | Reuse history: the new password cannot match any of the last N passwords | TC-ST-01-03-022 |
| 3.3 Password Policy Enforcement | Real-time strength meter with specific, actionable hints | TC-ST-01-03-023 |
| 3.3 Password Policy Enforcement | Policy applied consistently at registration, reset, and change | TC-ST-01-03-024 |
| 3.3 Password Policy Enforcement | Policy violation logging | TC-ST-01-03-025 |
| 3.3 Password Policy Enforcement | Audit logging of the password policy enforcement | TC-ST-01-03-026 |
| 3.3 Password Policy Enforcement | Rule: The policy is applied consistently at registration, reset, and change; there is no weaker path. | TC-ST-01-03-018 |
| 3.3 Password Policy Enforcement | Rule: The strength meter gives specific, actionable hints (length, character class, common password, personal info, reuse). | TC-ST-01-03-019 |
| 3.3 Password Policy Enforcement | Rule: The reuse history covers the last N passwords (e.g., 5); a match is rejected. | TC-ST-01-03-020 |
| 3.3 Password Policy Enforcement | Rule: A password containing the Student's name or email is rejected. | TC-ST-01-03-021 |
| 3.3 Password Policy Enforcement | Rule: Policy violations are logged (which rule failed) without storing the password itself. | TC-ST-01-03-022 |
| 3.3 Password Policy Enforcement | Rule: The password policy enforcement is audit-logged with the account, the rule(s) triggered, and the timestamp. | TC-ST-01-03-023 |

## 3.1 Password Reset

### TC-ST-01-03-001 — "Forgot password?" entry point on the login screen
**Type:** Positive
**Covers:** 3.1 → "Forgot password?" entry point on the login screen; Rule: The reset link is single-use and time-limited; reusing or expiring it produces a reissue path.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Forgot password?" entry point on the login screen.
2. Observe the result and verify the full behavior: "Forgot password?" entry point on the login screen.
**Expected Result:** "Forgot password?" entry point on the login screen — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-03-002 — Reset request: enter registered email, receive a single-use, time-limited reset link
**Type:** Edge
**Covers:** 3.1 → Reset request: enter registered email, receive a single-use, time-limited reset link; Rule: The response to a reset request is identical whether or not the email is registered (prevents account enumeration).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Reset request: enter registered email.
2. Observe the result and verify the full behavior: Reset request: enter registered email, receive a single-use, time-limited reset link.
**Expected Result:** Reset request: enter registered email, receive a single-use, time-limited reset link — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-003 — Reset link validation (single-use, time-limited) with expiry handling
**Type:** Edge
**Covers:** 3.1 → Reset link validation (single-use, time-limited) with expiry handling; Rule: Reset requests are rate-limited per account and per IP to prevent abuse.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Reset link validation (single-use.
2. Observe the result and verify the full behavior: Reset link validation (single-use, time-limited) with expiry handling.
**Expected Result:** Reset link validation (single-use, time-limited) with expiry handling — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-004 — New password entry with strength validation and confirm field
**Type:** Edge
**Covers:** 3.1 → New password entry with strength validation and confirm field; Rule: A successful reset invalidates all existing sessions for the account.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: New password entry with strength validation and confirm field.
2. Observe the result and verify the full behavior: New password entry with strength validation and confirm field.
**Expected Result:** New password entry with strength validation and confirm field — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-005 — All existing sessions invalidated on successful reset
**Type:** Edge
**Covers:** 3.1 → All existing sessions invalidated on successful reset; Rule: The new password must meet the strength policy and cannot be the same as the previous password.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: All existing sessions invalidated on successful reset.
2. Observe the result and verify the full behavior: All existing sessions invalidated on successful reset.
**Expected Result:** All existing sessions invalidated on successful reset — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-006 — Rate limiting on reset requests per account and per IP
**Type:** Edge
**Covers:** 3.1 → Rate limiting on reset requests per account and per IP; Rule: Reset events (requested, link sent, link used, expired, failed) are logged with timestamp and IP.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Rate limiting on reset requests per account and per IP.
2. Observe the result and verify the full behavior: Rate limiting on reset requests per account and per IP.
**Expected Result:** Rate limiting on reset requests per account and per IP — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-007 — Generic response for unknown emails (no account enumeration)
**Type:** Positive
**Covers:** 3.1 → Generic response for unknown emails (no account enumeration); Rule: The password reset is audit-logged with the account, the outcome, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Generic response for unknown emails (no account enumeration).
2. Observe the result and verify the full behavior: Generic response for unknown emails (no account enumeration).
**Expected Result:** Generic response for unknown emails (no account enumeration) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-008 — Reset event logging (requested, link sent, link used, expired, failed)
**Type:** Edge
**Covers:** 3.1 → Reset event logging (requested, link sent, link used, expired, failed)
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Reset event logging (requested.
2. Observe the result and verify the full behavior: Reset event logging (requested, link sent, link used, expired, failed).
**Expected Result:** Reset event logging (requested, link sent, link used, expired, failed) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-009 — Audit logging of the password reset
**Type:** Positive
**Covers:** 3.1 → Audit logging of the password reset
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the password reset.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical

## 3.2 Password Change

### TC-ST-01-03-010 — "Change password" entry point in Profile → Security
**Type:** Positive
**Covers:** 3.2 → "Change password" entry point in Profile → Security; Rule: The current password must be verified before a new password is accepted.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Change password" entry point in Profile → Security.
2. Observe the result and verify the full behavior: "Change password" entry point in Profile → Security.
**Expected Result:** "Change password" entry point in Profile → Security — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-03-011 — Current password verification before accepting a new password
**Type:** Positive
**Covers:** 3.2 → Current password verification before accepting a new password; Rule: The new password must meet the strength policy and cannot be the same as the current or recent previous passwords.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Current password verification before accepting a new password.
2. Observe the result and verify the full behavior: Current password verification before accepting a new password.
**Expected Result:** Current password verification before accepting a new password — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-012 — New password entry with strength validation and confirm field
**Type:** Edge
**Covers:** 3.2 → New password entry with strength validation and confirm field; Rule: Changing the password does not sign out the current session by default, but can invalidate all other sessions.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: New password entry with strength validation and confirm field.
2. Observe the result and verify the full behavior: New password entry with strength validation and confirm field.
**Expected Result:** New password entry with strength validation and confirm field — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-013 — "Cannot reuse previous password" check
**Type:** Edge
**Covers:** 3.2 → "Cannot reuse previous password" check; Rule: A wrong current password produces a specific "current password incorrect" message (the Student is already authenticated, so enumeration is not a concern).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Cannot reuse previous password" check.
2. Observe the result and verify the full behavior: "Cannot reuse previous password" check.
**Expected Result:** "Cannot reuse previous password" check — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-014 — Immediate application on success
**Type:** Positive
**Covers:** 3.2 → Immediate application on success; Rule: Change events (success, wrong current password, weak new password) are logged with timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Immediate application on success.
2. Observe the result and verify the full behavior: Immediate application on success.
**Expected Result:** Immediate application on success — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-015 — Optional invalidation of other sessions on change
**Type:** Edge
**Covers:** 3.2 → Optional invalidation of other sessions on change; Rule: The password change is audit-logged with the account, the outcome, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Optional invalidation of other sessions on change.
2. Observe the result and verify the full behavior: Optional invalidation of other sessions on change.
**Expected Result:** Optional invalidation of other sessions on change — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-016 — Change event logging (success, wrong current password, weak new password)
**Type:** Edge
**Covers:** 3.2 → Change event logging (success, wrong current password, weak new password)
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Change event logging (success.
2. Observe the result and verify the full behavior: Change event logging (success, wrong current password, weak new password).
**Expected Result:** Change event logging (success, wrong current password, weak new password) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-017 — Audit logging of the password change
**Type:** Positive
**Covers:** 3.2 → Audit logging of the password change
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the password change.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical

## 3.3 Password Policy Enforcement

### TC-ST-01-03-018 — Minimum length requirement (e.g., 8 characters)
**Type:** Positive
**Covers:** 3.3 → Minimum length requirement (e.g., 8 characters); Rule: The policy is applied consistently at registration, reset, and change; there is no weaker path.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Minimum length requirement (e.g..
2. Observe the result and verify the full behavior: Minimum length requirement (e.g., 8 characters).
**Expected Result:** Minimum length requirement (e.g., 8 characters) — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-03-019 — Character class requirements (uppercase, lowercase, number, symbol)
**Type:** Positive
**Covers:** 3.3 → Character class requirements (uppercase, lowercase, number, symbol); Rule: The strength meter gives specific, actionable hints (length, character class, common password, personal info, reuse).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Character class requirements (uppercase.
2. Observe the result and verify the full behavior: Character class requirements (uppercase, lowercase, number, symbol).
**Expected Result:** Character class requirements (uppercase, lowercase, number, symbol) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-020 — Blocked common passwords list
**Type:** Edge
**Covers:** 3.3 → Blocked common passwords list; Rule: The reuse history covers the last N passwords (e.g., 5); a match is rejected.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Blocked common passwords list.
2. Observe the result and verify the full behavior: Blocked common passwords list.
**Expected Result:** Blocked common passwords list — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-021 — Personal information check (password must not contain the Student's name or email)
**Type:** Positive
**Covers:** 3.3 → Personal information check (password must not contain the Student's name or email); Rule: A password containing the Student's name or email is rejected.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Personal information check (password must not contain the Student's name or email).
2. Observe the result and verify the full behavior: Personal information check (password must not contain the Student's name or email).
**Expected Result:** Personal information check (password must not contain the Student's name or email) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-022 — Reuse history: the new password cannot match any of the last N passwords
**Type:** Edge
**Covers:** 3.3 → Reuse history: the new password cannot match any of the last N passwords; Rule: Policy violations are logged (which rule failed) without storing the password itself.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Reuse history: the new password cannot match any of the last N passwords.
2. Observe the result and verify the full behavior: Reuse history: the new password cannot match any of the last N passwords.
**Expected Result:** Reuse history: the new password cannot match any of the last N passwords — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-023 — Real-time strength meter with specific, actionable hints
**Type:** Edge
**Covers:** 3.3 → Real-time strength meter with specific, actionable hints; Rule: The password policy enforcement is audit-logged with the account, the rule(s) triggered, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Real-time strength meter with specific.
2. Observe the result and verify the full behavior: Real-time strength meter with specific, actionable hints.
**Expected Result:** Real-time strength meter with specific, actionable hints — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-024 — Policy applied consistently at registration, reset, and change
**Type:** Positive
**Covers:** 3.3 → Policy applied consistently at registration, reset, and change
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Policy applied consistently at registration.
2. Observe the result and verify the full behavior: Policy applied consistently at registration, reset, and change.
**Expected Result:** Policy applied consistently at registration, reset, and change — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-025 — Policy violation logging
**Type:** Positive
**Covers:** 3.3 → Policy violation logging
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Policy violation logging.
2. Observe the result and verify the full behavior: Policy violation logging.
**Expected Result:** Policy violation logging — delivered exactly as documented.
**Priority:** High

### TC-ST-01-03-026 — Audit logging of the password policy enforcement
**Type:** Positive
**Covers:** 3.3 → Audit logging of the password policy enforcement
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the password policy enforcement.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical