Pourquoi char [] est-il préféré à String pour les mots de passe?

Dans Swing, le champ de mot de passe a une méthode getPassword()(retours char[]) au lieu de la méthode habituelle getText()(retours String). De même, je suis tombé sur une suggestion de ne pas utiliser Stringpour gérer les mots de passe.

Pourquoi Stringconstitue- t-il une menace pour la sécurité en ce qui concerne les mots de passe? Cela semble gênant à utiliser char[].

Les cordes sont immuables . Cela signifie qu'une fois que vous avez créé le String, si un autre processus peut vider la mémoire, il n'y a aucun moyen (à part la réflexion ) que vous puissiez vous débarrasser des données avant que la collecte des ordures n'intervienne.

Avec un tableau, vous pouvez effacer explicitement les données une fois que vous en avez terminé. Vous pouvez écraser le tableau avec tout ce que vous voulez et le mot de passe ne sera présent nulle part dans le système, même avant le ramassage des ordures.

Alors oui, c'est un problème de sécurité - mais même l'utilisation char[]ne fait que réduire la fenêtre d'opportunité pour un attaquant, et ce n'est que pour ce type d'attaque spécifique.

Comme indiqué dans les commentaires, il est possible que les tableaux déplacés par le garbage collector laissent des copies parasites des données en mémoire. Je crois que cela est spécifique à l'implémentation - le garbage collector peut effacer toute la mémoire au fur et à mesure, pour éviter ce genre de chose. Même si c'est le cas, il reste le temps pendant lequel le char[]contient les personnages réels comme fenêtre d'attaque.

Alors que d'autres suggestions semblent valables ici, il y a une autre bonne raison. Avec plain, Stringvous avez beaucoup plus de chances d' imprimer accidentellement le mot de passe dans les journaux , les moniteurs ou tout autre endroit non sécurisé. char[]est moins vulnérable.

Considère ceci:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

Tirages:

