Password Strength Analyser and Security Recommendation System with Breach Intelligence and Encrypted Vault

Passwords are still the most common way people log in to web applications, enterprise systems and personal accounts. Biometrics and multi-factor authentication are becoming more common, but passwords remain dominant because they are simple, cheap to implement and work everywhere [1]. Studies of large anonymized password collections have shown again and again that many user-chosen passwords come from a surprisingly small search space. That makes them easy targets for dictionary attacks, brute-force attacks and credential stuffing with passwords from earlier leaks [2].

Most real systems still judge password strength by composition rules: a minimum length, plus an uppercase letter, a digit and a symbol. These rules are easy to meet without gaining any real strength. A password like "Password1!" ticks every box, yet it is one of the first guesses an attacker would try. Cracking simulations based on guessing have shown that following a composition policy has little to do with how well a password actually resists cracking [3].

In this paper we propose a Password Strength Analyser and Security Recommendation System that fills three gaps left by conventional approaches. First, strength estimation is shallow, so we combine entropy analysis with structural pattern detection. Second, conventional checkers know nothing about breaches, so we add a privacy-preserving breach-intelligence check. Third, credential hygiene is poor, so we provide a secure encrypted vault where strengthened passwords can be kept and reused during a session without being written down insecurely.

II. LITERATURE SURVEY

Wheeler [1] introduced zxcvbn, a pattern-matching password estimator that models how attackers actually guess, including dictionary words, dates, keyboard patterns and l33t-speak substitutions. His work showed that pattern-aware estimation is much more accurate than composition-rule checks. Bonneau [2] analyzed an anonymized corpus of 70 million passwords and measured the guessing entropy of real-world password distributions, setting empirical baselines that later strength-estimation research has widely used.

Kelley et al. [3] ran several password-cracking algorithms against large password sets under different composition policies. They found that stricter rules do not reliably make passwords harder to crack, and that some policies push users toward predictable workarounds, such as adding "1!" to a familiar word. Ur et al. [4] built and evaluated a data-driven password meter that gives users real-time, detailed feedback instead of a single pass/fail result, and found that this kind of feedback measurably improved the strength of the passwords people chose.

The NIST Special Publication 800-63B guidelines [5] formally advise moving away from forced periodic password changes and complex composition rules. They favour length, screening against lists of known-breached passwords, and secure storage. Hunt [6] brought breach screening to scale with the "Pwned Passwords" service, which popularized the k-anonymity protocol for checking whether a password has been exposed without revealing the full password or hash to the remote service. Pearman et al. [7] studied how people adopt password managers and found that convenient, well-integrated tools make users much more likely to use unique, strong passwords rather than reuse one weak one.

This work brings together four strands: pattern-aware strength estimation, evaluation of guessing resistance, breach screening through k-anonymity, and integrated secure storage. We combine them in a single Java system with no dependencies. To the best of the authors' knowledge, existing open tools cover these only separately.

III. PROBLEM STATEMENT

Take a user-supplied password P. Existing composition-rule checkers compute a binary or coarse pass/fail signal f(P) using only character-class membership and length, without considering how predictable the structure is or whether the password has been exposed in the real world. This leads to two kinds of error. False positives occur when a password that meets the rules (for example "Qwerty123!") is accepted even though it is very easy to guess. False negatives occur when a long, high-entropy passphrase without symbols is rejected even though it resists attacks well. In addition, f(P) says nothing about whether P has already appeared in a known data breach, and there is no way for the user to store a strengthened password securely once it has been chosen. The problem this work addresses is to design a scoring function S(P) that (a) matches true guessing resistance more closely than composition rules alone, (b) uses breach-exposure evidence without compromising the confidentiality of P, and (c) comes with a secure storage mechanism that encourages people to adopt the stronger credentials it produces.

IV. PROPOSED SYSTEM ARCHITECTURE

The proposed system has four modules that work together: the Analysis Engine, Breach Intelligence, the Recommendation Engine and the Encrypted Vault. They sit on a shared Java core and are available through two interchangeable front ends, a console application and a browser-based web application, as shown in Fig. 1.

Fig. 1. High-level system architecture.

A. Analysis Engine

This module estimates the effective character pool the password uses and calculates raw Shannon entropy as length × log?(pool size). A PatternDetector component then looks for keyboard walks, ascending or descending sequences, runs of repeated characters and date-like substrings, and each one costs a fixed number of entropy bits. The adjusted entropy is scaled to a 0-100 score and mapped to one of five categories, from Very Weak to Very Strong. A bundled common-password dictionary is checked alongside the pattern checks: an exact match sets the score to a floor value, and a dictionary substring adds a further entropy penalty (Section VI).

B. Breach Intelligence Module

