¿Debo registrar que un usuario cambió su contraseña?

Para, responda su pregunta, Sí, puede y DEBERÍA registrar cambios de contraseña, y no hay nada fundamentalmente incorrecto en hacerlo, siempre y cuando no lo haga, por ejemplo. registra la contraseña en sí "

¿Qué debo registrar?

Al diseñar el registro con fines de seguridad, desea responder a estas preguntas:

¿Cuándo ocurrió el evento?

• La fecha y la hora en que ocurrió el evento (use el formato de registro común)

¿Cuál fue el evento?

• Una breve descripción del evento (por ejemplo, cambio de contraseña)

¿Quién desencadenó el evento?

• El ID de usuario, nombre, correo electrónico o algún identificador único

¿Por qué se desencadenó el evento?

• Esto no es lo mismo que el "Qué" aunque muchas personas lo usan de esa manera. Esta es la razón por la que se ejecutó el evento. (por ejemplo, la contraseña se modificó debido a la política, la contraseña modificada manualmente por el usuario, etc.). Esto puede ser realmente bueno para eliminar el ruido.

Escenarios

Uno de los mejores métodos para discutir qué ver a través de escenarios y preguntar al equipo:

• ¿Qué información proporciona el evento?
• ¿Se requiere el evento para el cumplimiento / legal?
• ¿Estamos iniciando sesión por motivos de detección? (por ejemplo, ¿Activar un SIEM) o para corregir? (por ejemplo, forense después del hecho)
• ¿Quién mirará los registros?
• ¿Cómo protegeremos los registros?

Example:

James es parte del equipo de IR, que es responsable de la aplicación crítica "No-Existencia" de Made-Up Company. James desea poder ver todos los cambios de contraseña para detectar cambios que ocurren fuera del proceso normal de la política. Estos eventos se activarán e investigarán si se produce un cambio de contraseña sin un incidente registrado por el equipo de soporte. Los registros se enviarán al dispositivo IR SIEM, que utilizará un conjunto de reglas para desencadenar advertencias al equipo de IR cuando no se pueda correlacionar un incidente con un cambio de contraseña fuera de un cambio de política requerido.

(Precaución obligatoria para usar esto en un lugar de trabajo. Acabo de mencionar este ejemplo.)

[editar] - Actualizada la respuesta inicial para que sea más clara. Gracias a @SeldomNeedy por la sugerencia.

No puedo darte una razón para no registrar algo; Tienes que darme una razón por la que necesitas registrarte.

Teóricamente, puede registrar todo lo que hacen los usuarios (hasta el movimiento del puntero del mouse, los clics y cuando una ventana está en primer plano o no).

Pero, ¿ NECESITA para registrar todo? ¿Puede registrar todo sin sacrificar el rendimiento? ¿Puede almacenar los registros durante un período de tiempo útil?

No hay razón para no iniciar sesión cuando el usuario cambia su contraseña. Puede evitar que los usuarios cambien su contraseña con demasiada frecuencia. O cualquier característica que pueda construir en el historial, los hábitos y los patrones de cambio de contraseña.

Incluso puede correlacionar el cambio de contraseña con las principales violaciones de seguridad para determinar qué tan "técnico" es el usuario.

Puede registrar algún mensaje para indicar que el usuario ha cambiado la contraseña junto con cierta información como ipaddress (para rastrear si alguien cambió su contraseña de manera inadvertida) desde donde cambió la contraseña.

Evite registrar la información de PII que llevará a un usuario específico si se filtra el archivo de registro.

No registrarlos es más un riesgo de seguridad que registrarlos, pero (como todos los demás han dicho), tenga cuidado de cómo y cómo registra la información.

Otras respuestas señalan que los registros permitirán a los administradores detectar el comportamiento de las infracciones, y el envío de notificaciones a los usuarios les permitirá detectar las infracciones de forma individual.

Creo que todos asumimos que estás almacenando tus contraseñas como hashes con sales aleatorias. Solo un recordatorio de que el uso de sales aleatorias ralentizará significativamente la capacidad de un atacante para descifrar las contraseñas de hash, ya que tienen que hacer el proceso completo de craqueo para cada sal única (que se espera que sea única para cada contraseña en el sistema, y cada vez que estén cambiado).

Si quisiera implementar algunas nuevas políticas de contraseña, podría:

• mantener registros (tal vez no "registros") de cuándo se cambiaron las contraseñas
• mantenga una versión con hash de la contraseña, con su sal aleatoria

Esto le permite implementar políticas para:

• caducidad, usando solo la parte de marca de tiempo
• historial de contraseñas, mediante la combinación de la nueva contraseña con cada una de las sales históricas y comparando con los hashes históricos, para garantizar que el usuario no esté reutilizando contraseñas antiguas

Una de las respuestas anteriores menciona esto de pasada y enfatizaré las dos cosas clave que debe tener en cuenta:

1. Mantenga la lista de hash para asegurarse de que el usuario no esté reutilizando las palabras antiguas.
2. No almacenar cuando, por lo que los hackers no pueden trabajar con la información de longevidad de pword. P.ej. UserX restablece el fin de pword de cada mes.