Hay siguientes problemas con este enfoque:
-
Las contraseñas con fórmulas parecen estar almacenadas en texto plano. Así que esto sería mejor si se divide en dos partes: la primera parte es conocida y la segunda parte es la fórmula. De esta manera, la primera parte se puede almacenar como hash.
-
Los tokens criptográficos utilizan un mecanismo similar, donde ingresas la contraseña seguida del número del token criptográfico (como "password" + "123456" que es "password123456"). El token criptográfico es un dispositivo de hardware pequeño que muestra el número después de presionar el botón. Cada hardware de token criptográfico tiene una clave diferente, por lo que todos necesitan usar su propio token. Ahora, el problema es que la fórmula es muy fácil de revertir si es muy simple. De hecho, debería ser algún tipo de cifrado fuerte que la persona no pueda realizar en la memoria.
De todos modos, parece que vas por buen camino y lo que intentas hacer se puede lograr de la siguiente manera, por ejemplo:
-
Cree una aplicación de token criptográfico de software, por lo que esta aplicación simplemente acordará la clave secreta con su servidor durante la instalación y podrá generar tokens criptográficos en modo sin conexión (o incluso en línea).
-
Su sitio web puede leer la contraseña y eliminar los últimos 6 números, luego verifique la contraseña con el hash almacenado. (Los 6 números cambian muy 10 segundos o más o menos, por lo que la sincronización de tiempo es importante, pero si no es ninguno, es posible sincronizar al verificar los tokens pasados / futuros y hacer los ajustes).
-
Luego, su sitio web puede ponerse en contacto con la API y verificar si el token criptográfico para el nombre de usuario coincide.
Ahora lo que hay que saber es que los tokens criptográficos funcionan a tiempo y con una clave secreta. Entonces, el token generado en un minuto no es válido en un tiempo diferente.
Sin embargo, el principal desafío sería proteger la seguridad de sus tokens criptográficos. Podría proporcionar un servidor en la nube dedicado para cada cliente que lo use, por ejemplo, permitiendo el acceso solo desde sus servidores y manteniendo un programa de actualización extremo para parches de seguridad, defensa de múltiples capas y una buena arquitectura de software donde todas las bibliotecas se mantienen activamente y se audita el código fuente.
Dicha solución sería eventualmente buena no solo para los sitios web, sino también para cualquier sistema corporativo, incluido Active Directory. Sin embargo, para vendérselo a los clientes, deberá cumplir con las políticas de seguridad oficiales una vez y, en segundo lugar, hacer que las instituciones educativas / gubernamentales lo revisen, lo que estoy seguro será útil.
El escenario general propuesto es bueno porque, por su parte, no corre mucho riesgo: si se roban los tokens criptográficos, las contraseñas no se conocen de todos modos y puede actualizar el token criptográfico suave o forzar la reactivación de estos.
El inconveniente es que requiere token criptográfico suave dedicado para acceder a un servicio único que lo estaría usando. Por lo tanto, el token criptográfico de hardware es mucho más práctico, pero el software suave sigue siendo bueno para la demostración y el desarrollo.
Respecto a "ingrese las letras 1, 3 y 5 de su segunda contraseña" es algo más débil pero mucho más barato en comparación con los tokens. Sin embargo, producir token no es difícil hoy en día, dado que es una larga vida y una seguridad mucho más sólida.
El modelo comercial de este se basa en mantener un método de comunicación seguro y un almacenamiento seguro adecuado de tokens criptográficos, por lo que todo el negocio de su lado debe centrarse adecuadamente en él, por lo que es un trabajo para empresas de terceros y no para los bancos. . De esta manera, la superficie de ataque se reduce a la forma en que los tokens son almacenados y verificados por una empresa de terceros.