Asegurar el formulario de inicio de sesión en una aplicación de escritorio

Question

Asegurar el formulario de inicio de sesión en una aplicación de escritorio

#1 de atk (1 votos)

1

Actualmente tengo una aplicación de escritorio que requiere que el usuario tenga un nombre de usuario y una contraseña. Estas credenciales se almacenan en un servidor web (myserver.com), de modo que cuando escribe el nombre de usuario y la contraseña y hace clic en el botón Iniciar sesión, se envían al servidor web. Si las credenciales son correctas, el servidor devolverá "ok", se mostrará información del usuario y se mostrará el formulario principal. Si no, el servidor devolverá "incorrecto" y se mostrará una alerta. Sin embargo, esto es muy inseguro, porque un usuario puede simplemente editar el archivo de hosts, redirigir myserver.com a su localhost, que siempre devuelve "ok", y omitir la pantalla de inicio de sesión. Me dijeron que generara un par de claves RSA y luego cifrara un "nonce" (un número aleatorio) en la aplicación de escritorio y lo enviara junto con las credenciales. Si el servidor pudiera devolver el número descifrado, eso significaría que en realidad es mi servidor. Tengo que decir que el servidor web está alojado en Heroku, por lo que HTTPS está habilitado de forma predeterminada, pero no tengo ningún certificado SSL. Esto parece ser bastante bueno, pero ¿es esto propenso a un ataque de hombre en el medio? Un atacante podría simplemente redirigir myserver.com a su host local, enviar la solicitud de localhost, recibir el número descifrado, cambiar "incorrecto" a "ok" (o cambiar alguna información del usuario) y enviarlo nuevamente a la aplicación.

¿Cómo puedo crear un formulario de inicio de sesión más seguro para una aplicación de escritorio?

authentication rsa desktop

pregunta Ivan 19.08.2014 - 11:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication rsa desktop

Los hackers atacan contra wp-config.php ¿Impedir que alguien use su sitio para phishing?

score 1 · Accepted Answer

La aspersión de polvo de hadas criptográfico no evitará que el atacante que controla al cliente haga que el cliente haga lo que quiera con él. Todavía puede redirigirlo a localhost, pero ahora necesita reemplazar la clave pública que integró con la aplicación con su propia clave pública. O adjunte un depurador y desactive el uso de crypto por completo. O descompilar, eliminar el uso de criptografía y recompilar. No puedes controlar esto, porque todo se ejecuta en la computadora cliente sobre la que tu atacante tiene control total y tú no tienes control, y tratar de controlarlo es una estrategia perdedora.

Lo que debe hacer es mantener los recursos a los que el usuario desea acceder en su servidor, por lo que no le ayuda a cambiar el comportamiento del cliente. Si el cliente se conecta a localhost en lugar de a su servidor, no puede acceder a los activos ya que los activos están en su servidor, no en localhost. Si intentan acceder a servicios para los que aún no han iniciado sesión, su servidor debe rechazar la solicitud. Después de todo, su servidor debe estar haciendo un seguimiento de quién ha iniciado sesión con una implementación de administración de sesión estándar (no escriba la suya; es demasiado duro y escribir el propio siempre resulta en una implementación vulnerable).

Ah, y necesitas usar criptografía, pero solo donde realmente ayuda. Use TLS 1.1 o 1.2, o use SSHv2 para proteger el tráfico de la red. Seleccione cifrados fuertes. Proporcione a sus usuarios su clave pública firmada digitalmente por una autoridad de certificación confiable. Cifre los activos cuando los almacene en su base de datos. Utilice criptografía fuerte como aes128 o 3des. Genere su clave de forma segura, lea la documentación completa acerca de su generador de números aleatorios, solo use uno que diga que está bien para fines criptográficos, que es estándar, y sin correr el riesgo de sobrescribir la semilla en lugar de complementarla (algunos documentos son muy engañosa, como java.security.SecureRandom de Java).

Y, finalmente, contrate a un experto en seguridad o vaya a aprender sobre la seguridad en OWASP.org (un buen lugar para comenzar, pero tenga cuidado, ya que ellos mismos cometen errores).