Protéger le mot de passe intégré

Question

J'ai un fichier de propriétés dans java, dans lequel je stocke toutes les informations de mon application, comme nom de fichier image, nom de base de données, utilisateur de base de données et mot de passe de base de données.
Je peux stocker le mot de passe chiffré sur le fichier de propriétés.
Mais, la clé ou mot de passe peut être lu hors du pot en utilisant un décompilateur.
Existe-t-il un moyen de stocker le passage DB dans un fichier de propriétés en toute sécurité?

Answer 1

Il y a plusieurs façons de gérer cela. Si vous pouvez trouver un moyen pour qu'un utilisateur fournisse un mot de passe pour un fichier de clés au démarrage de l'application, le moyen le plus approprié serait de chiffrer toutes les valeurs à l'aide d'une clé et de stocker cette clé dans le magasin de clés. L'interface de ligne de commande du magasin de clés utilise l'outil keytool. Toutefois, JSE a des API pour accéder par programme au fichier de clés. Si vous ne disposez pas de la possibilité pour un utilisateur de fournir manuellement un mot de passe au keystore au démarrage (par exemple pour une application Web), une façon de le faire est d'écrire une routine d'obfuscation exceptionnellement complexe qui peut masquer la clé et stockez-le dans un fichier de propriétés. Il est important de garder à l'esprit que la logique d'obfuscation et de désobfuscation doit être multicouche (il peut s'agir de brouillage, d'encodage, d'introduction de caractères parasites, etc.) et doit comporter au moins une clé pouvant être cachée dans les autres classes de l'application en utilisant des noms non intuitifs. Ce mécanisme n'est pas totalement sûr car une personne disposant d'un décompilateur et d'une bonne quantité de temps et d'intelligence peut toujours contourner le problème, mais c'est la seule que je connaisse qui ne nécessite pas d'entrer dans le code natif (facilement décompilable) .

Answer 2

Non, il n'y en a pas. Même si vous le cryptez, quelqu'un décompilera le code qui le déchiffre.

Answer 3

Vous pouvez créer un fichier de propriétés distinct (en dehors du fichier jar) pour les mots de passe (mot de passe DB direct ou phrase clé) et ne pas inclure ce fichier de propriétés dans la distribution. Ou vous pourriez être en mesure de faire en sorte que le serveur accepte uniquement cette connexion à partir d'une machine spécifique afin que l'usurpation d'identité soit requise.

Answer 4

Vous stockez un hachage SHA1 du mot de passe dans votre fichier de propriétés. Ensuite, lorsque vous validez un mot de passe d'utilisateur, vous hachez leur tentative de connexion et assurez-vous que les deux hachages correspondent.

Ceci est le code qui va hacher quelques octets pour vous. Vous pouvez facilement générer des octets à partir d'une chaîne à l'aide de la méthode 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(); 
    } 

Answer 5

En plus de chiffrer les mots de passe comme décrit ci-dessus mis des mots de passe dans un fichier distinct des propriétés et sur le déploiement essayer de donner ce fichier les plus verrouillés autorisations vers le bas possible. Par exemple, si votre serveur d'applications s'exécute sous Linux/Unix en tant que root, définissez le fichier de propriétés de mot de passe détenu par root avec les autorisations 400/-r--------.

Answer 6

L'application ne peut-elle pas contacter un serveur via https et télécharger le mot de passe, après s'être authentifiée d'une manière ou d'une autre?