Uso del nombre de usuario / contraseña para generar una clave 'pública' para el cifrado

Utilizar una clave pública es siempre una opción. La criptografía de clave pública fue diseñada para hacer exactamente lo que usted está tratando de hacer; intercambie información confidencial a través de una red no confiable (Internet) sin que los observadores ocasionales puedan olfatearla.

Obtenga su servidor firmado con un certificado. Si no necesita confianza global (por ejemplo, si puede "introducir" manualmente cada cliente al servidor dentro de una red de confianza la primera vez, antes de intentar conectarse a través de la que no es de confianza), puede generar un "autofirmado" "certificado de forma gratuita, pero si desea una verificación independiente de que usted es quien dice ser, pase por una CA global que firmará su certificado, proporcionando una confirmación verificable de la identidad de su servidor por un tercero (por un precio, por supuesto, generalmente muy razonable).

Una vez que tenga este certificado, simplemente obligue a que todo el tráfico que se conecta a su servidor lo haga a través de HTTPS. El cliente solicitará el certificado (cualquiera puede; es información pública), verificará que el certificado coincida con el que esperan de usted (o que la cadena de confianza sea válida hasta una "raíz confiable") y luego use el clave pública en el certificado para cifrar un mensaje que contiene información sobre el algoritmo simétrico que desean usar. Si acepta, inicializa el esquema de encriptación y envía el acuse de recibo encriptado con su clave; Si no, envía un rechazo de texto simple e intentan nuevamente.

Este es el "protocolo de enlace SSL", y se ha usado durante mucho tiempo con muy pocos ataques exitosos contra él (usualmente aprovechando una vulnerabilidad en el algoritmo de hash para generar certificados falsos para sitios de phishing; simplemente use un SHA) 2 algoritmos y estarás bien). Una vez que se haya establecido el canal de cifrado simétrico, no importa qué tan salvaje es la red, los datos enviados entre el cliente y el servidor se cifrarán para que nadie más pueda leerlos. Luego, pueden enviarle las credenciales del usuario para iniciar sesión y establecer la "sesión de aplicación" a través de la sesión de red segura.

No recomendaría tu esquema. Parece ineficiente (tener que crear claves de cada combinación de nombre de usuario y contraseña, solo para encontrar el origen), y no es seguro, ya que el servidor genera claves privadas que se envían a los clientes. También es vulnerable a los ataques de repetición, ya que no estás protegiendo el canal subyacente, aunque sin ver el resto de los detalles, no está claro de qué se trata un atacante.

¿Por qué no solo usar SSL ? Está diseñado para proteger información confidencial a través de redes inseguras, es universalmente compatible y es probable que sea más seguro que cualquier cosa que implementes.

Si necesita almacenar estos datos encriptados después de la transferencia, el uso de un esquema de clave pública tradicional es ciertamente una opción. No hay riesgo de que alguien espíe una clave pública, ya que están destinados a ser públicos. Mientras la clave pública de cada una de las partes esté firmada, o bien entre sí , o por algún tercero de confianza mutua , entonces no hay riesgo de un ataque de hombre en el medio.

tldr: Use SSL. Si necesita almacenar datos después de la transferencia, use PGP.

¿Por qué no estás usando SSL? No, en serio.

Genere un certificado autofirmado que mantenga privado. Luego, use ese certificado para su servidor o (mejor aún) utilícelo para firmar un certificado específico del servidor. Envíe el certificado autofirmado (pero no la clave privada, obviamente) con cualquier software que vaya a utilizar.

Luego, cuando inicie su conexión SSL con el servidor, use el certificado enviado como su única CA de confianza, es decir, no acepte conexiones firmadas por cualquier otra CA .

En este punto, se garantiza que se comunicará directamente con su servidor de confianza a través de un canal seguro. No es posible ningún administrador intermedio porque solo confía en las conexiones protegidas con la clave del servidor.

Ahora, autentique al cliente utilizando el mecanismo que desee. Ya que está seguro de que la interceptación, la manipulación o la reproducción no es posible a través de la conexión segura, realmente no tiene que hacer nada especial.