Las contraseñas se envían en texto sin cifrar debido a un error de los usuarios al escribirlas en el campo de nombre de usuario

Una idea es no permitir el envío de formularios si no hay un valor en el cuadro de contraseña. Generalmente, si ingresaron accidentalmente la contraseña en el nombre de usuario, es probable que no haya nada en el diálogo de contraseña.

Vale la pena señalar que esto no tiene que hacerse simplemente del lado del cliente, sino que también se puede hacer en un servidor siempre que el transporte utilizado sea seguro y la entrada no se registre hasta después de pasar una verificación sobre el campo de contraseña no estar vacío.

Suponiendo que su aplicación de fondo y SIEM necesitan ver los intentos de inicio de sesión fallidos de varias aplicaciones (y, por lo tanto, mostrar el mensaje de error "El usuario P @ $$ w0rd no es válido"), entonces no será trivial detenerlo.

Sin embargo, asegurarse de que todas las aplicaciones que envían datos confidenciales, incluidos los nombres de usuario y las contraseñas implementan HTTPS (HTTP cifrado mediante SSL) es una buena manera de garantizar que los dispositivos de red y cualquier persona en la red no puedan obtener la contraseña que se ingresó por error en el cuadro de nombre de usuario!

¿Entonces el problema es que no desea que los analistas vean las contraseñas en los archivos de registro confidenciales?

Precaución: Incluso si tuviera que usar Javascript, no se ocupará de los datos de contraseña almacenados en su disco como texto sin formato.

  

Una mejor solución es preprocesar los registros antes de que los analistas los vean y redactar la información en los registros.

Puede hacer este filtrado línea por línea si agrega una lista blanca o una lista negra a otras líneas. Por ejemplo:

Puede incluir nombres de usuario en la lista blanca cuando aparezcan en un archivo de registro que

• Tiene un patrón ([az] + número) o ([az] + período + [az])
• incluya un nombre de dominio seguido de una barra diagonal "\" para entornos AD
• aparece varias veces
• Se puede lavar contra un directorio LDAP de nombres de usuario conocidos antes de que los analistas lo vean

También identifica y enumera las contraseñas de la lista negra mediante:

• La política de contraseña a menudo sigue un patrón (un símbolo, superior / inferior, x caracteres ...)

Puede utilizar este conocimiento para crear un limpiador de datos de registro personalizado para proteger la información que no desea que vean los analistas.

¿Qué aspecto tiene una línea filtrada?

Usted puede simplemente redactar nombres de usuario cuestionables mediante el hash, asignándoles una identificación humana y almacenándolos en una ubicación segura:

 eb574b236133e60c989c6f472f07827b   Redact1
 7e67b89a695bfbffc05b7ed2c38f927f   Redact2
 ..etc

Los analistas pueden ver si una entrada en particular está ocurriendo una y otra vez si el hash se repite en la frecuencia.

El método de hashing exacto (o el método de cifrado) que elija está sujeto a riesgos ya que esta "base de datos de hash" contendrá información de alto valor. Y la siembra (por su naturaleza) evitará el análisis de frecuencia que puede o no ser de valor para usted.

Solo puedo identificar tres problemas con lo que estás discutiendo.

1. Los usuarios no ingresan información correctamente.
2. Los analistas pueden distinguir las contraseñas de los registros.
3. Las contraseñas se envían en texto sin cifrar y son susceptibles a las escuchas ilegales de man-in-the-middle .

En mi opinión, esto es bastante simple de solucionar.

1. Aceptar error de usuario, a regañadientes .
2. No registre nombres de usuario no válidos, en su lugar registre los intentos fallidos y la IP.
3. No envíe los nombres de usuario en texto sin cifrar. Use tecnología como HTTPS o use javascript para codificar el texto plano (por ejemplo, ROT13).

Ejemplo de registro de un inicio de sesión fallido y luego un reintento exitoso.

