Comunicación segura
El protocolo de comunicación debe ser seguro. Si el canal de comunicación es inseguro, la autenticación es insegura. TLS / SSL es una forma de proteger el protocolo de comunicación. Si no utiliza TLS / SSL, deberá crear un marco para crear un protocolo de comunicación seguro a través de un enlace inseguro. Si se realiza correctamente (autenticación del servidor, autenticación del cliente, intercambio seguro de claves, cifrado, autenticación de mensajes, manejo robusto de las calificaciones bajas, etc.) el protocolo sería complejo. Para todos los propósitos prácticos, acabarías reinventando TLS / SSL.
Por lo tanto, lo escrito solo # 4 y # 5 son seguros y para la mayoría de las aplicaciones # 4 debería ser la opción principal. Esto no quiere decir que siempre debe usar el número 4, pero debe poder expresar claramente por qué en este escenario el número 4 es inferior a una alternativa.
Conocimiento cero (negabilidad)
Una variante de # 5 puede ser útil en aplicaciones de nicho donde el conocimiento cero o la negabilidad es un requisito de diseño central. Comprenda que esto agrega complejidad adicional, por lo que si no necesita negación, está construyendo un sistema más complejo sin mejorar la seguridad. Mayor complejidad significa mayor costo y mayor posibilidad de introducir debilidades que pueden ser explotadas.
Un ejemplo de dónde sería útil la autenticación de conocimiento cero sería un servicio de respaldo en línea. Si el servidor tiene las claves de cifrado, el servicio puede verse obligado a revelarlas (potencialmente de forma encubierta y sin el debido proceso). Si el servidor nunca tiene las claves de cifrado, no se les puede obligar a revelar lo que no saben.
El cifrado de archivos sin procesar es bastante sencillo. La clave de cifrado se genera a partir de la contraseña del usuario utilizando un KDF. Los archivos están cifrados en el lado del cliente y se transmiten al servidor. El servidor nunca tiene la contraseña del usuario o la clave de cifrado. El desafío es cómo autenticar al usuario (para verificar el estado de la cuenta, la facturación, permitir las cargas, etc.). El proceso predeterminado del usuario que envía la contraseña (# 4) anula el cifrado de datos del lado del cliente. Por lo tanto, el sitio podría hacer que el usuario tome la contraseña hash it del lado del cliente y la suministre al servidor. El hash debe producirse de manera diferente a la clave de cifrado (la misma kdf pero diferente número de rondas o la misma contraseña pero un prefijo estático). Una mejora con respecto a lo que usted presentó es que el servidor no tiene que almacenar el hash de autenticación del usuario directamente. El servidor puede almacenar un hash del hash que evitaría la autenticación falsa incluso si la lista de contraseñas está comprometida.
Criptografía asimétrica para autenticación
Una opción no listada sería utilizar un certificado del lado del cliente para autenticar al cliente. La creación de certificados, la gestión y el almacenamiento / respaldo seguro deben realizarse completamente del lado del cliente o no tiene sentido. La clave privada se puede cifrar con la contraseña del lado del cliente para mayor seguridad. TLS / SSL es compatible con los certificados del lado del cliente, por lo que si este es un requisito de diseño, empezaría allí en lugar de reinventar la rueda. Una de las ventajas de ECC sobre RSA es que es más amigable para dispositivos de baja potencia y con limitaciones de memoria como las tarjetas inteligentes, por lo que esta se está convirtiendo en una solución más realista, aunque la educación del usuario sigue siendo un desafío.