String: Password
Array: [C@5829428e

Pour citer un document officiel, le guide de Java Cryptography architecture dit ceci au sujet par char[]rapport aux Stringmots de passe (sur le cryptage par mot de passe, mais cela est plus généralement sur les mots de passe bien sûr):

Il semblerait logique de collecter et de stocker le mot de passe dans un objet de type java.lang.String. Cependant, voici la mise en garde: Objectles types de type Stringsont immuables, c'est-à-dire qu'aucune méthode définie ne vous permet de modifier (écraser) ou de mettre à zéro le contenu d'une String utilisation ultérieure. Cette fonctionnalité rend les Stringobjets inadaptés au stockage d'informations sensibles pour la sécurité telles que les mots de passe des utilisateurs. Vous devez toujours collecter et stocker des informations sensibles à la sécurité dans un chartableau à la place.

La directive 2-2 des directives de codage sécurisé pour le langage de programmation Java, version 4.0 dit également quelque chose de similaire (bien que ce soit à l'origine dans le contexte de la journalisation):

Ligne directrice 2-2: ne pas enregistrer d'informations très sensibles

Certaines informations, telles que les numéros de sécurité sociale (SSN) et les mots de passe, sont très sensibles. Ces informations ne doivent pas être conservées plus longtemps que nécessaire ni là où elles peuvent être vues, même par les administrateurs. Par exemple, il ne doit pas être envoyé dans des fichiers journaux et sa présence ne doit pas être détectable lors de recherches. Certaines données transitoires peuvent être conservées dans des structures de données modifiables, telles que des tableaux de caractères, et effacées immédiatement après leur utilisation. La suppression des structures de données a réduit l'efficacité sur les systèmes d'exécution Java typiques car les objets sont déplacés en mémoire de manière transparente vers le programmeur.

Cette directive a également des implications pour la mise en œuvre et l'utilisation de bibliothèques de niveau inférieur qui n'ont pas de connaissances sémantiques sur les données qu'elles traitent. Par exemple, une bibliothèque d'analyse de chaîne de bas niveau peut enregistrer le texte sur lequel elle fonctionne. Une application peut analyser un SSN avec la bibliothèque. Cela crée une situation où les SSN sont disponibles pour les administrateurs ayant accès aux fichiers journaux.

Les tableaux de caractères ( char[]) peuvent être effacés après utilisation en mettant chaque caractère à zéro et non aux chaînes. Si quelqu'un peut en quelque sorte voir l'image de la mémoire, il peut voir un mot de passe en texte brut si des chaînes sont utilisées, mais s'il char[]est utilisé, après avoir purgé les données avec des 0, le mot de passe est sécurisé.

Certaines personnes pensent que vous devez remplacer la mémoire utilisée pour stocker le mot de passe une fois que vous n'en avez plus besoin. Cela réduit la fenêtre de temps dont dispose un attaquant pour lire le mot de passe de votre système et ignore complètement le fait que l'attaquant a déjà besoin d'un accès suffisant pour détourner la mémoire JVM pour ce faire. Un attaquant avec autant d'accès peut attraper vos événements clés, ce qui le rend complètement inutile (AFAIK, alors corrigez-moi si je me trompe).

Mise à jour

Grâce aux commentaires, je dois mettre à jour ma réponse. Apparemment, il y a deux cas où cela peut ajouter une amélioration (très) mineure de la sécurité car cela réduit le temps qu'un mot de passe peut atterrir sur le disque dur. Pourtant, je pense que c'est exagéré pour la plupart des cas d'utilisation.

• Votre système cible peut être mal configuré ou vous devez le supposer et vous devez être paranoïaque à propos des vidages de mémoire (peut être valide si les systèmes ne sont pas gérés par un administrateur).
• Votre logiciel doit être trop paranoïaque pour éviter les fuites de données avec l'attaquant ayant accès au matériel - en utilisant des choses comme TrueCrypt (interrompu), VeraCrypt ou CipherShed .

Si possible, la désactivation des vidages mémoire et du fichier d'échange résoudrait les deux problèmes. Cependant, ils nécessiteraient des droits d'administrateur et pourraient réduire les fonctionnalités (moins de mémoire à utiliser) et extraire la RAM d'un système en cours d'exécution serait toujours une préoccupation valable.

Je ne pense pas que ce soit une suggestion valable, mais je peux au moins deviner la raison.

Je pense que la motivation est de vouloir vous assurer que vous pouvez effacer toute trace du mot de passe en mémoire rapidement et avec certitude après son utilisation. Avec un, char[]vous pouvez remplacer chaque élément du tableau par un blanc ou quelque chose à coup sûr. Vous ne pouvez pas modifier la valeur interne de Stringcette façon.

Mais cela seul n'est pas une bonne réponse; pourquoi ne pas simplement vous assurer qu'une référence au char[]ou Stringne s'échappe pas? Ensuite, il n'y a pas de problème de sécurité. Mais le fait est que les Stringobjets peuvent être intern()édités en théorie et maintenus en vie à l'intérieur du bassin constant. Je suppose que l'utilisation char[]interdit cette possibilité.

La réponse a déjà été donnée, mais je voudrais partager un problème que j'ai découvert récemment avec les bibliothèques standard Java. Bien qu'ils prennent grand soin maintenant de remplacer les chaînes de mot de passe par char[]partout (ce qui est bien sûr une bonne chose), d'autres données critiques pour la sécurité semblent être ignorées lorsqu'il s'agit de les effacer de la mémoire.

Je pense par exemple à la classe PrivateKey . Considérez un scénario dans lequel vous chargeriez une clé RSA privée à partir d'un fichier PKCS # 12, en l'utilisant pour effectuer une opération. Maintenant, dans ce cas, renifler le mot de passe seul ne vous aiderait pas tant que l'accès physique au fichier de clé est correctement restreint. En tant qu'attaquant, vous feriez beaucoup mieux si vous obteniez la clé directement au lieu du mot de passe. Les informations souhaitées peuvent être des fuites multiples, des vidages de mémoire, une session de débogage ou des fichiers d'échange ne sont que quelques exemples.

Et il s'avère que rien ne vous permet d'effacer les informations privées d'un PrivateKeyde la mémoire, car il n'y a pas d'API qui vous permet d'effacer les octets qui forment les informations correspondantes.

C'est une mauvaise situation, car cet article décrit comment cette circonstance pourrait être potentiellement exploitée.

La bibliothèque OpenSSL, par exemple, écrase les sections de mémoire critiques avant de libérer les clés privées. Étant donné que Java est récupéré, nous aurions besoin de méthodes explicites pour effacer et invalider les informations privées des clés Java, qui doivent être appliquées immédiatement après l'utilisation de la clé.

Comme le dit Jon Skeet, il n'y a pas d'autre moyen que d'utiliser la réflexion.

Cependant, si la réflexion est une option pour vous, vous pouvez le faire.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

lors de l'exécution

please enter a password
hello world
password: '***********'

Remarque: si le caractère de la chaîne [] a été copié dans le cadre d'un cycle GC, il est possible que la copie précédente se trouve quelque part en mémoire.

Cette ancienne copie n'apparaîtrait pas dans un vidage de tas, mais si vous avez un accès direct à la mémoire brute du processus, vous pouvez la voir. En général, vous devez éviter que quiconque ait un tel accès.

Ce sont toutes les raisons, il faut choisir un tableau char [] au lieu de String pour un mot de passe.

1. Étant donné que les chaînes sont immuables en Java, si vous stockez le mot de passe en texte brut, il sera disponible en mémoire jusqu'à ce que le garbage collector le supprime, et puisque String est utilisé dans le pool de chaînes pour être réutilisable, il y a de fortes chances qu'il le soit. rester en mémoire pendant une longue durée, ce qui constitue une menace pour la sécurité.

Étant donné que toute personne ayant accès au vidage de la mémoire peut trouver le mot de passe en texte clair, c'est une autre raison pour laquelle vous devez toujours utiliser un mot de passe crypté plutôt que du texte brut. Étant donné que les chaînes sont immuables, il est impossible de modifier le contenu des chaînes car toute modification produira une nouvelle chaîne, tandis que si vous utilisez un char [], vous pouvez toujours définir tous les éléments comme vides ou nuls. Ainsi, le stockage d'un mot de passe dans un tableau de caractères atténue clairement le risque de sécurité de voler un mot de passe.

2. Java lui-même recommande d'utiliser la méthode getPassword () de JPasswordField qui retourne un char [], au lieu de la méthode obsolète getText () qui retourne les mots de passe en texte clair en indiquant des raisons de sécurité. Il est bon de suivre les conseils de l'équipe Java et de se conformer aux normes plutôt que de s'y opposer.

3. Avec String, il y a toujours un risque d'imprimer du texte brut dans un fichier journal ou une console, mais si vous utilisez un tableau, vous n'imprimerez pas le contenu d'un tableau, mais son emplacement de mémoire sera imprimé. Bien que ce ne soit pas une vraie raison, cela reste logique.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [C@110b053

Référencé depuis ce blog . J'espère que ça aide.

Edit: Pour en revenir à cette réponse après un an de recherche sur la sécurité, je me rends compte que cela implique plutôt malheureusement que vous compareriez réellement des mots de passe en texte brut. S'il vous plait, ne le faites pas. Utilisez un hachage unidirectionnel sécurisé avec un sel et un nombre raisonnable d'itérations . Pensez à utiliser une bibliothèque: ce truc est difficile à réaliser!

Réponse originale: Qu'en est-il du fait que String.equals () utilise une évaluation de court-circuit et est donc vulnérable à une attaque de synchronisation? Cela peut être peu probable, mais vous pourriez théoriquement chronométrer la comparaison des mots de passe afin de déterminer la séquence correcte de caractères.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

Quelques ressources supplémentaires sur le timing des attaques:

• Une leçon sur les attaques temporelles
• Une discussion sur le chronométrage des attaques sur Exchange de la pile de sécurité de l'information
• Et bien sûr, la page Wikipedia Timing Attack

Il n'y a rien que le tableau de caractères vous donne contre String à moins que vous ne le nettoyiez manuellement après utilisation, et je n'ai vu personne le faire. Donc, pour moi, la préférence de char [] vs String est un peu exagérée.

Jetez un œil à la bibliothèque Spring Security _{largement utilisée} ici et posez-vous la question - les gars de Spring Security sont-ils incompétents ou char [] n'ont tout simplement pas beaucoup de sens. Quand un pirate méchant saisit les vidages de mémoire de votre RAM, assurez-vous qu'il obtiendra tous les mots de passe même si vous utilisez des moyens sophistiqués pour les cacher.

Cependant, Java change tout le temps, et certaines fonctionnalités effrayantes comme la fonction de déduplication des chaînes de Java 8 peuvent interner des objets String à votre insu. Mais c'est une conversation différente.

Les chaînes sont immuables et ne peuvent pas être modifiées une fois qu'elles ont été créées. La création d'un mot de passe sous forme de chaîne laissera des références erronées au mot de passe sur le tas ou sur le pool de chaînes. Maintenant, si quelqu'un prend un vidage de tas du processus Java et analyse attentivement, il pourrait être en mesure de deviner les mots de passe. Bien sûr, ces chaînes non utilisées seront récupérées, mais cela dépend du moment où le GC entre en jeu.

D'un autre côté, les char [] sont mutables dès que l'authentification est terminée, vous pouvez les écraser avec n'importe quel caractère comme tous les M ou les barres obliques inverses. Maintenant, même si quelqu'un prend un vidage de tas, il pourrait ne pas être en mesure d'obtenir les mots de passe qui ne sont pas actuellement utilisés. Cela vous donne plus de contrôle dans le sens comme l'effacement du contenu de l'objet vous-même par rapport à l'attente du GC pour le faire.

La chaîne est immuable et va au pool de chaînes. Une fois écrit, il ne peut pas être écrasé.

char[] est un tableau que vous devez remplacer une fois que vous avez utilisé le mot de passe et voici comment procéder:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {

Arrays.fill(pass, '0');
}

Un scénario où l'attaquant pourrait l'utiliser est un crashdump - lorsque la JVM se bloque et génère un vidage de la mémoire - vous pourrez voir le mot de passe.

Ce n'est pas nécessairement un attaquant externe malveillant. Il peut s'agir d'un utilisateur du support qui a accès au serveur à des fins de surveillance. Il pouvait jeter un œil dans un crashdump et trouver les mots de passe.

La réponse courte et directe serait parce qu'il char[]est mutable alors que les Stringobjets ne le sont pas.

Stringsen Java sont des objets immuables. C'est pourquoi ils ne peuvent pas être modifiés une fois créés, et donc la seule façon de supprimer leur contenu de la mémoire est de les faire ramasser les ordures. Ce ne sera qu'à ce moment que la mémoire libérée par l'objet pourra être écrasée et que les données auront disparu.

Désormais, le ramasse-miettes en Java ne se produit à aucun intervalle garanti. Le Stringpeut donc persister en mémoire pendant une longue période et si un processus se bloque pendant ce temps, le contenu de la chaîne peut se retrouver dans un vidage de la mémoire ou un journal.

Avec un tableau de caractères , vous pouvez lire le mot de passe, terminer de travailler avec lui dès que vous le pouvez, puis modifier immédiatement le contenu.

La chaîne en java est immuable. Ainsi, chaque fois qu'une chaîne est créée, elle restera en mémoire jusqu'à ce qu'elle soit récupérée. Ainsi, toute personne ayant accès à la mémoire peut lire la valeur de la chaîne.
Si la valeur de la chaîne est modifiée, elle finira par créer une nouvelle chaîne. Ainsi, la valeur d'origine et la valeur modifiée restent en mémoire jusqu'à ce qu'elles soient récupérées.

Avec le tableau de caractères, le contenu du tableau peut être modifié ou effacé une fois l'objectif du mot de passe atteint. Le contenu d'origine du tableau ne sera pas trouvé en mémoire après sa modification et avant même que le garbage collection ne démarre.

En raison de problèmes de sécurité, il est préférable de stocker le mot de passe sous forme de tableau de caractères.

Il est discutable de savoir si vous devez utiliser String ou Char [] à cet effet, car les deux ont leurs avantages et leurs inconvénients. Cela dépend de ce dont l'utilisateur a besoin.

Étant donné que les chaînes en Java sont immuables, chaque fois que certains essaient de manipuler votre chaîne, il crée un nouvel objet et la chaîne existante reste inchangée. Cela pourrait être considéré comme un avantage pour le stockage d'un mot de passe sous forme de chaîne, mais l'objet reste en mémoire même après utilisation. Donc, si quelqu'un a en quelque sorte obtenu l'emplacement de mémoire de l'objet, cette personne peut facilement retrouver votre mot de passe stocké à cet emplacement.

Char [] est modifiable, mais il a l'avantage qu'après son utilisation, le programmeur peut nettoyer explicitement le tableau ou remplacer les valeurs. Ainsi, une fois qu'il est utilisé, il est nettoyé et personne ne peut jamais connaître les informations que vous avez stockées.

Sur la base des circonstances ci-dessus, on peut se faire une idée si aller avec String ou avec Char [] pour leurs besoins.

Chaîne de cas:

    String password = "ill stay in StringPool after Death !!!";
    // some long code goes
    // ...Now I want to remove traces of password
    password = null;
    password = "";
    // above attempts wil change value of password
    // but the actual password can be traced from String pool through memory dump, if not garbage collected

Affaire CHAR ARRAY:

    char[] passArray = {'p','a','s','s','w','o','r','d'};
    // some long code goes
    // ...Now I want to remove traces of password
    for (int i=0; i<passArray.length;i++){
        passArray[i] = 'x';
    }
    // Now you ACTUALLY DESTROYED traces of password form memory