Nunca codifique contraseñas en su código. Esto se mencionó recientemente entre los 25 errores de programación más peligrosos :
La codificación rígida de una cuenta secreta y una contraseña en su software es extremadamente conveniente, para ingenieros en reversa calificados. Si la contraseña es la misma en todo su software, todos los clientes se vuelven vulnerables cuando esa contraseña inevitablemente se da a conocer. Y debido a que está codificado de forma rígida, es un gran problema arreglarlo.
Debe almacenar la información de configuración, incluidas las contraseñas, en un archivo separado que la aplicación lee cuando se inicia. Esa es la única forma real de evitar que la contraseña se filtre como resultado de la descompilación (nunca la compile en el binario para empezar).
Para obtener más información sobre este error común, puede leer el artículo CWE-259 . El artículo contiene una definición más completa, ejemplos y mucha más información sobre el problema.
En Java, una de las formas más sencillas de hacer esto es utilizar la clase Preferencias. Está diseñado para almacenar todo tipo de configuraciones de programas, algunas de las cuales podrían incluir un nombre de usuario y una contraseña.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
En el código anterior, puede llamar al setCredentialsmétodo después de mostrar un cuadro de diálogo solicitando el nombre de usuario y la contraseña. Cuando necesite conectarse a la base de datos, puede usar los métodos getUsernamey getPasswordpara recuperar los valores almacenados. Las credenciales de inicio de sesión no estarán codificadas en sus archivos binarios, por lo que la descompilación no representará un riesgo de seguridad.
Nota importante: los archivos de preferencias son archivos XML de texto sin formato. Asegúrese de tomar las medidas adecuadas para evitar que usuarios no autorizados vean los archivos sin formato (permisos de UNIX, permisos de Windows, etc.). En Linux, al menos, esto no es un problema, porque la llamada Preferences.userNodeForPackagecreará el archivo XML en el directorio de inicio del usuario actual, que de todos modos no es legible por otros usuarios. En Windows, la situación puede ser diferente.
Notas más importantes: ha habido mucha discusión en los comentarios de esta respuesta y otras sobre cuál es la arquitectura correcta para esta situación. La pregunta original realmente no menciona el contexto en el que se está utilizando la aplicación, así que hablaré sobre las dos situaciones que se me ocurren. El primero es el caso en el que la persona que usa el programa ya conoce (y está autorizada a conocer) las credenciales de la base de datos. El segundo es el caso en el que usted, el desarrollador, está tratando de mantener en secreto las credenciales de la base de datos de la persona que usa el programa.
Primer caso: el usuario está autorizado a conocer las credenciales de inicio de sesión de la base de datos
En este caso, la solución que mencioné anteriormente funcionará. La Preferenceclase Java almacenará el nombre de usuario y la contraseña en texto sin formato, pero el archivo de preferencias solo podrá leerlo el usuario autorizado. El usuario puede simplemente abrir el archivo XML de preferencias y leer las credenciales de inicio de sesión, pero eso no es un riesgo de seguridad porque el usuario conocía las credenciales para empezar.
Segundo caso: intentar ocultar las credenciales de inicio de sesión del usuario
Este es el caso más complicado: el usuario no debe conocer las credenciales de inicio de sesión, pero aún necesita acceso a la base de datos. En este caso, el usuario que ejecuta la aplicación tiene acceso directo a la base de datos, lo que significa que el programa necesita conocer las credenciales de inicio de sesión con anticipación. La solución que mencioné anteriormente no es apropiada para este caso. Puede almacenar las credenciales de inicio de sesión de la base de datos en un archivo de preferencias, pero el usuario podrá leer ese archivo, ya que será el propietario. De hecho, no existe una buena forma de utilizar este estuche de forma segura.
Caso correcto: uso de una arquitectura de varios niveles
La forma correcta de hacerlo es tener una capa intermedia, entre su servidor de base de datos y su aplicación cliente, que autentique a los usuarios individuales y permita realizar un conjunto limitado de operaciones. Cada usuario tendría sus propias credenciales de inicio de sesión, pero no para el servidor de la base de datos. Las credenciales permitirían el acceso a la capa intermedia (el nivel de lógica empresarial) y serían diferentes para cada usuario.
Cada usuario tendría su propio nombre de usuario y contraseña, que podrían almacenarse localmente en un archivo de preferencias sin ningún riesgo de seguridad. Esto se denomina arquitectura de tres niveles (los niveles son el servidor de base de datos, el servidor de lógica empresarial y la aplicación cliente). Es más complejo, pero realmente es la forma más segura de hacer este tipo de cosas.
El orden básico de operaciones es:
- El cliente se autentica con el nivel de lógica empresarial utilizando el nombre de usuario / contraseña personal del usuario. El usuario y la contraseña son conocidos por el usuario y no están relacionados con las credenciales de inicio de sesión de la base de datos de ninguna manera.
- Si la autenticación tiene éxito, el cliente realiza una solicitud al nivel de lógica empresarial solicitando información de la base de datos. Por ejemplo, un inventario de productos. Tenga en cuenta que la solicitud del cliente no es una consulta SQL; es una llamada a procedimiento remoto como
getInventoryList.
- El nivel de lógica empresarial se conecta a la base de datos y recupera la información solicitada. El nivel de lógica de negocios se encarga de formar una consulta SQL segura basada en la solicitud del usuario. Todos los parámetros de la consulta SQL deben desinfectarse para evitar ataques de inyección SQL.
- El nivel de lógica empresarial envía la lista de inventario a la aplicación cliente.
- El cliente muestra la lista de inventario al usuario.
Tenga en cuenta que en todo el proceso, la aplicación cliente nunca se conecta directamente a la base de datos . El nivel de lógica empresarial recibe una solicitud de un usuario autenticado, procesa la solicitud del cliente de una lista de inventario y solo entonces ejecuta una consulta SQL.