[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100

Leyendo otras respuestas, me gustaría incluir esto.

• Valide todos los campos antes de enviarlos.
• Considere la posibilidad de dividir el formulario entre varias páginas, como lo mencionó Eric G.

Una solución que he visto que algunos bancos implementan, al menos en aplicaciones web, es tener un inicio de sesión de dos páginas.

1. En la primera página, acepta solo el nombre de usuario
2. En la siguiente página en el proceso, solicite la contraseña y solo haga eco del nombre de usuario para que no sea un campo editable.

Por lo tanto, la única entrada en la segunda página debe ser la contraseña. Como el usuario sabe que debe borrar la primera página con un nombre de usuario, sabe que debe borrar esa puerta, entonces la única opción en la segunda página es la contraseña.

Si puede implementar este flujo de trabajo, ayudará a concentrar a los usuarios en lo que están escribiendo y cuándo.

También, considerando su registro: ¿Quizás pueda cambiar su registro para no incluir las credenciales reales?

Por ejemplo, en un inicio de sesión exitoso, use la identificación de la clave principal en lugar de devolver la entrada: "El usuario con la identificación: '2342342' ha intentado iniciar sesión" luego "El usuario con la identificación '2342342' ha proporcionado una contraseña con éxito ".

Si realiza una búsqueda y el nombre de usuario no está allí, entonces algo como "Usuario de la dirección IP '192.168.0.10' intentó iniciar sesión con una identificación de usuario no válida".

Estos serían tus registros de nivel de aplicación. Los registros del servidor web pueden incluir parámetros de consulta, por lo que puede ser un poco más difícil de tratar o quizás pueda colocar algún tipo de filtro proxy entre la acción y cuando se escribe el registro para redactar el contenido del registro según ciertas reglas. Esto sería específico de la plataforma, pero parece que puede ser posible en Apache .

Como control secundario, limite el acceso de lectura a los diversos archivos de registro que está procesando.

En términos generales, todos los códigos de clientes son lo suficientemente inteligentes como para manejar errores básicos

1. ID de usuario y / o falta de contraseña
2. La contraseña no coincide con las directrices

Por lo tanto, en cualquier caso cuando aún vea estas entradas en el Registro,

User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]

Ninguna validación del cliente funcionó y el sistema terminó enviando la contraseña sin cifrar a través de la red. Entonces, ¿qué había en el campo de contraseña? Definitivamente no está en blanco ya que la validación del cliente fallaría. Me debe algo diferente de la contraseña

Por lo tanto, conviértalo en una autenticación de dos pasos

1. First Pass, envíe todos los detalles cifrados, incluida la contraseña, al servidor. Verifique si el campo Contraseña está vacío.
2. Primer paso, verifique si la contraseña coincide con las Pautas en caso de error.
3. Primer paso, luego verifique si la contraseña está presente en su base de datos. Si no es Error Out.
4. Envíe una respuesta RPC al cliente y deje que envíe la ID de usuario y la contraseña ahora.
5. Ahora realice el proceso de autenticación

Toda la esencia de este proceso es

1. Minimiza el riesgo. Tenga en cuenta que no puede eliminar el riesgo de cero
2. No confía en el cliente.

Y finalmente, haga que un UX Expert revise su interfaz. Puede ser que su interfaz tenga algún defecto que haga que los Usuarios ingresen la Contraseña en el campo de ID.

Por lo que describe de su arquitectura, esto no es factible, pero en mi opinión, la solución correcta es: no envíe el nombre de usuario de forma clara y no registre los nombres de usuario de los intentos fallidos de inicio de sesión. El lugar solo donde debe ir el nombre de usuario y la contraseña es al subsistema que verifica la contraseña; hasta que esto ocurra, el nombre de usuario es datos no autenticados, datos arbitrarios , cualquiera que tenga acceso al formulario de inicio de sesión, que en una aplicación web es todo Internet, puede escribir lo que quiera sin importar la frecuencia que lo desee, y por lo tanto te dice muy poco de interes (A menos que su formulario de inicio de sesión no esté expuesto a Internet).

  

esto probablemente eliminaría gran parte del análisis de registro por no poder decir quién hizo qué ...?

Dado un nombre de usuario sin la contraseña correcta, no sabe que la solicitud es realmente de ese usuario , por lo que aún no sabe quién inició la sesión intento.

El problema general es la autenticación basada en contraseña. Cada tienda familiar insiste en tener autenticación propia con contraseñas. Esto es estúpido.

Deje que otro proveedor de identidad haga el trabajo duro de mantener las credenciales seguras. Haga lo mismo que StackOverflow: permitir la autenticación con OpenID, Gmail, etc.

Sus usuarios se lo agradecerán por no necesitar otra contraseña en alguna parte.

El lado del cliente con javascript parece razonable.

