Password strength diagnosis and cracking time calculation checker | ZeroTools

This screen runs the evaluation function within the same browser every time the value in the input field changes, updating the simple 0-4 point score, the theoretical bit count calculated from character types and length, and the estimated time across three types of fixed trial speeds.

It is not a system where you press a submit button to diagnose. The eye icon toggles the input field's type between password and text, and the clear button empties the current input.

The input value is placed into React state and the screen's DOM for evaluation. The diagnostic component has no process for saving the input to a database, local storage, or IndexedDB, nor does it have a process for creating a history list.

The screen's state is initialized upon reloading or navigating away, but there is no process to overwrite the used memory area with zeros, and it does not guarantee that physical traces on the device are erased.

Pressing copy writes the current input to the Clipboard API, and only if successful, changes to a check display for 2 seconds. The return after 2 seconds is only for the icon; it is not an action that clears the clipboard.

Whether OS clipboard history or browser extensions can access the value cannot be controlled from this component. Instead of pasting an important password you actually use, you have the option of checking the mechanism with a test string sharing the same characteristics.

"Generate 16-character candidate" is an auxiliary feature that inserts a new candidate into the input field to perform the same evaluation.

It does not save the diagnostic results to a file, change passwords on services you use, or register them in a password manager. The displayed labels are also not a passing notification that you meet the requirements of a specific service.

In the calculation of theoretical bits, if there is an ASCII lowercase letter in the input, 26 is added to the candidate pool; 26 for ASCII uppercase; 10 for numbers; and 33 for any other character.

For example, if it's only lowercase and numbers, it's 36 types; if it includes all 4 categories, it's 95 types. It doesn't count the number of character types actually used in the input, but treats the entirety of a category as candidates if even one character from it is found.

The displayed value is an integer rounded off from multiplying JavaScript's password.length by the information entropy per character in the pool, obtained via log2.

The formula is Length in UTF-16 code units × log2(Assumed pool size). A password with only lowercase letters rounds 8 × log2(26) to 38 bits.

If it's 12 code units containing lowercase, uppercase, numbers, and symbols, it rounds 12 × log2(95) to approximately 79 bits.

This length is not necessarily the number of characters users visually count or the number of Unicode graphemes. Because a typical emoji is 2 code units in JavaScript's UTF-16, even a single emoji might be calculated as length 2.

Japanese characters, spaces, and emoji are not ASCII alphanumeric, so they all fall under the same "symbols present" judgment, simply adding 33 types.

There is no feature to check the number of kanji types or the total candidate number of emojis.

The calculation represents a candidate space where each position is assumed to be uniformly and independently chosen from the entire assumed pool.

Words, dates, names, substitution rules, or keyboard habits thought up by humans are not reflected in the theoretical value. An input like DogCat123! is also calculated as if 10 code units were randomly chosen from 95 types.

If the actual generation process is predictable, the displayed value may greatly overestimate the effective difficulty of guessing.

This is not a hash analysis or statistical measured entropy.

The score starts at 0 points, adds 1 point for 8 or more code units, and adds another 1 point for 12 or more. If it includes 3 or more of the 4 categories (lowercase, uppercase, numbers, symbols), it adds 1 point, and if it includes all 4 categories and has a length of 10 or more, it adds another 1 point.

The maximum is 4 points. The 0 to 4 points correspond sequentially to 5 labels: "Very Weak", "Weak", "Fair", "Strong", and "Very Strong".

There are 4 bars in the meter. Even at 0 points, if the input is not empty, the first bar is displayed in red, but this does not mean it earned 1 point; it is a display to make the "Very Weak" state visible.

Please check the label and score, and do not judge by the number of bars alone. The point conditions are unique to this screen and are not certification results from external standards like NIST.

There are 3 types of deduction conditions. The first is an exact match with 20 built-in strings, ignoring uppercase and lowercase.

This includes password, 123456, qwerty, admin, etc., but it does not connect to a large leak corpus or dictionary. It also does not check partial matches, usernames, email addresses, service names, or previously used values.

The second is sections where the same character repeats 4 or more times consecutively. The third checks whether a forward 4-character sequence extracted from the input is included within the fixed string abcdefghijklmnopqrstuvwxyz01234567890qwertyuiopasdfghjklzxcvbnm.

This targets things like abcd, 1234, or qwer. Reverse sequences, dates, and common character substitutions are exempt, but sequences like 90qw at the concatenation boundary of the fixed string will match.

If any of the three conditions are met, 2 points are subtracted. Even if multiple conditions are met, penalties are not stacked. The penalty is applied as Math.max(1, score - 2), meaning the score drops to a minimum of 1.

