Usar solo la contraseña para autenticar al usuario (sin el campo "nombre de usuario")

El principal problema al usar solo la contraseña es que no puede aplicar sales .

En un servidor normal y robusto que autentica a los usuarios con una contraseña, las contraseñas en sí mismas no se almacenan "como están", sino que hash . El proceso de hashing de contraseña requiere algo de cuidado, ya que un atacante que obtiene una copia de ese archivo lleno de contraseñas hash (por ejemplo, a través de un ataque de inyección SQL) puede ejecutar un ataque del diccionario : esto es" intentar "contraseñas potenciales. Los usuarios humanos tienden a elegir contraseñas que son "palabras" en algún idioma, o derivadas simples de eso (por ejemplo, agregando un dígito), de ahí el término "diccionario".

Para hacer la tarea más difícil para el atacante, el proceso de hashing de contraseña debe:

1. ser inherentemente lento al ordenar, por ejemplo, un millón de invocaciones de funciones hash anidadas;
2. be salted : la sal es un parámetro que altera la forma en que funciona el hash, y cada contraseña de hash tiene su propio valor de sal. De esta manera, cuando el atacante intenta una contraseña potencial, primero debe elegir la contraseña con hash a la que se dirigirá.

El nombre de usuario es el selector para el salt: cuando el servidor recibe el nombre de usuario, lo busca en su base de datos, obteniendo la contraseña con hash y el valor de sal que se utilizó para calcular ese hash ( ambos se almacenan juntos). Esto le permite al servidor volver a calcular el hash, comenzando con el valor de sal que y la contraseña que proporcionó el usuario. Si el servidor obtiene el mismo valor de hash que el que se almacenó, el usuario se autentica; De lo contrario, el usuario es rechazado. "Buenos algoritmos para eso son bcrypt y PBKDF2 . Prefiero bcrypt ( pero PBKDF2 no es malo).

Sin nombre de usuario, sin sal. El servidor no puede saber qué valor de sal usar para la contraseña específica, por lo tanto, debe usar la misma sal (es decir, sin sal) para todas las contraseñas almacenadas. Esto permite a los atacantes atacar todas las contraseñas a la vez, lo que es mucho más eficiente.

Es más simple de ver si piensa en un ataque de diccionario en línea , donde el atacante intenta posibles contraseñas en su servidor. Con un nombre de usuario + contraseña, el atacante debe enviar un nombre de usuario y una contraseña, y tiene éxito si el usuario con ese nombre realmente tiene esa contraseña . Sin el nombre de usuario, el atacante simplemente envía una contraseña potencial y tiene éxito si cualquier usuario en el sistema tiene esa contraseña. Si tienes 1000 usuarios, simplificaste el ataque 1000 veces.

Además, cuando un nuevo usuario se registra, elige su contraseña. Si esa contraseña choca con la de otro usuario, no tiene más remedio que rechazar el registro. En ese momento, el nuevo usuario acaba de enterarse de que la contraseña que quería usar es ya una contraseña válida para otro usuario: acaba de convertir al nuevo usuario en un atacante exitoso, y él lo sabe ... .

De acuerdo, debo recordar que no debe responder la pregunta después de comer, pero antes del café. Acabo de darme cuenta de que sus "contraseñas" son en realidad UUID con 122 bits de entropía generada aleatoriamente. En ese caso, las cosas serán mejores. No llamaríamos a estas UUID "contraseñas", ya que no son "palabras" y tampoco son elegidas por un humano, ni siquiera recordadas por un humano. Estos son tokens de autenticación .

Aún querrá hacer sus transacciones sobre SSL. Además, dado que los clientes no los recordarán , los escribirán, en archivos o en papel (más probablemente los archivos, para que puedan cortarlos y pegarlos, nadie quiere escribir el UUID completo en una base regular). Esto hace que el secreto de estos UUID sea más difícil de mantener. Sus clientes deberán asumir la responsabilidad de mantener estos valores en secreto; esto podría ser demasiado pedirle a un cliente típico.

Le sugeriría que mantuviera un par de cadenas, usuario / contraseña, público / privado, como sea que lo llamemos.

Si bien prácticamente no hay posibilidad de colisión, no veo ninguna razón por la que una autenticación de solo contraseña sea mejor. Por otro lado, con un par de claves, la pública podría ser una ID fija del usuario, que permite muchas cosas, como el registro, no importa cuántas veces se cambie la contraseña.

No mencionaste esto explícitamente, pero tengo la impresión de que guardas las credenciales (ya que "no está pensado para ser recordado", al igual que las claves API), por lo que realmente no importa para el Usuario que método utilizas.

Debería tener un ID de usuario & contraseña para que pueda cambiarla si es necesario o desea sin cambiar el ID de usuario. Asumiría que, para los requisitos de auditoría, deberá realizar un seguimiento del usuario en particular que realiza ciertas actividades, lo que significa que el usuario tendrá que autenticarse (proporcionar su propia contraseña), por lo que un UUID oculto específico para PC será insuficiente.

Mi respuesta en una pregunta relacionada también se aplica aquí:

El concepto simple y básico que falta:

  

La identificación y la autenticación no son lo mismo.

En pocas palabras, estos son dos requisitos separados, y no deben confundirse.
Un nombre de usuario proporciona identificación y una contraseña le permite verificar la identidad reclamada (es decir, la autenticación).

Ahora, en su esquema propuesto, la situación es ligeramente diferente, ya que espera que la "contraseña" no se pueda recordar, en realidad está tratando de implementar lo que algunos han llamado un débil "algo que tiene "- ya que esta URL está destinada a ser recuperada una vez, y (supongo) guardada como favorito / favorito, el acceso al escritorio del usuario supuestamente controla el acceso a la cuenta del usuario.

Sin embargo, todavía hay algunos problemas con esto:

• La "contraseña" no se puede cambiar fácilmente (como se ha mencionado);
• La "contraseña" no se puede eliminar fácilmente, debido al problema de recuperación mencionado por @Thomas;
• es un factor débil , dependiendo del sistema en el que no quiera confiar en la seguridad de la máquina del usuario;
• algunos navegadores actuales sincronizan la configuración del navegador, incluidos los favoritos, en todos los dispositivos. De hecho, esto permitiría el acceso a cualquiera de los dispositivos sincronizados;
• Dado que la "contraseña" está en la URL, esto podría estar expuesto a través del historial o caché del navegador (existen ataques que permiten el acceso a esta incluso sin acceso físico a la máquina del usuario);
• Muchas configuraciones hacen que la URL se registre, como los registros del servidor web, los servidores proxy inversos, etc.
• Acceso HTTP accidental (en lugar de HTTPS, incluso si redirecciona, el usuario seguirá haciendo clic en ese marcador, ya que de todas formas llega al sitio ...).

Podría continuar, encontrando escenarios adicionales donde sería posible exponer dicha "contraseña". Si desea evitar cualquier autenticación basada en contraseña, sería mejor que emita certificados del lado del cliente y haga que el usuario los almacene. El soporte del navegador para aquellos es suficientemente maduro (si no es transparente o trivial), y los protocolos ya están implementados para admitir esto de forma segura.