El campo de verificación de contraseña no está vacío, antes del envío. Compruebe que el nombre de usuario está en una forma válida. Especialmente elegante es algo donde se requiere que el nombre de usuario sea una dirección de correo electrónico. Además, podría prohibir que la contraseña en su mecanismo de configuración / cambio de contraseña tenga forma de dirección de correo electrónico. Luego, simplemente verifique que el nombre de usuario tenga la forma de una dirección de correo electrónico válida antes de enviar el formulario. Esto podría hacerse de manera similar con, por ejemplo, caracteres especiales o números. (Por ejemplo, se requieren números / caracteres especiales en las contraseñas, pero están prohibidos para los nombres de usuario).

Además, use una biblioteca SSL actualizada para todos los envíos de formularios (esto se debe hacer para evitar que los oyentes de la red escuchen). Requiere permisos elevados para leer estos registros (por ejemplo, la cuenta del servidor web puede escribir en estos registros, pero solo la raíz puede leerlos). Tan pronto como la contraseña falla el paso de autenticación, no propague el nombre de usuario a otros sistemas. (También use SSL entre distintos sistemas internos para evitar los escuchas ilegales de la red).

Me gusta el enfoque que mi empresa actual toma para este problema: si escribe su contraseña en el cuadro incorrecto, un sistema automatizado hace que su contraseña caduque de inmediato. Por lo tanto, el usuario tiene que cambiar su contraseña, y la contraseña que está en el registro ahora ya no es vulnerable.

Por supuesto, esto todavía no es ideal si el usuario sigue usando esa contraseña para otro sistema, pero es probable que el hecho de ser forzado a cambiar su contraseña haga que un usuario esté más al tanto de los posibles riesgos de seguridad.

En su mayoría, la respuesta MÁS FÁCIL es la correcta. Ahora notamos que cada dirección de correo electrónico tiene un signo "@" justo antes del nombre de dominio. Hacer que "@" sea una clave NO ACEPTABLE en la contraseña hace que la solución sea bastante obvia. Si el nombre de usuario NO tiene @ y TODOS LOS NOMBRES DE USUARIO son direcciones de correo electrónico, entonces registre solo aquellos que tengan al menos @ @.

Ahora, si el nombre de usuario NO tiene "@", es probable que enoje a algunos usuarios, pero esta es una solución ingeniosa. Eso es tener UN SOLO carácter especial que viene ANTES de una contraseña. Al igual que TODOS los USUARIOS que son cuentas de correo electrónico tienen un formato. Todas las respuestas tienen un carácter especial al principio o al final, lo que sea. Entonces, cuando el usuario ingresa una contraseña, le comunicas que debe escribirla.

La tercera solución es que CODIFICACIÓN A COLOR. Nombre de usuario Campo Amarillo y Contraseña Campo ROJO. El rojo normalmente llama su atención porque se usa para cosas sensibles. Entonces, incluso si están mirando el teclado, APRENDERÁN MUY RÁPIDAMENTE que las contraseñas son rojas. Básicamente, el campo de texto Y LA etiqueta de la contraseña están en rojo, preferiblemente en una casilla separada, y la etiqueta del nombre de usuario y el campo de texto TODOS AMARILLOS.

¿Por qué no responder simplemente con esto?

That username does not exist

¿Cuánto control tiene sobre el manejo del servidor receptor de esto? Parece que la solución que un usuario propuso anteriormente, para cambiar el nombre de usuario y la contraseña, podría funcionar de varias maneras:

Método 1 (que requiere JavaScript): hash tanto el nombre de usuario como la contraseña. En su base de datos, almacene nombres de usuario con hash, y luego haga su búsqueda de autenticación usando ese campo. Esto sería ideal si tiene algún control sobre la forma en que se tratan los datos en su servidor, pero no controla su capacidad de registro.

Método 2 (no requiere JavaScript): reciba el nombre de usuario en texto plano como de costumbre, pero conviértalo en un hash como en el método 1 una vez que lo reciba en el servidor. Cuando el intento falla, registre el hash, no el nombre de usuario. Los registros seguirán siendo útiles (un poco menos útiles cuando se inspeccionan con cursor), ya que cada hash seguirá identificando de forma única a un usuario. Ninguno de estos es tan elegante como la mejor respuesta aquí (y sugeriría usar eso también), pero son más completos.

Una solución simple, pero molesta, podría ser tener un diseño de teclado en pantalla con botones html, donde los usuarios solo pueden escribir su nombre de usuario con estos botones, esto evitará que se cometa el error, me doy cuenta de lo molesto que esto puede cambiar. Ya sea, pero después del primer inicio de sesión, puede usar una cookie para recordar el nombre de usuario y no volver a solicitarlo. Se requerirá Javascript por supuesto. Ahora es imposible enviar la contraseña en texto sin formato por accidente. Espero que ayude.

