cómo autenticar al usuario en la implementación cliente-servidor

Pasando el hash Si hash la contraseña en el cliente, corres el riesgo de introducir una falla de pasar el hash (PTH). Este es un fenómeno real y sorprendentemente común que afecta significativamente la seguridad de su aplicación. Ha sido un problema de seguridad clave en Windows durante años: enlace

(EDIT: el ejemplo de Windows anterior habla sobre las debilidades en el protocolo de desafío-respuesta NTLM. Un protocolo de desafío-respuesta bien diseñado no debería ser vulnerable a la PTH, aunque estos protocolos han sido ampliamente reemplazados por la seguridad de la capa de transporte. Vea más abajo .)

Esencialmente, si primero hash la contraseña, el valor que estás utilizando para autenticarte en el servidor es en realidad un hash de esa contraseña, y no la contraseña en sí. Por lo tanto, un atacante técnicamente solo necesita conocer el hash, y no la contraseña en sí. Como resultado, si la base de datos estaba comprometida, ahora está bloqueado, porque el atacante tiene todas las credenciales que necesita.

Solución Usted podría solucionar este problema mediante el hash en el cliente y el hash nuevamente en el servidor. Esto significa que la base de datos contendría una lista de hashes que aún deben ser crackeados antes de que sean útiles.

Sin embargo, esto no ayuda especialmente a su dilema de seguridad en el transporte. Cualquiera que sea el valor que envíe al servidor durante la autenticación (la contraseña o simplemente un hash) es el valor que un atacante puede usar para autenticarse con el servidor. Por lo tanto, un hash del lado del cliente siempre tiene el mismo perfil de riesgo que la propia contraseña. No estás más seguro transfiriéndolo como un hash.

TLS Como resultado, es mejor que centre su atención en una buena configuración de TLS. Asegúrese de que el cliente nunca enviará información confidencial a través de un protocolo de texto simple y que solo acepta certificados de servidor válidos. Considere la posibilidad de fijar el certificado si está disponible. Configure el soporte solo para los protocolos y conjuntos de cifrado más seguros tanto en el servidor como en el cliente.

Métodos de autenticación alternativos (todos los cuales tienen el potencial de ser invulnerables para pasar el hash si se implementan correctamente):

• Autentificación de clave pública con certificados de cliente (TLS)
• Kerberos / SPNEGO
• Protocolos de desafío-respuesta como Compendio de HTTP ( no recomendado ). Estos incluyen el hashing y el salado y, por lo tanto, son más similares al hashing del lado del cliente que se está discutiendo. Cuando se implementan correctamente, no deben ser vulnerables a los ataques de estilo PTH.
• Contraseña remota segura (SRP)

Tales protocolos son en gran medida innecesarios en las aplicaciones modernas debido a la mayor disponibilidad e interoperabilidad de TLS.

Cuando ya está utilizando SSL, no hay razón para no usar también SSL para obtener la contraseña del usuario. Por supuesto, esto requerirá que usted tenga un certificado de una autoridad de certificados confiable o que el cliente confíe en su certificado. Cuando se habla de un ejecutable independiente que instalan sus usuarios, puede incluir el certificado de su servidor en él.