Laptop screen showing password requirements with increasingly complex rules

At 08:17 this morning, I attempted to check my email.

ProtonMail informed me: “Your password has expired. Please create a new password.”

This took 47 minutes to resolve.

It is Tuesday. I have frequency measurements scheduled for 14:30. I do not have time for password entropy calculations before breakfast.

08:17 - The Requirements

New password must contain:

  • Minimum 12 characters
  • At least one uppercase letter
  • At least one lowercase letter
  • At least one number
  • At least one special character (!@#$%^&*)
  • Cannot be similar to previous password
  • Cannot contain common words
  • Cannot contain sequential characters (123, abc)
  • Cannot be password you used in last 6 months

My previous password: 18 characters long. Referenced my career at Laboratory 23-Б. Contained only lowercase letters and numbers. I could type it without looking. Never forgot it.

ProtonMail’s assessment: “Weak. Contains common word. No special characters.”

This worked perfectly for 3 years.

08:22 - The Entropy Problem

I understand the mathematics. Password strength is measured in bits of entropy.

Entropy calculation:

  • If password has N possible characters and length L
  • Entropy = log₂(N^L)
  • More entropy = more possible combinations = harder to guess

My old password analysis:

  • Character set: lowercase letters + numbers = 36 possible characters
  • Length: 18 characters
  • Entropy ≈ log₂(36^18) ≈ 93 bits

A “strong” 12-character password with all requirements:

  • Character set: uppercase + lowercase + numbers + special = ~72 characters
  • Length: 12 characters
  • Entropy ≈ log₂(72^12) ≈ 74 bits

Mathematical result: My “weak” 18-character password has MORE entropy than their “strong” 12-character requirement.

But ProtonMail does not accept this argument.

08:30 - The Attempts

Attempt 1: Laboratory23-Б!

  • Contains uppercase ✓
  • Contains lowercase ✓
  • Contains number ✓
  • Contains special character ✓
  • Result: “Too similar to previous password”

Attempt 2: Frequency@Counter47

  • All requirements met
  • References current research
  • Result: “Password must not contain dictionary words”

Frequency and counter are both dictionary words. This is technically correct but frustrating.

Attempt 3: Fr3qu3ncy@C0unt3r47

  • Replaced letters with numbers (classic substitution)
  • Result: “Common substitution pattern detected”

They are checking for leetspeak. I am simultaneously annoyed and impressed.

Attempt 4: Tue$day_Anomaly_2026

  • References the Tuesday Anomaly
  • All requirements met
  • No dictionary words in sequence
  • Result: “Password contains year. Not recommended.”

Not rejected, just warned. I could use this.

But.

It is Tuesday. If I use “Tuesday_Anomaly” as password on a Tuesday, am I contributing to the Tuesday Anomaly? Is password creation affected by day of week? This requires measurement.

Attempt 5: Random characters, generated by closing eyes and hitting keyboard.

  • Result: “Password accepted. Strength: Very Strong”

Success. Also: I will never remember this.

09:04 - The Documentation Problem

I now have password I cannot remember.

Options:

  1. Write it down (defeats purpose of strong password)
  2. Use password manager (need password to access password manager)
  3. Memorize it (unlikely, am 52 years old, memory not improving)
  4. Reset password every time (will require new password each time)

I chose Option 1. Password is written in notebook, hidden inside drawer, under folder labeled “Equipment Calibration Notes 1998.”

Security assessment: If someone breaks into apartment, searches through drawer, opens folder about 1998 calibration data, and reads notebook… they deserve access to my email.

Contents of my email worth stealing:

  • Correspondence about atmospheric pressure
  • Blog post drafts about refrigerators
  • One email from 14-year-old about fake research consortium
  • Approximately 0 rubles in financial value

09:15 - The Fascination (Despite Frustration)

The mathematics IS interesting.

Entropy improvement from each additional character:

For 72-character set (full complexity):

  • 12 characters: ~74 bits entropy
  • 13 characters: ~80 bits entropy (+6 bits = 64x harder to crack)
  • 14 characters: ~86 bits entropy (+6 bits = another 64x harder)
  • 15 characters: ~92 bits entropy

Each additional character multiplies difficulty by 72.

Adding just 3 characters makes password 373,248 times harder to crack.

This is elegant. One character = enormous security improvement.

But also:

My 18-character password (36-character set) had approximately 1.99 × 10^28 possible combinations.

A 16-character password (72-character set) has approximately 2.03 × 10^29 combinations.

My old password was actually comparable in entropy to modern “strong” passwords. But contained “dictionary word” so was rejected.

This is security theater. They optimize for appearance of security over actual entropy.

I understand why (most users would choose “password123”), but it is still frustrating.

10:30 - The Measurement Opportunity

While documenting this frustration, I realized: measurable phenomenon.

Research question: Does password complexity affect typing accuracy and time?

Hypothesis: Complex passwords with special characters require more time and produce more errors than simple long passwords.

Methodology:

  • Two test passwords (not my actual password):
    • Simple: measurementschedule (20 chars, lowercase only)
    • Complex: M3@sur3m#nt$ch3dul3! (20 chars, full complexity)
  • Type each 10 times
  • Measure: time to type, number of errors, cognitive load (subjective)
  • Control: Same keyboard, same time of day, same lighting

Results (10 trials each):

Simple password:

  • Average time: 3.2 seconds
  • Errors: 2 total (0.2 per attempt)
  • Cognitive load: Low (muscle memory after 3 attempts)

Complex password:

  • Average time: 8.7 seconds
  • Errors: 17 total (1.7 per attempt)
  • Cognitive load: High (must think about each character)

Conclusion: Complex password takes 2.7x longer and produces 8.5x more errors.

Security tradeoff: Slightly stronger password (entropy) vs. significantly higher user frustration and error rate.

If users write down complex passwords because they cannot remember them, have we increased or decreased actual security?

This is measurement nobody asked for. I documented it anyway.

14:30 - The Tuesday Measurement (As Scheduled)

Despite password frustration, I conducted the Tuesday frequency measurement.

Context: Dima’s fake prediction suggested frequency elevation between 14:30-14:45. I know prediction was fabricated. I am measuring anyway because pattern-seeking is compulsion.

Methodology:

  • Frequency counter (10-minute warm-up completed by 14:20)
  • Baseline: 14:00-14:30 (30 minutes before)
  • Target: 14:30-14:45 (15 minutes, the “prediction window”)
  • Follow-up: 14:45-15:15 (30 minutes after)
  • Measurements every 60 seconds

Results:

Time Period Average Frequency Notable Observations
14:00-14:30 49.94 Hz Stable, ±0.02 Hz variation
14:30-14:45 49.96 Hz Slightly elevated (+0.02 Hz)
14:45-15:15 49.93 Hz Return to baseline

Statistical analysis:

  • Elevation during prediction window: +0.02 Hz
  • Dima predicted: +0.4 to +0.6 Hz
  • Actual elevation: 33x smaller than prediction
  • Within normal measurement variance
  • Conclusion: No anomaly detected. Dima’s prediction was incorrect (as expected).

But.

Frequency WAS slightly higher during the exact window he specified.

Possible explanations:

  1. Random variation (most likely)
  2. Confirmation bias (probable - I was looking for elevation)
  3. Measurement error (possible - 47€ device)
  4. Coincidence (statistically possible)
  5. Dima is secretly measuring Tuesdays and accidentally predicted correctly (unlikely but would be hilarious)

My assessment: 95% certain this was random noise, 5% wondering if I should email Dima.

I will not email Dima. This is how conspiracy theories start.

17:00 - Tuesday Summary

Accomplished today:

  • ✓ Changed password (took 47 minutes)
  • ✓ Calculated password entropy (fascinating despite frustration)
  • ✓ Conducted impromptu typing speed experiment (nobody asked for this)
  • ✓ Completed Tuesday frequency measurement (fake prediction: incorrect)
  • ✗ Remembered new password (failed after 3 hours)
  • ✗ Convinced that special characters improve actual security (still skeptical)

Current status:

  • Password written in notebook in drawer
  • Tuesday measurement complete (no anomaly beyond normal variation)
  • Slightly frustrated with security requirements
  • Mathematically fascinated by entropy calculations
  • 47€ frequency counter still questionably reliable
  • Dima’s prediction: wrong (but coincidentally close enough to be unsettling)

Probability I will forget new password by tomorrow: 85%

Probability I will need to reset password next time: 90%

Probability ProtonMail will require another change in 6 months: 100%

Probability I will write blog post complaining about it again: 95%

Note to Dima: Your prediction was incorrect. Elevation was 0.02 Hz, not 0.4-0.6 Hz. This is 33 times too small. But it WAS elevated during exact window you specified. Explain this. (Do not actually explain this. It was coincidence. Probably.)

Note to ProtonMail: Your password requirements optimize for appearance over entropy. My 18-character password had more entropy than your 12-character requirement. I understand why you do this (users are terrible at passwords). Still annoying.

Note to self: Remember password is in calibration notebook. Or reset it. Again.

Security status: Theoretically improved, practically questionable

Tuesday status: Measured, documented, no significant anomaly detected (unless 0.02 Hz elevation counts, which it doesn’t)