¿Qué tan seguro es este enfoque de autenticación en comparación con el hash?

  

¿Hay algún inconveniente con este enfoque en comparación con el uso habitual de la contraseña y el hash?

Por lo general, no hay razón para inventar su propio método de hashing de contraseñas, siempre y cuando los existentes se ajusten a su propósito. Es difícil hacerlo mejor en comparación con elegir un método fuerte y establecido conocido. Pero es fácil hacerlo mal.

La fortaleza de los actuales métodos de hashing de contraseñas proviene de múltiples aspectos:

• la función irreversible para hacer que la entrada informática de la salida sea imposible
  Esto se hace mediante el uso de funciones criptográficas de hash fuertes.
• la validación lenta de una contraseña única ralentiza los ataques de fuerza bruta
  Esto se realiza mediante la creación de funciones hash lentas e incluso mantiene la lentitud de estas funciones hash, incluso si el atacante ha creado hardware específicamente para solucionar el problema de la velocidad.
• múltiples salidas (almacenamiento) para la misma entrada (contraseña) para que no sea factible el cálculo previo. Esto se hace utilizando un salt aleatorio para cada hashing. Las sales se extraen al azar de conjuntos lo suficientemente grandes como para que el cálculo previo y el almacenamiento de los resultados de todas las entradas posibles se vuelvan inviables en el tiempo y la memoria.

Veamos cómo se compara tu idea con este enfoque establecido:

• irreversibilidad
  Esto probablemente se otorga siempre que la función de derivación de la clave (para obtener la clave de cifrado de la contraseña) proporcione esta propiedad. Solo que no se sabe nada acerca de esta función, por lo que asumo que no consideraste que esta función deba tener propiedades especiales.
• validación lenta para disminuir la fuerza bruta
  Ningún aspecto de su algoritmo se preocupa por reducir la fuerza bruta y ningún aspecto es intrínsecamente lento. Esto puede hacerse nuevamente dentro de la función de derivación de claves, pero de nuevo no requiere una función específicamente construida para esto.
• múltiples salidas (almacenamiento) para la misma entrada (contraseña)
  Esto probablemente se garantiza al tener un IV aleatorio para cada cifrado.

En resumen, diría que la seguridad de su enfoque depende de la elección de la función de derivación de claves, es decir, que el KDF es un hash lento y unidireccional. Como no requería que su KDF se comportara de esa manera, consideraría su idea como una mala idea. Incluso si requiere que el KDF sea fuerte y lo suficientemente lento, podría haber otros problemas de su algoritmo que no reconocí en el corto tiempo.

Nuevamente, no inventes el tuyo si existe un método de trabajo que resuelva tu problema. Normalmente solo empeora, no mejora.

Sí, hay un inconveniente, incluso si es „solo“ uno práctico (aunque percibo que la tasa de colisión (la contraseña incorrecta deriva de una clave que se desencripta a algo que sigue la sintaxis que espera) es mayor en su esquema, pero No fui a las matemáticas, porque el otro inconveniente es frecuente).

Hay más partes móviles en tu esquema que en el hash de contraseña habitual. Esto significa que más cosas pueden salir mal, especialmente si lo implementas tú mismo. El uso de una función hash es fácil en comparación con el uso de un cifrado de bloque.

Las implementaciones y los ejemplos sobre hash seguro para contraseñas están fácilmente disponibles, mientras que una implementación de su esquema sería algo especial, ofreciendo muchas más dificultades en la implementación.

Además, esto permitiría a los atacantes que tienen la base de datos descifrar las contraseñas de los usuarios, lo más fácil. Dependiendo de la función de hash y la sal que utilice, AES, que se implementa principalmente en hardware, es rápido en comparación, y solo un bloque sería un buen indicador del descifrado correcto.