Protéger le mot de passe intégré

Question

J'ai un fichier de propriétés en java dans lequel je stocke toutes les informations de mon application, telles que le nom de fichier du logo, le nom de la base de données, l'utilisateur de la base de données et le mot de passe de la base de données.
Je peux stocker le mot de passe chiffré dans le fichier de propriétés.
Mais, la clé ou le mot de passe peut être lu hors du pot à l'aide d'un décompilateur.
Existe-t-il un moyen de stocker le passe de base de données dans un fichier de propriétés de manière sécurisée?

Answer 1

Il existe plusieurs façons de gérer cela. Si vous pouvez trouver un moyen de demander à un utilisateur de fournir un mot de passe pour un fichier de clés au démarrage de l'application, le moyen le plus approprié consiste à chiffrer toutes les valeurs à l'aide d'une clé et à stocker cette clé dans le fichier de clés. L'interface de ligne de commande avec le magasin de clés est à l'aide de keytool. Toutefois, JSE dispose d’API pour accéder également au fichier de clés par programmation.

Si vous ne pouvez pas demander à un utilisateur de fournir manuellement un mot de passe au magasin de clés au démarrage (par exemple, pour une application Web), vous pouvez le faire en écrivant une routine d'obfuscation exceptionnellement complexe pouvant masquer la clé et stockez-le également dans un fichier de propriétés. Il est important de se rappeler que la logique d’obscurcissement et de désobfuscation doit comporter plusieurs couches (peut impliquer l’embrouillage, l’encodage, l’introduction de caractères parasites, etc.) et doit avoir elle-même au moins une clé pouvant être cachée dans d’autres classes de l’application. en utilisant des noms non intuitifs. Ce n'est pas un mécanisme totalement sûr, car une personne disposant d'un décompilateur et disposant de suffisamment de temps et d'intelligence peut toujours le contourner, mais c'est le seul que je connaisse qui ne vous oblige pas à entrer dans le code natif (c'est-à-dire non facilement décompilable). .

Answer 2

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

Ceci est le code qui va hacher des octets pour vous. Vous pouvez facilement obtenir des octets depuis une chaîne en utilisant 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 3

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

Answer 4

Vous pouvez créer un fichier de propriétés distinct (en dehors du fichier JAR) pour les mots de passe (mot de passe direct de la base de données ou phrase de passe de clé) et ne pas inclure ce fichier de propriétés dans la distribution. Vous pouvez également faire en sorte que le serveur accepte uniquement la connexion à partir d’une machine spécifique, ce qui nécessite une usurpation de contenu.

Answer 5

En plus de chiffrer les mots de passe comme décrit ci-dessus, placez-les dans un fichier de propriétés distinct. Lors du déploiement, essayez de lui octroyer les autorisations les plus verrouillées possibles.

Par exemple, si votre serveur d'applications s'exécute sous Linux / Unix en tant que racine , créez le fichier de propriétés du mot de passe appartenant à racine avec 400 / -r--. ------ autorisations.

Answer 6

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