¿Este esquema de autenticación será seguro y protegerá las contraseñas / hashes del usuario?

Guía de autenticación

OWASP tiene una Hoja de referencia para el almacenamiento de contraseñas con una excelente guía sobre esquemas de hashing y la teoría de fondo de cómo Mantienen las contraseñas seguras. También hay una sección que cubre la pieza que parece más preocupada: proteger la cuenta de un usuario en el caso de un posible compromiso.

Para leer más, Troy Hunt tiene un artículo - Passwords Evolved: Autenticación Guía para la era moderna : resume la actualización reciente de las publicaciones gubernamentales sobre el tema, incluyendo Publicación especial NIST 800-63 - Pautas de identidad digital .

No reinventes la rueda

Parece que estás intentando inventar algo completamente nuevo. Recomendaría apegarse a las cosas que están probadas. Los recursos anteriores deberían ayudar con eso.

No es que vea algo inherentemente incorrecto con tu sugerencia. Yo tampoco soy matemático o criptógrafo, por lo que no pretendo tener la experiencia para certificar que su esquema es seguro. Parece que estás haciendo un montón de trabajo adicional para encontrar e implementar una solución no estándar, lo que en realidad podría hacerla más vulnerable al final.

Los esquemas no estándar también tienen la desventaja de ser más difíciles de mantener a medida que se incorporan personas que no están conscientes de los detalles de cómo se construyó su esquema, qué factores lo hacen seguro y pueden hacer cambios que hagan agujeros en su seguridad. modelo.

Por último, como desarrolladores de software, generalmente no se nos paga para hacer investigación de seguridad e inventar nuevos esquemas de encriptación o autenticación. Nuestros clientes o empleadores nos pagan para realizar mejoras medibles en el estado de la técnica para su dominio específico. Esto es solo mi opinión, pero cuando se trata de implementar la autenticación, sería casi negligente no seguir la guía proporcionada por las organizaciones como NIST, OWASP y los equipos de seguridad de los proveedores que producen el software y las bibliotecas que utilizamos (Microsoft , IBM, Oracle, etc).

Para que esto funcione, el servidor debe almacenar la clave pública generada a partir de la contraseña (es decir, "PK.public"). Sin embargo, no hay forma de que el servidor verifique la firma.

Así que ahora, en lugar de una tabla llena de hashes, tiene una tabla llena de claves públicas derivadas de contraseñas. Un atacante que tenga sus manos en esa mesa podría simplemente atacarlo con fuerza bruta, repitiendo los pasos 2 y 3 para varias contraseñas hasta que encuentre una coincidencia. En lugar de almacenar un hash, está almacenando algo derivado de un hash. En el mejor de los casos, eso es equivalente a simplemente almacenar el hash.

Entonces, todo lo que has hecho aquí es agregar mucha complejidad al agregar algunos criptogramas asimétricos de fantasía, sin obtener ninguna mejora de seguridad. Dado que la complejidad es tu enemigo, esta es una pérdida neta.