However, if the length is less than 4, it is set to 0 at the end. Note that this pattern penalty only applies to the score and does not reduce the theoretical bits in Chapter 2 or the time displayed in the next chapter.

The impression that the label and time for the same input differ is due to these different calculation paths.

The time display calculates the total number of candidates by raising the assumed pool size to the power of the input length, and assumes that on average, the correct answer is reached when half are tried.

That half candidate count is divided by three types: 100 times per second, 10,000 times per second, and 100,000,000,000 times per second.

On the screen, these are sequentially displayed as "Slow Online Assumption", "Fixed Assumption", and "Fast Offline Assumption". They are not values measured from a specific PC, GPU, or supercomputer.

Taking a lowercase-only password as an example, the total candidates are 26 to the 8th power, and the average trials are half of that.

This displays as about 33 years at 100/sec, about 121 days at 10,000/sec, and about 1 second at 100 billion/sec. However, because this input also matches one of the 20 built-in common strings, an actual attacker might try it early without waiting for the brute-force order.

The time calculation does not reflect that priority.

Seconds less than 1 are displayed as "Instant", and rounded to seconds, minutes, hours, days, years, thousand years, and million years.

If it exceeds JavaScript's numerical range and becomes Infinity, it displays "display limit exceeded". This does not mean it is forever impossible to decipher, but is simply a state where this simple formula cannot display it as a normal number.

Actual offline guessing speeds depend on the hash or key derivation method used by the service for storage, Salt, cost factors, and attacking hardware.

Online, rate limits, account lockouts, detection, and multi-factor authentication determine the outcome. This screen has no fields to input those, and dictionary attacks, reuse of leaked values, rule-based attacks, and phishing are not reflected in the time.

The time is a fixed model for comparison, not the decryption deadline for a specific account.

The built-in generator uses a total of 70 types: 26 lowercase, 26 uppercase, 10 numbers, and 8 symbols. First, it selects one character from each group to create a state containing at least one of all 4 categories.

Then, it adds 12 characters from the combined pool of 70 types, and shuffles the total 16 characters using the Fisher–Yates method.

The generation count, length, and symbol set cannot be changed from the screen.

A common secure random function is used for character selection and shuffling. This obtains a 32-bit value with crypto.getRandomValues, and performs rejection sampling by discarding and redrawing the upper range of values that cannot be evenly divided by the number of candidates.

If Web Crypto is unavailable, it does not fall back to Math.random; it stops generation and displays an error. The W3C specification defines getRandomValues as an API to obtain cryptographically strong random values, but does not dictate an information-theoretical lower bound for entropy.

The generator's candidate pool of 70 types and the diagnostic side's assumption do not match. The generation result will always contain one of the 8 symbols, but the diagnosis treats having a symbol as 33 types, assuming 95 types overall.

Therefore, the theoretical value displayed immediately after generation is not strict entropy representing the character set actually used by the generator and the minimum one-character guarantee.

It usually scores 4 points due to the 4 categories and 16 characters, but it may incur a penalty if it accidentally includes fixed sequential patterns or 4 consecutive identical characters.

When adopting a generated candidate, check the service's maximum length, allowed symbols, and specific requirements. The built-in generator only places candidates on the screen; it does not register them with the service, save history, or move them to a password manager.

If you wish to further select length or exclude similar characters, please use the relevant Web Crypto password generator accordingly.

NIST SP 800-63B-4 explains that it is difficult to estimate the effective strength of a user-chosen password as information-theoretical entropy, and treats length as the primary factor.

It also asks service providers to check against a blocklist of common, predictable, and compromised passwords, rate-limit failed attempts, and allow password managers and pasting, while stating that composition rules mixing character types should not be imposed.

The minimum length of 15 characters in the same document is a requirement for verifiers offering single-factor authentication, and a minimum of 8 characters for verifiers using passwords as part of MFA.

The purpose and target differ from this screen's point-addition criteria of 8 or 12 code units. Even if the screen yields 4 points, it doesn't mean it is 15 characters or more, and checking against 20 items is not a substitute for the sufficient blocklist required on the service side.

The diagnostic component has no process to transmit the input value externally for diagnostic purposes. However, separate communications for the entire page may occur, such as page display files, access analytics, and advertisements.

The input value is placed in the DOM and JavaScript state, will appear in plain text on the screen if the display button is pressed, and will be passed to the OS clipboard if copied.

Browser extensions, device malware, and shoulder surfing cannot be prevented by this simple diagnosis.

The score, theoretical bits, and time are each calculated based on different assumptions. High values do not detect reuse, phishing, password list attacks, or poor storage practices by the service.

Use unique values for each account, and combine them with a password manager and multi-factor authentication if the service supports it.

If there is no need to enter a real password, just check the calculation tendencies with a test string of the same length and composition.