Passwords, passphrases, and browser encryption

A password generator can select uniformly from a known set of outputs. That makes its search-space calculation transparent: length and pool size determine the number of possible results. A password strength checker sees only one finished string. It usually cannot know whether that string came from a secure generator, a quote, a keyboard walk, a leaked password, or a personal pattern.

Treat generated search-space bits as a property of the generation process, not a magical property embedded in the text. A meter that multiplies length by character-pool size can dramatically overrate human choices. Pattern checks and small blocklists help, but they cannot reproduce an attacker’s full dictionaries and breach data.

NIST SP 800-63B-4 centers password-verifier guidance on sufficient length, support for password managers and paste, blocklisting common or compromised values, and rate limiting. It does not require arbitrary mixtures of uppercase, lowercase, numbers, and symbols, and it discourages forced periodic changes without evidence of compromise.

Those are requirements for systems that accept passwords, not a promise that any 15-character string is safe. As a user, the practical strategy is a unique generated password for each account, stored in a password manager, with phishing-resistant multi-factor authentication where available.

A passphrase can make length easier to remember and type. Its security model depends on the size of the word list and the number of independent picks. If a list has 739 words, each random word contributes about log₂(739), or 9.5 bits, to the generated search space. Six independent picks create a much larger space than four.

Do not turn the output into a familiar sentence or swap random words for birthdays, pets, quotations, or places. Those edits make it more memorable to an attacker too. Separators and deterministic capitalization may help with site rules, but adding another independently selected word has the clearer security effect.

An offline guess-time display needs at least two assumptions: how many candidate passwords an attacker tests each second and how candidates are ordered. Hashing algorithms vary by many orders of magnitude, and attackers try common patterns long before exhaustive random strings. A “billions of years” output based on a uniform model can be meaningless for a reused phrase found in a breach.

Use such numbers to compare two uniformly generated settings, not to certify a real account. A checker that is honest about this limitation is more useful than one that promises a precise compromise time.

AES-GCM provides confidentiality and authentication: modified ciphertext fails verification instead of producing silent garbage. A user password is not an AES key, so PBKDF2 can derive a key through many repeated HMAC operations and a unique random salt. A new random IV is required for each AES-GCM encryption under a key.

The ciphertext can still be attacked offline. A weak password remains weak, and no server can reset a forgotten password when there is no recovery key. The page, device, browser, and extensions are also part of the trust boundary. Use audited secure-messaging or storage software for high-impact secrets rather than treating a web utility as a complete security system.

Generate a unique credential, save it directly into a reputable password manager, and avoid copying it through chats or documents. Turn on multi-factor authentication. Keep recovery codes offline or in an appropriately protected vault. If a service reports a breach, change that one unique credential; reuse is what turns one incident into many.

When testing a meter, use a synthetic example with the same shape rather than pasting a live password. Local execution reduces one risk, but limiting unnecessary exposure is still the better habit.