Apple Passwords’ generated strong password format

Original Article ↗ Hacker News Discussion ↗

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 passwordrules HTML 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.