This module follows the k-anonymity protocol. The password is hashed locally with SHA-1, and only the first five hexadecimal characters of the hash are sent to a remote breach-lookup API. The service returns every suffix that shares that prefix, and the comparison with the full suffix is finished locally, so the complete password or hash never leaves the client. If no network connection is available, the module quietly falls back to a bundled local corpus.

C. Recommendation Engine

This module links each specific weakness found by the Analysis Engine to a targeted, practical recommendation, such as avoiding keyboard-adjacent sequences, making the password longer, or avoiding embedded dates, instead of showing one generic message.

D. Encrypted Vault

The vault stores approved credentials using authenticated, password-based encryption. A 256-bit AES key is derived from a master password chosen by the user, using PBKDF2-HMAC-SHA256 with 200,000 iterations and a random 16-byte salt. The vault contents are encrypted with AES/GCM/NoPadding, which also detects tampering or a wrong master password.

V. METHODOLOGY

We built the system iteratively and in modules. First we analysed the requirements and identified the limits of composition-rule checkers described in Section II. We then designed the scoring algorithm to combine entropy estimation with pattern-based penalties (Section IV-A). After that, each module (Analysis Engine, Breach Intelligence, Recommendation Engine and Vault) was implemented separately using only the Java Development Kit standard library (java.security, javax.crypto, java.net.http and com.sun.net.httpserver) [8]. Avoiding external dependencies keeps the system portable and easy to audit. Because each module could be tested on its own, we were able to verify the scoring function at unit level before connecting it to the console and web front ends. We then ran functional tests end to end on both front ends, followed by an evaluation on a representative password sample, discussed in Section VII.

VI. IMPLEMENTATION DETAILS

The scoring function starts from a base entropy estimate and applies cumulative penalties. For a password of length L that uses a character pool of size N (determined by which of the lowercase, uppercase, digit and symbol classes are present), the raw entropy is:

E_raw = L × log?(N)

Each structural finding f? returned by the PatternDetector (keyboard walk, sequential run, repeated characters or date pattern) subtracts a fixed penalty p? ∈ [6, 12] bits, and a dictionary-substring match subtracts a further 10 bits. This gives the effective entropy E_eff = max(0, E_raw − Σp?). The final score is S = min(100, round((E_eff / 80) × 100)). It is also capped at 35 for any password shorter than 8 characters, whatever its character variety, because short passwords are especially vulnerable to brute-force search no matter how large the alphabet is. A password that exactly matches an entry in the bundled common-password corpus skips this calculation and gets a fixed score of 2, since it is at immediate risk of exposure. The 80-bit normalisation constant marks the point where the scale saturates. The penalty values are fixed design parameters, not values fitted to empirical data, a limitation discussed in Section IX. Fig. 2 summarises the complete scoring pipeline.

Fig. 2. Scoring pipeline of the Analysis Engine.

For the encrypted vault, AES-256 keys are derived as K = PBKDF2-HMAC-SHA256(masterPassword, salt, 200000). Every save re-encrypts the full vault contents with a freshly generated random 96-bit initialization vector, because reusing an IV under the same key would break the confidentiality guarantees of GCM mode. PBKDF2 [11] and AES-GCM [12] are used as their standards specify, through the JDK implementations [8]. We chose PBKDF2 over the memory-hard scrypt function [9] because it is built into the JDK, which fits the zero-dependency goal. The 200,000-iteration work factor is lower than the 600,000 iterations OWASP currently recommends for PBKDF2-HMAC-SHA256 [10], so it should be raised in a production deployment.

VII. RESULTS AND DISCUSSION

We evaluated the system on ten representative passwords, covering trivial ones, ones that meet composition rules but are still weak, and genuinely high-entropy ones. Table I shows the score, category and entropy computed by the implemented Analysis Engine.

Table I. Analyser Output On Representative Passwords

The results support our central hypothesis: passwords that merely satisfy composition rules are correctly told apart by their structure. "qwerty12345" meets a naive length-plus-digit rule, but it scores only 31/100 because of its keyboard-walk and sequential-run penalties. "P@ssw0rd2024" and "Tr0ub4dor&9" both use common substitution patterns, yet they still score 90 or higher because their overall entropy stays high despite minor penalties. Trivial passwords and exact corpus matches ("123456", "password", "password123") are correctly floored at a score of 2, which reflects immediate exposure risk rather than a graded weakness. The passphrase-style input "correcthorsebatterystaple" reaches the maximum score even though it uses only lowercase letters. This fits what entropy theory predicts: once length is large enough, it outweighs the pattern-detection penalties.

To put these scores in context, Table II compares the analyser with a conventional composition-rule checker (at least eight characters, containing upper-case, lower-case, digit and symbol characters) and with the zxcvbn estimator [1] (Python port, score 0-4) on the same ten passwords.

TABLE II. Comparison With Composition-Rule And Zxcvbn Baselines