El cifrado no es su problema, ya que la mayoría de los ejemplos de cifrado C # harán lo correcto con la clase CryptoStream . Pero después de echar un vistazo rápido a el artículo de CodeProject que vinculó , puedo diga con certeza que es mejor que no use el código tal como se presenta. Enumeraré los problemas en el orden en que aparecen en el código.
-
private void EncryptFile(string inputFile, string outputFile)
El método de encriptación toma un nombre de ruta . Eso significa que los archivos estarán en su sistema de archivos en una forma vulnerable sin cifrar hasta que se encripte con este método y se elimine. Debe estar cifrado en la memoria del servidor, ya que se está conectando a través de la conexión antes de tocar cualquier dispositivo de almacenamiento.
-
string password = @"myKey123"; // Your Key Here
UnicodeEncoding UE = new UnicodeEncoding();
byte[] key = UE.GetBytes(password);
¿Que demonios? ¡La contraseña nunca debe usarse directamente desde la cadena en bruto! ¡Debe estar marcado con algo seguro!
-
CryptoStream cs = new CryptoStream(fsCrypt, RMCrypto.CreateEncryptor(key, key), CryptoStreamMode.Write);
¿Por qué el vector de inicialización es el mismo que la clave? Hay un método para eso: RijndaelManaged.GenerateIV();
-
catch { MessageBox.Show("Encryption failed!", "Error"); }
Si está ejecutando eso en un servidor sin una interfaz de usuario, eso va a causar problemas. ¡Pero el mayor problema es que este bloque de captura no es lo suficientemente específico para determinar cómo manejar el problema! Consulte Mejores prácticas para la administración de excepciones en Java o C # .
Aparte de eso, la otra debilidad potencial es cómo genera sus claves, dónde las guarda y cómo se controla el acceso a las claves.
En su caso, ¿quién guarda las claves del texto cifrado: usted o el cliente o ambos? Si también tiene las claves, tendrá que averiguar cómo un atacante que ha irrumpido en su servidor y obtuvo su texto cifrado no tendrá también sus claves.
Su mejor apuesta es almacenar los datos cifrados en el servidor con la clave cifrada. La clave en sí debe cifrarse con las credenciales del usuario. De esa manera, el servidor solo puede descifrar los datos y enviarlos al usuario cuando el usuario inicia sesión y descifra la clave con la contraseña y el servidor puede cifrar y descifrar los datos con la clave descifrada hasta que el usuario finalice la sesión, momento en el que la clave debe ser borrada de la memoria. Si implementó este sistema y sus datos fueron robados, el atacante tendría un conjunto de claves cifradas (que son inútiles hasta que se descifran con la contraseña del cliente) y blobs de datos cifrados (que también son inútiles sin las claves de descifrado).