¿Qué riesgos debo tener en cuenta al cifrar el lado del servidor en lugar del lado del cliente?

Dice que desea usar el cifrado del lado del servidor para limitar la exposición al malware del lado del cliente. Eso no tiene sentido. Si hay software malicioso o software espía en el cliente, entonces es posible que se dirija de cualquier manera. El cifrado en el servidor no ayuda, ya que los datos siguen existiendo en texto claro en el cliente, por lo que el software malicioso / spyware del lado del cliente puede capturar los datos de texto claro.

Creo que necesita volver a revisar sus requisitos y su enfoque. Si le preocupa el malware del lado del cliente, solo puedo ver dos opciones: (1) garantizar que los datos confidenciales nunca lleguen al cliente en texto claro, o (2) implementar defensas para reducir la probabilidad de malware en el lado del cliente. La encriptación en el lado del servidor realmente no ayuda.

El envío de los datos del cliente al servidor y luego el cifrado en el servidor tiene todos los riesgos de seguridad del cifrado del lado del cliente, más algunos riesgos adicionales:

• Si el servidor está comprometido, o si alguna de las cuentas de sus empleados está comprometida, entonces el atacante obtiene acceso a los datos. (Twitter fue puesto por el segundo. Muchas compañías fueron puestas por el primero.)

• Debido a que técnicamente tiene la capacidad de descifrar los datos, ahora significa que puede estar sujeto a citaciones, garantías o demandas de las autoridades policiales para descifrar los datos si ellos quieren / necesitan acceso. Si usted es una operación pequeña, esto podría no ser un gran problema, pero en una operación grande, esto podría comenzar a crear algunos costos de cumplimiento para usted.

• Si el atacante puede montar un ataque de hombre en el medio (por ejemplo, atacar a un usuario que se está conectando a través de wifi abierta), y si los usuarios del usuario a través de las advertencias de certificados SSL, entonces el atacante puede obtener acceso a los datos sensibles.

Una de las ventajas del cifrado del lado del servidor es que le permite realizar la administración de claves en el lado del servidor, lo que reduce la carga para los usuarios. Por ejemplo, si los usuarios pierden u olvidan sus claves, puede recuperarlas para ellos.

Otra posible ventaja del cifrado del lado del servidor es que la ventana de tiempo cuando los datos existen en el texto del cliente en texto claro podría reducirse, lo que podría reducir la exposición a violaciones de datos si, por ejemplo, la máquina cliente es robada o se pierde. Sin embargo, esta ventaja puede ser bastante modesta en la práctica y puede haber mejores soluciones para este problema (por ejemplo, cifrado de disco completo).

Comenzaré con un sistema de autenticación simple.

Le pide al usuario su nombre de usuario / contraseña, que envía a su servidor. En el servidor, hash la contraseña para compararla con la base de datos (no voy a hablar aquí sobre la importancia de hacer hashing de una contraseña y usar sal y pimienta).

No, usando una conexión no cifrada (SSL), alguien entre su usuario y su servidor puede leer los datos transmitidos (conocido como ataque Man In The Middle) y conocer su contraseña de usuario.

Para eso, puede usar una conexión SSL para proteger a su usuario de la lectura mientras envía datos al servidor. Es la mejor manera segura hasta ahora (nuevamente, no hablaré de la limitación de SSL aquí).

Pero se puede hacer otra alternativa. Puede hash la contraseña usando md5 / sha directamente en el navegador de su usuario y enviarle el hash. Algunas bibliotecas de Javascript existen para eso. Pero debes recordar que no todos los usuarios tendrán habilitado javascript (excepto que los obligas a usarlo). Además, utilizando este método, no podrá agregar sal y pimienta sin comprometer la seguridad general.

Además, no olvides que esto no te protegerá de nuevo, no registradores de teclas, troyanos y otros. Sólo ataques MitM.

Ahora, para la carga del archivo. La carga de archivos predeterminada de los navegadores, me refiero a que <input type="file" /> no enviará datos cifrados. Si desea hacerlo, deberá implementar un sistema Java o Flash para cargar archivos que cifrarán los datos antes de enviarlos a la red. Nuevamente, esto no protegerá a sus usuarios si tienen un virus en su computadora.

Recuerde que la ideología entre cliente < - > El servidor es su relación entre ellos. No puede proteger a su usuario contra virus, solo puede mejorar la seguridad en el enlace entre el cliente < - > servidor y también su servidor.

Ahora, si desea proteger su servidor para la carga de código malintencionado, habilitar la seguridad en el lado del cliente será inútil. No puedes nunca confiar en lo que los usuarios te envían. Incluso si creas la aplicación html más sofisticada, alguien podrá enviarte datos sin usar esta aplicación.

Todo lo que tiene que hacer es mejorar la seguridad en su servidor: verifique si el archivo enviado es del tipo correcto al verificar su tipo MIM (con la herramienta correcta, no solo la extensión). Siempre rechace los archivos que se pueden ejecutar (.exe, .sh, etc.) y más, asegúrese de qué hacer con esos archivos. (Puede permitir la carga de archivos .php, ¡pero debe colocarlos en un directorio donde no se puedan ejecutar desde una ubicación remota!)