Ne codez jamais de mots de passe en dur dans votre code. Cela a été récemment évoqué dans le Top 25 des erreurs de programmation les plus dangereuses :
Le codage en dur d'un compte secret et d'un mot de passe dans votre logiciel est extrêmement pratique - pour les ingénieurs inverseurs qualifiés. Si le mot de passe est le même pour tous vos logiciels, chaque client devient vulnérable lorsque ce mot de passe devient inévitablement connu. Et parce que c'est codé en dur, c'est une énorme douleur à réparer.
Vous devez stocker les informations de configuration, y compris les mots de passe, dans un fichier séparé que l'application lit au démarrage. C'est le seul vrai moyen d'empêcher le mot de passe de fuir suite à la décompilation (ne le compilez jamais dans le binaire pour commencer).
Pour plus d'informations sur cette erreur courante, vous pouvez lire l'article CWE-259 . L'article contient une définition plus approfondie, des exemples et de nombreuses autres informations sur le problème.
En Java, l'un des moyens les plus simples de procéder consiste à utiliser la classe Preferences. Il est conçu pour stocker toutes sortes de paramètres de programme, dont certains peuvent inclure un nom d'utilisateur et un mot de passe.
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);
}
}
Dans le code ci-dessus, vous pouvez appeler la setCredentialsméthode après avoir affiché une boîte de dialogue demandant le nom d'utilisateur et le mot de passe. Lorsque vous devez vous connecter à la base de données, vous pouvez simplement utiliser les méthodes getUsernameet getPasswordpour récupérer les valeurs stockées. Les informations de connexion ne seront pas codées en dur dans vos binaires, la décompilation ne posera donc pas de risque de sécurité.
Remarque importante: les fichiers de préférences ne sont que des fichiers XML en texte brut. Assurez-vous de prendre les mesures appropriées pour empêcher les utilisateurs non autorisés de visualiser les fichiers bruts (autorisations UNIX, autorisations Windows, et cetera). Sous Linux, au moins, ce n'est pas un problème, car l'appel Preferences.userNodeForPackagecréera le fichier XML dans le répertoire personnel de l'utilisateur actuel, qui n'est de toute façon pas lisible par les autres utilisateurs. Sous Windows, la situation peut être différente.
Notes plus importantes: Il y a eu beaucoup de discussions dans les commentaires de cette réponse et d'autres sur ce qu'est l'architecture correcte pour cette situation. La question initiale ne mentionne pas vraiment le contexte dans lequel l'application est utilisée, je vais donc parler des deux situations auxquelles je peux penser. Le premier est le cas dans lequel la personne utilisant le programme connaît déjà (et est autorisée à connaître) les informations d'identification de la base de données. Le second est le cas dans lequel vous, le développeur, essayez de garder les informations d'identification de la base de données secrètes de la personne utilisant le programme.
Premier cas: l'utilisateur est autorisé à connaître les informations de connexion à la base de données
Dans ce cas, la solution que j'ai mentionnée ci-dessus fonctionnera. La Preferenceclasse Java stockera le nom d'utilisateur et le mot de passe en texte brut, mais le fichier de préférences ne sera lisible que par l'utilisateur autorisé. L'utilisateur peut simplement ouvrir le fichier XML des préférences et lire les informations de connexion, mais ce n'est pas un risque de sécurité car l'utilisateur connaissait les informations d'identification au départ.
Deuxième cas: tentative de masquer les informations de connexion de l'utilisateur
C'est le cas le plus compliqué: l'utilisateur ne doit pas connaître les informations de connexion mais doit tout de même accéder à la base de données. Dans ce cas, l'utilisateur exécutant l'application a un accès direct à la base de données, ce qui signifie que le programme doit connaître les informations de connexion à l'avance. La solution que j'ai mentionnée ci-dessus ne convient pas à ce cas. Vous pouvez stocker les informations de connexion à la base de données dans un fichier de préférences, mais l'utilisateur pourra lire ce fichier, car il en sera le propriétaire. En fait, il n'y a vraiment aucun bon moyen d'utiliser ce boîtier de manière sécurisée.
Cas correct: utilisation d'une architecture à plusieurs niveaux
La bonne façon de le faire est d'avoir une couche intermédiaire, entre votre serveur de base de données et votre application client, qui authentifie les utilisateurs individuels et permet d'effectuer un ensemble limité d'opérations. Chaque utilisateur aurait ses propres informations de connexion, mais pas pour le serveur de base de données. Les informations d'identification permettraient d'accéder à la couche intermédiaire (le niveau de logique métier) et seraient différentes pour chaque utilisateur.
Chaque utilisateur aurait son propre nom d'utilisateur et mot de passe, qui pourraient être stockés localement dans un fichier de préférences sans aucun risque de sécurité. C'est ce qu'on appelle une architecture à trois niveaux (les niveaux étant votre serveur de base de données, votre serveur de logique métier et votre application cliente). C'est plus complexe, mais c'est vraiment le moyen le plus sûr de faire ce genre de chose.
L'ordre de base des opérations est:
- Le client s'authentifie avec le niveau de logique métier à l'aide du nom d'utilisateur / mot de passe personnel de l'utilisateur. Le nom d'utilisateur et le mot de passe sont connus de l'utilisateur et ne sont en aucun cas liés aux informations de connexion à la base de données.
- Si l'authentification réussit, le client envoie une demande au niveau de logique métier pour demander des informations à partir de la base de données. Par exemple, un inventaire de produits. Notez que la requête du client n'est pas une requête SQL; il s'agit d'un appel de procédure à distance tel que
getInventoryList.
- Le niveau de logique métier se connecte à la base de données et récupère les informations demandées. Le niveau de logique métier est en charge de former une requête SQL sécurisée en fonction de la demande de l'utilisateur. Tous les paramètres de la requête SQL doivent être nettoyés pour empêcher les attaques par injection SQL.
- Le niveau de logique métier renvoie la liste d'inventaire à l'application cliente.
- Le client affiche la liste d'inventaire à l'utilisateur.
Notez que dans l'ensemble du processus, l'application cliente ne se connecte jamais directement à la base de données . Le niveau de logique métier reçoit une demande d'un utilisateur authentifié, traite la demande du client pour une liste d'inventaire, puis n'exécute qu'une requête SQL.