2008-09-19 23 views
7

Tengo un archivo de propiedades en java, en el que almaceno toda la información de mi aplicación, como nombre de archivo de logo, nombre de base de datos, usuario de base de datos y contraseña de base de datos.
Puedo almacenar la contraseña cifrada en el archivo de propiedades.
Pero la clave o frase de contraseña se puede leer desde el contenedor utilizando un decompilador.
¿Hay alguna forma de almacenar el paso de db en un archivo de propiedades de forma segura?Proteger contraseña incrustada

Respuesta

3

Existen varias formas de administrar esto. Si puede encontrar la forma de que un usuario proporcione una contraseña para un almacén de claves cuando se inicia la aplicación, la forma más adecuada sería encriptar todos los valores usando una clave, y almacenar esta clave en el almacén de claves. La interfaz de línea de comando para el almacén de claves es mediante el uso de keytool. Sin embargo, JSE también tiene API para acceder mediante programación al almacén de claves.

Si no tiene la posibilidad de que un usuario proporcione manualmente una contraseña al almacén de claves al inicio (por ejemplo, para una aplicación web), una forma de hacerlo es escribir una rutina de ofuscación excepcionalmente compleja que pueda oscurecer la clave y almacenarlo en un archivo de propiedad también. Cosas importantes para recordar es que la lógica de ofuscación y desofuscación debe ser de varias capas (podría involucrar cifrado, codificación, introducción de caracteres espurios, etc.) y debería tener al menos una clave que podría ocultarse en otras clases de la aplicación. usando nombres no intuitivos. Este no es un mecanismo completamente seguro ya que alguien con un descompilador y una buena cantidad de tiempo e inteligencia aún pueden solucionarlo, pero es el único que conozco que no requiere que se rompa en código nativo (es decir, no fácilmente descompilable) .

1

No, no hay. Incluso si lo encriptas, alguien descompilará el código que lo descifra.

+0

Si le das a alguien la llave y el candado, pueden duplicar la llave y acceder al candado sin la llave que les diste originalmente. A menos que no proporcione la clave, no hay manera de evitar que lo hagan. Es el defecto fundamental con DRM también. –

0

Puede crear un archivo de propiedades separado (fuera del contenedor) para las contraseñas (ya sea una contraseña de base de datos directa o una frase de contraseña clave) y no incluir ese archivo de propiedades con la distribución. O puede hacer que el servidor solo acepte ese inicio de sesión desde una máquina específica para que se requiera suplantación.

2

Almacena un hash SHA1 de la contraseña en su archivo de propiedades. Luego, cuando valide la contraseña de un usuario, compruebe su intento de inicio de sesión y asegúrese de que los dos hashes coincidan.

Este es el código que copiará algunos bytes para usted. Puedes fácilmente ger bytes desde una Cadena usando el método getBytes().

/** 
    * Returns the hash value of the given chars 
    * 
    * Uses the default hash algorithm described above 
    * 
    * @param in 
    *   the byte[] to hash 
    * @return a byte[] of hashed values 
    */ 
    public static byte[] getHashedBytes(byte[] in) 
    { 
     MessageDigest msg; 
     try 
     { 
      msg = MessageDigest.getInstance(hashingAlgorithmUsed); 
     } 
     catch (NoSuchAlgorithmException e) 
     { 
      throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist. Epic fail, go change it in the Util file. SHA(1) or MD5"); 
     } 
     msg.update(in); 
     return msg.digest(); 
    } 
+0

Buena respuesta, pero no a su pregunta. –

+0

Supongo que no entiendo completamente la pregunta entonces. – jjnguy

+2

Quiere guardar el nombre de usuario y la contraseña que la aplicación usará para conectarse a la base de datos.Por lo tanto, debe ser capaz de volver a convertirlo en texto sin formato antes de que se conecte a la base de datos. –

0

Además de la encriptación de las contraseñas como se describe anteriormente poner ninguna contraseña en las propiedades separadas de archivo y en el despliegue tratar de dar este archivo los permisos más cerradas hacia abajo posible.

Por ejemplo, si su servidor de aplicaciones se ejecuta en Linux/Unix como root, haga que el archivo de propiedades de contraseña sea propiedad de root con 400/-r-------- permisos.

0

¿No podría hacer que la aplicación se ponga en contacto con un servidor a través de https y descargue la contraseña, después de autenticarse de alguna manera, por supuesto?

Cuestiones relacionadas