Autenticar el hash en salado sin nombre de usuario

Eso es realmente una idea muy mala . Considere a dos personas usando una contraseña similar donde las dos letras coinciden. ¿Cómo podrás distinguir entre los dos? No.

Usamos el nombre de usuario y la contraseña para identificar a alguien. Si solo necesita proteger la aplicación, también podría compartir una contraseña, ya que parece que no le importa la responsabilidad.

No, esto no es posible.

• Una sal lo protege de las colisiones en la contraseña con hash, no de las colisiones en la contraseña de texto sin formato. Si dos usuarios tienen la misma contraseña, tendrá dos combinaciones de contraseña / sal / hash que pasan su validación y no podrá distinguir entre los usuarios.

• Los problemas que tiene con la forma de buscar a los usuarios se deben a que no tiene una clave principal. No puede usar una contraseña como clave principal a menos que rechace activamente contraseñas duplicadas (y en cuyo caso acaba de decirle la contraseña de alguien al atacante).

• Un nombre de usuario puede ser una fuente de entropía. Es más probable que "Buscar cualquier usuario con una contraseña de prueba" devuelva un resultado que "Encontrarme usuario abc con prueba de contraseña". Un atacante oportunista probablemente podría encontrar una cuenta al intentar contraseñas comunes.

Utilice una cookie de inicio de sesión persistente para lograr su objetivo.

La forma tradicional de evitar que el usuario tenga que escribir un nombre de usuario es incluir la funcionalidad "recordarme" donde el nombre de usuario se mantiene de una manera que está asociada con el navegador, por ejemplo. una cookie cifrada o una cookie que contiene un token duradero (por ejemplo, 30 días) que el servidor puede usar para inferir el nombre de usuario.

Algunas de las respuestas aquí sostendrán que el nombre de usuario proporciona entropía adicional. Puede tratar esta objeción solicitando una contraseña que sea el doble de larga. Por supuesto, este tipo de cancela el beneficio de la escritura reducida, ya que ahora el usuario tiene que escribir tantas cosas, con la dificultad añadida de la entrada enmascarada.

Si insiste en utilizar un diseño sin nombre de usuario, hay una serie de características comunes que dependen del nombre de usuario con las que tendrá que averiguar cómo lidiar de otra manera:

1. Bloqueo de autenticación. Si el usuario no ha proporcionado un nombre de usuario o una contraseña correcta, ¿dónde guarda el contador de bloqueo?

2. Recuperación de contraseña. ¿Qué escribe el usuario en el flujo de trabajo de "Contraseña olvidada" que le permite identificarse? (Supongo que este problema no es más difícil de resolver que la función "olvidé el nombre de usuario").

3. Detección de colisión de ID de usuario. ¿Qué mensaje mostraría en lugar de "Ese nombre de usuario ya está en uso por otro usuario"? Estoy pensando en un mensaje como "felicidades, ¡acabas de adivinar la contraseña de otra persona!" no aprobaría la revisión de seguridad.

4. Auditabilidad y atención al cliente. ¿Qué cadena emite su aplicación en los registros de auditoría, los registros de depuración u otras tablas o archivos, que un desarrollador o técnico de soporte puede reconocer en el soporte técnico del cliente? Seguramente no la contraseña. Además, ¿qué ofrece el cliente por teléfono cuando solicita asistencia, si no es el nombre de usuario?

También tendrá problemas si intenta alcanzar el cumplimiento con PCI-DSS (por ejemplo, si necesita aceptar tarjetas de crédito), el cumplimiento con la FDIC (si trabaja con bancos) o el cumplimiento con la norma ISO (si trabaja con agencias gubernamentales) .