¿Se debe registrar un nombre de usuario no válido?

Debe registrar nombres de usuario no válidos.

Considere el escenario en el que un atacante realiza un ataque de fuerza bruta en línea contra su servicio utilizando un diccionario de nombre de usuario y contraseñas. El atacante no está realizando un ataque dirigido contra ninguna cuenta en particular en su sistema, en vez de eso, está probando nombres de usuario aleatorios.

Si no registra nombres de usuario no válidos, existe la posibilidad de que un ataque de fuerza bruta pase desapercibido. Si registra nombres de usuario no válidos, así como información como direcciones IP, existe una mayor posibilidad de que sea capaz de reconocer un ataque de fuerza bruta contra su sistema, lo que le permite tomar las medidas adecuadas para detener el ataque.

Sí. Pero, por otro lado, no desea que el archivo de registro contenga las contraseñas, lo que ocurriría si alguien fallara el inicio de sesión y enviara la contraseña en lugar del nombre de usuario.

Lo que creo que podría ser un compromiso viable podría ser el registro:

• intenta con nombres de usuario válidos y contraseñas no válidas, registrando el nombre de usuario pero no la contraseña.
• intentos con nombres de usuario no válidos (que pueden ser contraseñas o lo que sea), registrando el nombre de usuario como "NO VÁLIDO".

El fundamento es que varios intentos con un solo nombre de usuario válido le informarán sobre un posible ataque de fuerza bruta en contra de ese nombre de usuario; un enjambre de intentos contra el nombre de usuario INVÁLIDO advertirá de un ataque a gran escala de "nombre de usuario con contraseña obvia", que, si tiene una política de contraseña adecuada, es irritante pero inofensivo. Más aún, los intentos contra usuarios conocidos.

Es concebible que alguien esté tratando de imponer una fuerza bruta contra un solo nombre de usuario no válido; Si eso es un problema, puede registrar nombres de usuario no válidos como hashes (parciales y / o con sal). El valor de esta información de texto claro, incluso si es capturado por partes hostiles, sería esencialmente nulo.

Un número muy pequeño de intentos en el nombre de usuario INVÁLIDO puede deberse a que los usuarios escriben mal sus nombres o ingresen la contraseña en lugar del nombre; o paranoicos que intencionalmente arruinan su primer inicio de sesión creyendo que esto protege contra la captura de credenciales.

Especialmente si es seguido rápidamente por un inicio de sesión válido desde la misma dirección (a menos que sea un sistema enmascarado en una red grande ...), un error de autenticación ocasional de este tipo podría considerarse ruido e ignorarse.

(Es posible que distinga un pequeño conjunto de "nombres no válidos válidos" como info , admin *, Administrator , guest , si Usted quería, pero eso es probablemente una exageración).

También, para los verdaderamente paranoicos, podría rellenar todos los nombres de usuario válidos y la cadena "INVALID" para que sea la misma, longitud fija (digamos ... ¿20 caracteres?). Si, por casualidad, un atacante pudiera observar de forma remota el crecimiento del archivo de registro, no podría decir si un nombre de usuario existía o no en el sistema.

Sigue el enlace del fabricante de cosas7 como comentario, ya que tenía muchos detalles sobre cómo detenerlo en primer lugar, pero aún así debes registrar todos los intentos.

  

¿Por qué no sería suficiente que un sistema de autenticación se registre?   ¿Sólo intentos de autenticación no válidos para nombres de usuario válidos?

Un intento de inicio de sesión no válido podría indicar un posible ataque. Si solo registra aquellos con nombres de usuario válidos, no verá todos los ataques, lo que puede ayudarlo a contrarrestar mejor el intento si se distribuye o puede proporcionarle otra información útil.

En un caso raro, si el registro está expuesto / accesible, el atacante podría usarlo para enumerar nombres de usuario válidos / no válidos (prueba A / B en cada inicio de sesión; aunque si sus registros están expuestos públicamente ...).

El problema de raíz es que la contraseña podría estar registrada. Esto también podría ocurrir con una probabilidad baja si el usuario escribió la contraseña en el campo de nombre de usuario, pero aún así coloca algo de contenido en el campo de contraseña.

Puede ser mejor cifrar todo el registro o al menos la parte del nombre de usuario (o cualquier otra PII que se incluya) cuando se almacena. Cualquier SIEM, etc. aún puede correlacionarse si el cifrado es siempre el mismo para un valor dado. Dado que es una buena idea almacenar todos los intentos no válidos, el cifrado le permite mantener todo eso como un límite de exposición de contraseñas.

Puede registrar el valor cifrado de los nombres de usuario no válidos.

Si alguien está realizando un ataque de fuerza bruta desde varias direcciones IP, puede / tener que identificarlo analizando el tráfico en su servidor web, no mirando los nombres de usuario registrados. Esto se puede hacer en la capa de aplicación. Si recibe un número inusual de solicitudes de inicio de sesión de una dirección IP, simplemente puede bloquear esa dirección IP (por un período que considere adecuado). De lo contrario, es posible que su servidor web se vea comprometido mucho antes de poder ver los nombres de usuario / contraseñas registrados.

Pero ahora suponga que un usuario legítimo ingresa accidentalmente su contraseña en el cuadro de nombre de usuario. Si almacena el texto sin procesar, un intruso puede leer el nombre de usuario (contraseña) registrado (suponga que un intruso ha obtenido acceso a sus archivos de datos). Su objetivo es hacer que el intruso no pueda leer los datos en esta situación. Esto es cuando el cifrado es útil.

Si está utilizando un DBMS, el sistema de base de datos puede realizar el cifrado. Por ejemplo, puede cifrar las tablas / columnas que almacenan los nombres de usuario y hash las contraseñas.

Si está almacenando esta información, digamos un archivo CSV, este cifrado se puede hacer en la capa de la aplicación. Si puede utilizar la criptografía de clave pública, entonces su vida será fácil. La aplicación puede simplemente cifrar los valores ingresados usando la clave pública y usted (o quien sabe la clave privada) puede descifrarlos con la clave privada; debería ser bastante fácil mantener la clave privada segura. Si tiene que usar criptografía de clave simétrica, hay varias maneras de almacenar la clave secreta de forma segura (hacer una búsqueda en línea). Puede que no sea tan seguro y tan fácil como usar el cifrado de clave pública, pero es mucho mejor que mantener el texto sin formato, ¿no?

Tenga en cuenta que el objetivo es hacer que la intrusión sea costosa, no hacer que su sistema sea 100% inmune ... porque eso simplemente no es práctico.

Creo que esta pregunta está dirigida por la definición de caso y varía según los requisitos para el análisis. Considera esto,

  

Un atacante que usa el diccionario ataque de fuerza bruta; puede bloquear usuarios legítimos (considerando) que mantiene un diccionario que está bien diseñado para su entorno de ataque. En este atacante está abusando de la política de bloqueo de cuenta.

Ahora, en el escenario anterior era un sistema honeypot (ejecutando un servicio de telnet vulnerable), puede aprender mucho sobre la forma en que el atacante usa el diccionario. Si los usuarios en el diccionario coinciden con las listas de la organización, probablemente pueda alertar  administradores del sistema para cambiar los nombres de usuario.

al igual que algunas matemáticas y las estadísticas pueden ayudar a analizar tendencias, por ejemplo, los datos dicen que el atacante está golpeando el nombre de usuario correcto después de 80% de intentos fallidos cada cinco minutos. Este número le proporciona el período de seguridad o de gracia para la acción.