Necesito cifrar algunos detalles para los usuarios de mi aplicación (no la contraseña, estoy usando bcrypt para eso), necesito acceder a los detalles en algún momento en el futuro, así que necesito poder descifrar estos detalles, para haga eso, tengo la siguiente clase en mi aplicación Spring Boot, mi pregunta es cómo proteger la contraseña utilizada para cifrar el texto.
import org.springframework.security.crypto.encrypt.Encryptors; import org.springframework.security.crypto.encrypt.TextEncryptor; public class Crypto { final static String password = "How_to_Secure_This_Password?"; public static String encrypt(String textToEncrypt, String salt) { if (textToEncrypt != null && !textToEncrypt.isEmpty()) { TextEncryptor encryptor = Encryptors.text(password, salt); String encryptedText = encryptor.encrypt(textToEncrypt); return encryptedText; } return null; } public static String decrypt(String encryptedText, String salt) { if(encryptedText != null && !encryptedText.isEmpty()) { TextEncryptor decryptor = Encryptors.text(password, salt); String decryptedText = decryptor.decrypt(encryptedText); return decryptedText; } return null; } }De mi investigación hasta ahora puedo sugerir las siguientes soluciones:
1- Obtenga la contraseña de un archivo de propiedades y use Spring Cloud Config para la función de cifrado/descifrado del archivo de propiedades (valores prefijados con la cadena {cipher}), un buen punto de partida está aquí . No me gusta esta solución ya que no necesito la estructura de configuración cliente/servidor, y no me siento bien al usarla solo por una característica, creo que Spring Framework debería tener una característica similar.
2- Use la biblioteca Jasypt , o su soporte 'no oficial' para el arranque de primavera desde aquí . Nuevamente, ¿no está seguro de si el problema es una cuestión de encriptar esta contraseña en un archivo de propiedades?
3- use la bóveda que parece construida para algo similar a lo que necesito aquí (claves de API, secretos, etc.) pero es demasiado sobrecarga para construir, mantener e integrar...
Mi argumento aquí es que si un atacante pudo acceder a mi(s) máquina(s) de la base de datos, entonces lo más probable es que pueda acceder a la(s) máquina(s) de la aplicación, lo que significa que puede hacer ingeniería inversa de la clase y podrá descifrar todos los detalles que quiero asegurar! Me siento confundido aquí, ¿cuál es la mejor práctica y el estándar de la industria aquí?
La mejor solución hasta ahora es usar Spring Cloud Vault , ya que ya estoy usando Spring Boot, puede ofrecer más que asegurar esta contraseña, de hecho, puede asegurar la contraseña para muchas claves API, bases de datos, etc. (es una versión RC en ese momento de escritura) .. sin embargo, todavía no estoy convencido de que esta sea la solución definitiva ya que mi aplicación aún necesita autenticarse en Vault, pero debo decir que esto se hace de una manera más avanzada y da un paso más allá que manteniendo las contraseñas en los archivos de configuración...
El problema es el problema del huevo y la gallina, y resulta que SO tiene muchas preguntas similares para escenarios similares (guardar la contraseña de la base de datos en la configuración, ocultarla en el código, ocultar la contraseña en la tienda PBE , etc.).
Esto bien explicado por Mark Paluch en su artículo de introducción
Los datos cifrados son un paso mejor que los no cifrados. El cifrado impone en el otro lado la necesidad de descifrar en el lado del usuario, lo que requiere que se distribuya una clave de descifrado. Ahora, ¿dónde pones la llave? ¿La clave está protegida por una frase de contraseña? ¿Dónde pones la contraseña? ¿En cuántos sistemas distribuye su clave y la frase de contraseña?
Como puede ver, el cifrado presenta un problema del huevo de la gallina. Almacenar una clave de descifrado le da a la aplicación la posibilidad de descifrar datos. También permite un vector de ataque. Alguien que no esté autorizado podría obtener acceso a la clave de descifrado al tener acceso a la máquina. Esa persona puede descifrar los datos que se pueden descifrar con esta clave. La clave es estática, por lo que una clave filtrada requiere el cambio de claves. Es necesario volver a cifrar los datos y cambiar las credenciales. No es posible descubrir dicha fuga con una medida en línea porque los datos se pueden descifrar fuera de línea una vez que se obtienen.
.......
Vault no es la respuesta a todos los problemas de seguridad. Vale la pena consultar la documentación del modelo de seguridad de Vault para tener una idea del modelo de amenazas.
Irónicamente, el backend de almacenamiento de Vault debe configurarse con contraseñas de texto sin formato para la mayoría de los casos (MySQL, S3, Azure, ... Todavía no acepto esto como una respuesta a mi pregunta, pero esto es lo que he encontrado hasta ahora, ¡esperando más aportes de otros colaboradores de SO con agradecimiento!
Vault es una buena solución, pero una forma de hacerlo sería proporcionar la contraseña manualmente cuando inicialice el componente, de modo que se almacene en la memoria y no se escriba en ningún archivo de configuración.