Password Policy Auditor & Hygiene Trainer for Synthetic Accounts (Java/MySQL)

PassCheck Auditor is an individual Java Swing desktop application that helps a college IT office audit its password policy and train staff in password hygiene — using a roster of 200 clearly-labelled synthetic accounts, never real users.

The office can define policy sets per role (faculty, student, guest) that follow NIST SP 800-63B: minimum length 8 (the office chooses 12), maximum length at least 64, all printable characters allowed, no forced composition rules, no forced periodic rotation, and a blocklist of common and breached passwords. The evaluation engine then tests any candidate password against the policy: length boundaries, personal-information matches, a bundled dictionary of the most common passwords, keyboard-walk patterns (qwerty-style rows), repeated characters and sequences. It reports a verdict per rule, an entropy estimate and an offline crack-time figure at a stated guess rate.

A breach check sends only the first five characters of the password's SHA-1 hash to the public Pwned Passwords range API — the k-anonymity design means the full password and its complete hash never leave the machine — with an offline fallback that uses the bundled blocklist when there is no internet, so the viva demo never depends on a network.

Every run is recorded, and the tool produces per-account and aggregate compliance reports as CSV. A trainer mode with a live strength meter and plain-language feedback makes the tool usable in a 30-minute hygiene session for staff. Storage follows secure practice: demo passwords are bcrypt-hashed, SQL uses prepared statements, nothing sensitive is logged.

College password policies in India are usually copied from an old template: eight characters, one capital, one digit, one special symbol, changed every 90 days. Modern guidance — NIST SP 800-63B and CERT-In's own awareness material — has abandoned composition rules and calendar-based rotation in favour of length, blocklists of breached passwords, and evidence-triggered resets. But a college office has no practical way to see whether its circular would actually stop the passwords users really choose, and it cannot ethically collect real passwords to find out. Staff therefore satisfy the rules with Password@123-class passwords that are trivially guessable and appear on every breach list. There is a need for a policy auditor and hygiene trainer that works entirely on synthetic accounts: it encodes the modern rules, tests candidate passwords against them (including a privacy-preserving breach check), reports policy gaps in plain language, and doubles as a training tool — without ever touching a real user's credential.

Abstract

Passwords remain the first line of defence for college systems — ERP logins, lab machines, Wi-Fi portals — yet the typical Indian college policy still enforces rules that guidance has moved beyond: mandatory special characters, 90-day forced resets, maximum lengths too short for passphrases. This project builds PassCheck Auditor, a Java/MySQL desktop application that lets a college IT office test its password policy against evidence and train staff, using synthetic accounts so that no real credential is ever handled.

Introduction

A college IT office writes a password rule in a circular, but nobody measures what the rule actually catches or misses. CERT-In's awareness material and NIST SP 800-63B now agree on the essentials: length beats composition tricks, common passwords must be blocked, and rotation should be triggered by evidence of compromise, not by the calendar. An auditor that encodes those rules turns a policy document into something testable.

Existing System

• The policy lives in a circular; compliance is assumed, never measured.
• "Strong password" advice on notice boards still pushes composition rules that NIST dropped in 2017 and reaffirmed since.
• Staff pick Password@123-class passwords that satisfy composition rules yet top every breach list — exactly the guessable patterns CERT-In's booklet warns about.
• When a breach makes headlines, the office has no way to check whether its users' habits would survive the same leak — and cannot ethically collect real passwords to find out.
• Limitations: no evidence, no tooling, no training loop, and any attempt to audit real accounts raises privacy problems the office cannot solve.

Proposed System

• A synthetic roster: 200 fictional accounts (faculty/student/guest roles) whose "passwords" are submitted only by the person running the audit — no real user is ever involved, and the demo data ships seeded.
• A policy editor with role-based policy sets encoding NIST-aligned rules: length range, blocklist, personal-info checks, allowed characters, and an explicit switch recording that rotation is evidence-triggered.
• An evaluation engine with per-rule verdicts: length, dictionary blocklist, keyboard walks, repeats/sequences, personal-info match, plus entropy bits and crack-time at a documented guess rate.
• A breach check via the Pwned Passwords k-anonymity range API (first five SHA-1 hex characters only), with an offline fallback to the bundled list.
• Bulk audit from CSV with per-account compliance reports, exportable for the office's records.
• A trainer mode: live strength meter, explainable feedback, a short lesson on passphrases and evidence-based rotation.

Feasibility Study

• Technical: Java 17 with Swing, JDBC and jBCrypt, and MySQL 8 — everything the IGNOU syllabus already teaches; the HTTP call uses the JDK's built-in HttpClient. The application runs entirely offline except the optional breach check.
• Economic: Zero licence cost; runs on any office PC with 4 GB RAM.
• Operational: The office keeps its circular; the auditor shows which rules would fail today and which habits need training, on synthetic data — privacy and the spirit of the DPDP Act, 2023 preserved by design.

In scope

• A single-user Java Swing desktop application for the IT office; Windows/Linux/macOS where Java 17 runs.
• Synthetic accounts only: 200 seeded fictional identities with roles and policy sets.
• Policy editor, evaluation engine with per-rule verdicts, entropy and crack-time estimates.
• Breach check through the Pwned Passwords k-anonymity range API, plus an offline mode.
• Bulk audit from CSV, compliance reports, CSV export, audit log.
• Trainer mode with strength meter and a short lesson.

Out of scope (v1)

