Al principio, me gustaría dejar claro que esto es para los propietarios pobres de sitios que no pueden pagar la opción SSL pero requieren inicios de sesión en su sitio, potencialmente desde un quiosco público, y necesitan un método seguro para permitirlo. Todo lo que estoy buscando es una revisión pública del proceso que he elaborado, si hay algún ataque que pueda haber pasado por alto y que este proceso lo permita, y cualquier posible golpe de carretera que pueda introducir.
El proceso para registrarse es así:
- El usuario llega a la página y el formulario de inicio de sesión se rellena con la clave pública del servidor y una única.
- El usuario ingresa la contraseña en el formulario (y otros detalles de identificación). La contraseña y el nonce se combinan y se insertan a través de una función de derivación de claves
- Utilizando una clave pública derivada y una clave pública del servidor, cifre la contraseña y envíe de vuelta la clave pública del cliente ad-hoc y la contraseña cifrada (y los detalles de identificación del requisito).
- Usando la clave pública del cliente y la clave privada del servidor, descifre la contraseña, genere sal, empiece con hash lento y almacene el resultado.
El proceso para iniciar sesión sería:
- el usuario llega y recibe la clave pública del servidor y el servidor.
- el usuario ingresa el combo de nombre de usuario / contraseña. Como antes, nonce y password generan un par de claves
- cifre la contraseña con la clave pública del servidor y la clave privada generada, elimine la privada, luego envíela a través del cliente, la contraseña cifrada y el nombre de usuario
- lado del servidor, descifre con el servidor privado y público del cliente, tome el salt que corresponda al nombre de usuario, la contraseña lenta con hash, verifique en la base de datos y continúe iniciando sesión si todo está bien.
Mi principal preocupación es que el uso de la contraseña para generar el par de claves introduce una vulnerabilidad en el sentido de que si la clave pública ad-hoc enviada a través del cable se puede usar para aplicar ingeniería inversa a la combinación nonce / password que generó la clave par, o peor aún, usarlo para crear de alguna manera la clave privada para descifrar la contraseña si la función de derivación no es lo suficientemente fuerte. ¿Son estas preocupaciones legítimas, y esta opción debería estar en la mesa?