¿Es la autenticación de contraseña peor que la mensajería firmada si se realiza sobre SSL?

2

Deja que haya una API pública:

  • basado en HTTP
  • a través de SSL
  • no hay navegadores, solo conexiones entre programas escritos personalizados

El primer esquema de autenticación que se me ocurrió fue ... el cliente firma sus mensajes con la clave privada, el servidor confirma los mensajes a través de la clave pública. Se ve bien.

Pero, ¿por qué no usar simplemente la autenticación de inicio de sesión / contraseña en ese caso? Sé que no es una idea brillante enviar información secreta a través de cables, pero ¿es realmente malo si todo se hace a través de HTTPS seguro de todos modos? ¿Cuáles son las desventajas de ese método?

    
pregunta Pavel Vlasov 20.02.2013 - 23:49
fuente

3 respuestas

4

Básicamente esto no es realmente malo, ya que la comunicación está encriptada. No hay más posibilidades de que la contraseña sea robada que la clave privada.

Sin embargo, las contraseñas débiles se pueden adivinar "fácilmente" con métodos como la fuerza bruta.

Por lo tanto, la seguridad de su sistema dependerá de cómo sus usuarios conozcan la fortaleza de la contraseña.

    
respondido por el Antoine Pinsard 21.02.2013 - 01:05
fuente
5

La autenticación basada en claves asimétricas ya es compatible con SSL con el nombre "certificado de cliente". De hecho, una firma está involucrada. Si desea utilizar una clave asimétrica del cliente, se recomienda utilizar esta función SSL que ya está implementada por las bibliotecas SSL.

Usar una clave asimétrica para la autenticación es útil cuando la identidad del cliente es confirmada por un tercero: una entidad, distinta del servidor , realiza la identificación inicial (también conocida como "certificación" con certificados ), y el servidor se basa en esta identificación. Esta es una separación de roles que puede o no ser útil en su contexto. Otra forma de verlo es la siguiente: cuando el cliente se conecta al servidor, en un escenario de inicio de sesión + contraseña, el cliente envía su contraseña al servidor. Por lo tanto, el servidor aprende la contraseña. Una consecuencia es que el cliente no debe usar la misma contraseña si se está conectando a varios servidores que no confían entre sí. Con un certificado de cliente, el cliente puede usar el mismo certificado con cada servidor.

Si no necesita las funcionalidades adicionales de los certificados, entonces una contraseña de inicio de sesión está bien. En realidad, si el cliente trabaja de forma automática sin una entrada de usuario, entonces la "contraseña" se almacena en algún lugar del cliente, no escrita por un humano. Por lo tanto, esa contraseña puede ser un conjunto de bytes aleatorios, que serán mucho más robustos contra una búsqueda exhaustiva que una contraseña recordada por el hombre. En estas condiciones, es posible que desee utilizar SSL / TLS-PSK que se basará en esta "clave precompartida" y evitar la necesidad de cualquier certificado, ni cliente ni servidor.

De forma similar, si la contraseña la escribe un humano o la recuerda, considere TLS-SRP que tampoco necesita ningún cliente o certificado de servidor y, además, tolera contraseñas de entropía limitada.

    
respondido por el Thomas Pornin 21.02.2013 - 12:43
fuente
1

Si estoy interpretando tu pregunta correctamente, lo que estás preguntando se reduce esencialmente a "¿Por qué no solo usar contraseñas en lugar de claves para SSH".

Lo único que suele ser inseguro acerca de las contraseñas son sus usuarios humanos estúpidos. Por lo general, la seguridad de la contraseña será mucho menor (mucho MUCHO) que cualquier sistema basado en claves. Esto lo abre a más vectores de ataque, como la fuerza bruta, que, por supuesto, se pueden gestionar mediante políticas de contraseña correctas, etc.

Versión corta: nada está mal, es menos seguro y usted debe decidir si es aceptable para usted o no.

    
respondido por el Peleus 21.02.2013 - 01:01
fuente

Lea otras preguntas en las etiquetas