• Any connection to real college systems — LDAP/Active Directory integration, live password-reset hooks or reading real user hashes.
• Collection or storage of any real person's password; the tool audits candidate passwords typed in during the session.
• MFA management, SSO, or password-manager provisioning (discussed as future scope).
• Argon2id storage option (bcrypt is used; Argon2id is listed as future work).
• Multi-language UI and scheduled automatic audits.

The project follows the Waterfall model with stage gates, chosen deliberately for an individual IGNOU project whose requirements are fixed and well understood, and because IGNOU's own flow — synopsis approval before implementation, report at the end — mirrors staged delivery. Each stage ends with a guide sign-off.

Testing approach: unit tests for every rule (an 11-character password fails a 12-character policy; qwerty123 fails the walk check; correct-horse-battery-staple passes length and dictionary checks; a blocked breached password fails the corpus check offline), integration tests running the engine against a test database, and documented black-box cases for every screen. The security checklist (hashed storage, prepared statements, no sensitive logging) is reviewed line by line in the report's security section.

PassCheck Auditor is a classic three-layer desktop application:

1. UI layer — Java Swing frames and panels: the roster table, the policy editor, the evaluator panel with the live strength meter, and the report viewer. No business logic lives here.
2. Service layer — the policy engine (rule objects evaluated in order, each returning a pass/fail and a reason), the estimator (entropy and crack time), the breach-check service (JDK HttpClient, SHA-1 prefix, HTTPS), and the report builder.
3. Data layer — MySQL 8 through JDBC with prepared statements; jBCrypt hashes any demo password before it is stored; an audit-log table records every evaluation run.

flowchart TD
  UI["Swing UI: roster, policy editor, evaluator, reports"] --> SVC
  SVC["Service layer"] --> PE["Policy engine: rule objects"]
  SVC --> ES["Estimator: entropy + crack time"]
  SVC --> BC["Breach-check service"]
  BC -->|"SHA-1 first 5 chars only, over HTTPS"| API[("Pwned Passwords range API")]
  PE --> DAO["DAO: prepared statements"]
  ES --> DAO
  BC --> DAO
  DAO --> DB[("MySQL 8")]
  DAO --> AL["Audit log"]

ER diagram

erDiagram
  POLICY_SET ||--o{ ACCOUNT : "governs"
  ACCOUNT ||--o{ EVALUATION : "is tested in"
  EVALUATION ||--o{ VIOLATION : "reports"
  EVALUATION ||--o{ AUDIT_LOG : "is recorded in"

  POLICY_SET {
    int id PK
    string name
    int minLength
    int maxLength
    string blocklistRef
    bool rotationEvidenceOnly
  }
  ACCOUNT {
    int id PK
    string username UK
    string role
    int policySetId FK
    string demoPasswordHash
    bool synthetic
  }
  EVALUATION {
    int id PK
    int accountId FK
    string verdict
    int entropyBits
    int breachCount
    datetime evaluatedAt
  }
  VIOLATION {
    int id PK
    int evaluationId FK
    string ruleCode
    string message
  }
  AUDIT_LOG {
    int id PK
    int evaluationId FK
    string action
    datetime loggedAt
  }

DFD — Level 0, Level 1 and Level 2 (evaluate process)

flowchart LR
  O(["IT Officer"]) -- "policy, candidate passwords, audit request" --> SYS(("PassCheck Auditor"))
  SYS -- "verdicts, compliance report, CSV" --> O
  API(["Pwned Passwords API"]) -- "hash-suffix list" --> SYS

flowchart TB
  O(["IT Officer"]) --> P1["1.0 Manage synthetic accounts"]
  P1 <--> D1[("D1 Accounts")]
  O --> P2["2.0 Evaluate password"]
  O --> P3["3.0 Run bulk audit"]
  P2 --> D2[("D2 Policy sets")]
  P2 --> P4["4.0 Build report"]
  P3 --> P2
  P4 <--> D3[("D3 Evaluations & audit log")]
  P4 -- "CSV report" --> O
  P2 --> E1(["Pwned Passwords API"])

flowchart TB
  P2["2.0 Evaluate password"] --> P21["2.1 Normalise input"]
  P21 --> P22["2.2 Policy rule checks: length, chars, personal info"]
  P22 --> P23["2.3 Dictionary, walk, repeat and sequence checks"]
  P23 --> P24["2.4 Breach check via k-anonymity prefix"]
  P24 --> P25["2.5 Score, verdict and reasons"]
  P22 <--> D2[("D2 Policy sets")]
  P23 <--> D4[("D4 Blocklist")]
  P25 --> D3[("D3 Evaluations")]

The breach check hashes the candidate with SHA-1, sends only the first five hex characters to GET /range/{prefix}, downloads the matching suffixes and compares locally — the full hash and the password never leave the machine, which is the k-anonymity property the report's security section explains.

• Argon2id as an additional storage option alongside bcrypt, with a benchmark comparison in the report.
• Tin-check for dates and roll numbers in the pattern engine (birthdates and register numbers are the most common personal-info leaks in Indian colleges).
• Policy-gap scorecard: compare the college's written circular, entered once, against the NIST-aligned sets and print a gap list the office can act on.
• Have-I-Been-Pwned account check (email-based, with consent) extended to the synthetic roster's addresses.
• Multilingual trainer mode in Hindi and one regional language for staff sessions.
• Scheduled audits that re-run the last bulk CSV monthly and track the pass rate over time.