¿Qué tan malo es usar la fecha para generar una contraseña "aleatoria"?

Supongamos que sé el día o la semana en que creó su contraseña, pero no la hora exacta. Este supuesto parece razonable:

• Muchos servicios en línea muestran las fechas de creación de la cuenta
• Muchos servicios en línea recomiendan públicamente cambiar las contraseñas debido a violaciones (puedo suponer que cambió su contraseña dentro de una semana después de la última violación divulgada públicamente del servicio)
• Mucha gente cambia las contraseñas "solo para estar seguro" si ocurre algo sospechoso, envía un correo electrónico falso a la víctima y hay una buena posibilidad de que tengas suerte.
• En el caso de una pérdida en la base de datos, muchos servicios almacenan la fecha del último cambio de contraseña (por ejemplo, para exigir el tipo de requisito de cambio de contraseña de 3 meses (ahora obsoleto))

Su contraseña de urandom tiene log ₂ (64 ³² ) = 192 bits de entropía. Como las contraseñas van, esto es excelente.

Si asumimos que el día que generó su contraseña date | md5 , tiene log ₂ (60 * 60 * 24) ≈ 16.4 bits de entropía (86.400 contraseñas posibles); esto es muy malo. Incluso con parámetros de Argon2 inusualmente fuertes que requieren 1 segundo por intento, solo tardaría 1 día (a lo sumo) en romperse, y un hash MD5 podría romperse casi al instante. En el caso de que una tasa de ataque en línea, puede ayudar, pero ciertamente no confiaría en ella (el atacante podría usar muchas direcciones IP y repartir conjeturas durante varias semanas).

Si solo sé en qué semana generó la contraseña, solo es 7 veces mejor, lo cual es casi instantáneo cuando se rompe un hash MD5.

Si un adversario conoce el valor de la fecha (o está cerca de él) cuando creó su contraseña, entonces puede reproducirla de manera trivial. Parece malo.