Tengo una opinión diferente ... ¿Qué problema intentas resolver realmente?

1. ¿Contraseñas incorrectas? Es decir. cuando ve que una persona usa "contraseña" (o una variante), desea poder rastrear al usuario y corregirla?

2. ¿Se están enviando las contraseñas de forma clara?

3. ¿O el problema con los idiotas que no pueden escribir o leer formularios (o tal vez una IU mal diseñada)?

Recuerde siempre que cada vez que "agregue" al sistema potencialmente agregue complejidad y definitivamente agregue código, lo que aumenta la posibilidad de que abra "agujeros" de seguridad en su arquitectura general en algún lugar (podría estar en la pila, podría ser a través de la web, podría ser a través de la red ...). Entonces, al resolver cualquiera de los 3, debe medir si el valor de resolverlos vale el riesgo de abrir un agujero que no conoce: el diablo que conoce siempre es mejor que el diablo que no conoce.

Ahora a cada uno.

La resolución de las contraseñas incorrectas se debe realizar durante la configuración y el cambio de la contraseña a través de las reglas de validación. Y sólo allí. Para agregar otro lugar para hacerlo, solo significa que corre el riesgo de que las reglas de validación se confundan o no estén sincronizadas.

Las contraseñas se envían en claro. ¿A quien le importa? Concedido podría "sentirse" inseguro, pero recuerde que esto es una autenticación de parte y si solo tiene 1 parte, no es diferente a tener una palabra en un diccionario. Tal vez, solo si tienes un rastreador activo puede darles algunas pistas, pero entonces la intrusión ya está en tu lugar, es tu problema real, no un poco de aleatorización ocasional de contraseñas en el campo del nombre de usuario. Ahora, si tiene todas las partes enviadas en claro, gran problema.

Problema de idiotas o mal diseño de la interfaz de usuario. Re-mediatar a los usuarios o la interfaz de usuario. Sencillo. Proporcione ayuda activa en la interfaz de usuario, haga que los departamentos realicen alguna capacitación o algo. Solución fácil que requiere cambios de codificación limitados y de bajo riesgo (o debería, tenga cuidado con el aspecto de la interfaz de usuario).

Aunque admiro muchas de las sugerencias aquí, y muchas de ellas tienen ideas maravillosas en su núcleo. Recomiendo un enfoque KISS, no BS, siempre recordando que si agrega a sus sistemas se arriesga a aumentar su inseguridad.

Sólo mis 2 centavos.

• solo permite transmitir hash md5 de nombres de usuario Y contraseñas (o hash similar), de modo que todo lo que se registre en los archivos de registro siempre se verá como una longitud fija de caracteres aleatorios, lo que no hará que nadie pueda adivinar rápidamente es un md5 de una contraseña o un nombre de usuario.

Con: Para comparar con los nombres de usuario en su base de datos, tiene que almacenar dos columnas, por ejemplo. 'nombre de usuario' y 'md5 (nombre de usuario)' O TIENE que hacer hash dinámicamente cada vez que solicite un nombre de usuario para iniciar sesión.

• cree una entrada de registro solo si el nombre de usuario existe en la base de datos; de lo contrario, solo log ip.

• solo permita que el usuario haga clic en ingresar con el mouse, no en el teclado, o solo permita el teclado después de 5 segundos del último carácter ingresado en cualquiera de los campos, lo que le dará tiempo al usuario para mirar la pantalla y ver su error.

• haga alguna restricción a los nombres de usuario y contraseñas permitidos:

  1. las contraseñas deben contener un carácter especial como! @ # $% ^ & * ()
  2. los nombres de usuario NO deben contener ningún carácter especial

De esta manera, puede hacer javascript para identificar rápidamente si el nombre de usuario o la contraseña ingresados.

La biometría es bastante barata ahora y funciona al menos el 80% del tiempo. Me parece genial en Tablet PC y he querido implementar teclados biométricos porque es más rápido (al menos en ese 80% del tiempo).

Apuesto a que esto no fue tan problemático con Win2000, WinXP, Win2003 y WinVista porque, de forma predeterminada, el campo de nombre de usuario ya estaba lleno con el último nombre de usuario exitoso. No estoy exactamente seguro de qué versión de ActiveDirectory o estación de trabajo cambió, pero ahora la predeterminada es que el campo de nombre de usuario esté en blanco, lo que hace que este problema sea más frecuente.