Web y HTTP inseguro: uso de RSA para cifrar contraseñas en el lado del cliente

En primer lugar, asumo que estás haciendo esto para debilitar a los ataques del hombre en el medio (que realmente son el único problema cuando se trata de contraseñas de texto simple sobre HTTP inseguro)

El hashing del lado del cliente tiene poco o ningún beneficio. Un atacante, al recoger el hash no necesitará fuerza bruta del hash. Todo lo que necesita su servidor es el hash, por lo que el atacante puede crear una solicitud POST con el hash y enviarla. Uno no necesita el texto simple para ingresar al sistema.

Con respecto a su solución:

Si está utilizando la misma clave pública para todos los clientes, entonces la situación es la misma. Como atacante, todo lo que necesito para rastrear es el texto cifrado que envías, y puedo personificarte enviando el mismo texto cifrado.

¿Qué sucede si le da diferente claves públicas a cada cliente en cada inicio de sesión? Entonces podría lanzar un hombre en el ataque central donde intercambié la clave pública del servidor con la mía propia, descifrar el texto cifrado que envías (para obtener tu texto plano, incluso mejor) y cifrarlo con la clave pública del servidor.

Tiene got para que el cliente sepa qué clave pública es correcta. Para eso necesitarías algún tipo de sistema de confianza. Donde los clientes saben qué claves públicas corresponden a qué servidor. Pero eso conducirá a que millones de claves públicas se almacenen en los navegadores. Así que necesitarías algún tipo de sistema de encadenamiento de certificados. Y creo que te das cuenta de a dónde voy con esto ;-)

TL; DR: utilice HTTPS, el cifrado del lado del cliente sin un sistema de confianza no es más seguro que ningún cifrado.

Si le preocupa que las contraseñas compartidas en otros sitios se detecten después de romper el hash, entonces el hash y el cifrado de clave pública están bien (el cifrado de clave pública es mejor debido a las tablas de arco iris). Tenga en cuenta que estos solo frustrarán los planes de un atacante pasivo. Si el atacante monta un ataque MITM activo, puede cambiar el código JS que envía y eliminar los bits de cifrado por completo.

Esto es lo que entiendo de tu pregunta.

• Aceptas una contraseña en el lado del cliente
• Usted rellena la contraseña al azar.
• hash la contraseña en el cliente.
• Cifras el hash usando la clave pública del servidor
• Envía el hash cifrado al servidor
• El servidor descifra el hash usando su clave privada & lo compara con el hash almacenado para verificar la validez.

El problema aquí es un ataque de repetición. Cualquier persona que escuche a escondidas el hash cifrado puede reutilizarlo.

La solución a esto puede ser

1. Agregue la hora actual a la contraseña en el lado del cliente. Entonces hash. Cuando el servidor descifra lo que obtiene, primero divide el paquete en la contraseña hash & hora. Solo si la hora está dentro de + - delta de la hora actual, comprueba la contraseña. Esto no permitirá reutilizar el hash encriptado a escondidas a menos que se use muy rápidamente.
2. Tome el esquema anterior y también agregue un número de ID a la cadena de contraseña + tiempo. Y luego hash, etc. La responsabilidad del servidor es asegurarse de que un número de ID en particular no se reutilice para un cliente en particular el mismo día. La responsabilidad del cliente es asegurarse de que no reutilice el mismo número de ID el mismo día. Esto evitará un ataque de repetición incluso si se realiza muy poco después del evento.

Un componente muy importante aquí es que el certificado del servidor (clave pública) debe estar preinstalado en el cliente, no debe ser que el cliente obtenga el certificado solicitándolo al servidor.