Apple Passwords’ generated strong password format
Apple’s updated password generator creates syllable-like strings with predictable structure, aiming to be easier to read, type, and communicate than fully random character soup, especially on awkward keyboards like TVs or game controllers. Commenters weigh the entropy trade‑off — roughly 71 bits versus higher‑entropy random strings or long word-based passphrases — against the practical benefits of memorability and reduced user error, generally concluding it is sufficient if combined with proper hashing and unique passwords. The thread also highlights ongoing problems with inconsistent website password rules, paste blocking, and length limits, and contrasts passwords with emerging alternatives such as passkeys.
Overall reaction to Apple’s format
- Many commenters think the CVC-style, syllable-based strong passwords are a good balance of security and usability, especially compared to fully random symbol-heavy strings.
- Others worry that constraining the structure (fixed length, positions of uppercase/digit, syllable patterns, hyphens) reduces entropy compared to a truly random password of similar length.
Entropy and security trade‑offs
- Several posters derive or reference estimates: Apple’s format is said to yield ~71 bits of entropy (up from 69 in the previous format), versus ~100+ bits for fully random same-length strings.
- Some argue this is still plenty when combined with modern slow hashing (bcrypt/Argon2/scrypt), making brute force impractical.
- Others are uneasy: 71 bits feels marginal if hashes are unsalted/fast-hashed (MD5/SHA), or for well-resourced attackers. Some advocate 80–100+ bits as a safer norm.
- There’s debate whether practical web attacks are limited mainly by password reuse and guessability, versus raw entropy. One side claims “no one brute forces” beyond low thresholds; others cite real hash-cracking and password spraying.
Usability, ergonomics, and edge devices
- Strong theme: random special characters are painful on TV remotes, VR keyboards, game controllers, cameras, VNC consoles, mismatched keyboard layouts, or low-quality on‑screen keyboards.
- Syllable-like chunks, mostly lowercase, and avoiding tricky symbols are seen as a big usability win; several people share horror stories where complex generated passwords were nearly impossible to enter.
- Some want ambiguous characters (O/0, l/1, etc.) excluded entirely; others say Apple mitigates this with monospace fonts and slashed zeros.
Alternatives: passphrases and other generators
- Many advocate real-word passphrases (Diceware, xkcd-style), sometimes with small deterministic embellishments (one capitalized word, a digit or symbol suffix) to satisfy legacy rules.
- Others prefer simpler generators: only lowercase (or lower+upper+digits) but longer, or pronounceable-password tools and base58 schemes.
- Some note that adding more words usually adds far more entropy and is easier to remember than fiddly format randomization.
Broken site rules and ecosystem issues
- Extensive frustration with archaic site policies: banned characters, mandatory symbols but tiny allowed sets, short maximum lengths, silent truncation, disabled paste, on‑screen keypads, frequent forced rotations.
- Apple’s open-source “password rules” database and
passwordrulesHTML attribute are highlighted as attempts to adapt generators to inconsistent site requirements, though coverage is incomplete. - There’s tension between praising Apple’s UX focus and concern that platform-level choices may pressure smaller sites and tools to conform.