Iniciar sesión en un sitio web. Podemos usar RSA para enviar la contraseña del cliente al servidor, pero ¿qué ocurre al revés?

1) Lo que usted describe se conoce como un ataque de repetición. Si acabara de cifrar un mensaje con RSA de libro de texto (sin un relleno aleatorio o un nonce incorporado en el mensaje), esto sería posible. Sin embargo, cuando las personas usan RSA para enviar datos, generalmente se refieren a SSL / TLS, donde RSA es el método utilizado para intercambiar una clave simétrica que luego se utiliza para el resto de la comunicación. Si está usando Chrome y va a seguridad en una página usando https, puede ver un mensaje como

La conexión a este sitio se encripta y autentica mediante un protocolo fuerte (TLS 1.2), un intercambio de clave fuerte (ECDHE_ECDSA con X25519) y un cifrado fuerte (AES_128_GCM).

que muestra que se usó ECDHE (curva elíptica diffe-hellman) en lugar de RSA como cifrado de clave pública y que la clave simétrica era AES-128. En este protocolo se incluyen medidas para prevenir ataques de repetición. Si no está usando SSL y solo quiere usar RSA, tendría que agregar un nonce o un relleno

2 y 3) como se mencionó anteriormente, no debería tener que poner una clave privada en su aplicación. Puede utilizar la clave pública del servidor para comunicarse y establecer una clave simétrica. Cifrar mensajes completos con RSA se considera lento y realmente debería usar una biblioteca existente para hacer SSL / TLS o algo así. Y evita rodar tu propia criptografía. Si RSA es seguro es otra pregunta. Ciertamente, es con tamaños de clave suficientemente altos (2048), pero otros métodos de intercambio de claves tienen otras ventajas (como diffe-hellman, que oculta la clave a un observador externo, incluso si se hace en texto plano)

  

¿Hay un método mejor?

Sí. Utilice TLS .

El cifrado por sí solo nunca hará que quieras lo que quieres. Incluso si aborda los problemas de intercepción y reproducción de alguna manera, aún se encuentra en una posición en la que la aplicación no puede estar segura de que está hablando con el servidor legítimo. Toda la privacidad en el mundo no importa si sus comunicaciones privadas van a una parte desconocida. Este problema se conoce como "confianza".

TLS le dará la posibilidad de autenticar el servidor (es decir, asegurarse de que no está hablando con un pirata informático que se ha hecho pasar por el servidor). TLS aprovecha una PKI que le permite autenticar la cadena de autoridad y garantizar que el receptor de sus mensajes sea una entidad confiable.

Ahora, podría intentar hacer crecer su propia PKI, pero el hecho es que probablemente no tenga su propia autoridad de certificación o un medio para distribuir sus certificados en su aplicación de manera segura. Solo las PKI y las CA públicas tienen esta capacidad, por lo que verdaderamente TLS es su única opción viable.

Primero, de acuerdo con John Wu. Usa TLS primero.
Luego, asegure TLS con el certificado del cliente, almacenado en el paquete de aplicaciones móviles.
Tercero: sugiero no confiar en la contraseña del lado del cliente. Por lo tanto, puede generar una contraseña en el lado del servidor, tomar un hash y luego enviar este hash que será cifrado por la contraseña del cliente con un cifrado sólido. Por lo tanto, el resultado almacenado en el lado del cliente no puede convertirse en un hash sin la contraseña del cliente. Será descifrado localmente para obtener el hash. Si agrega algo de entropía y cambia la firma de datos basada en la sesión, puede garantizar que los datos transmitidos estén protegidos de forma segura. Pero si desea estar seguro de la protección de datos, use diferentes redes para transferir partes de las claves de sesión. Por ejemplo, sms o el código de devolución de llamada de audio junto con la transmisión ip.