Pourquoi est-char[] préféré sur Chaîne de caractères pour les mots de passe?

Question

En Swing, le champ mot de passe a un getPassword() (retours char[]) méthode au lieu de l'habituel getText() (retours String) de la méthode. De même, je suis tombée sur une suggestion de ne pas utiliser Strings pour gérer les mots de passe. Pourquoi est - String constituent une menace pour la sécurité quand il s'agit de mots de passe?

Il se sent inconfortable à utiliser char[].

Answer 1

Les chaînes sont immuables. Cela signifie que lorsque vous avez créé la chaîne, si un autre processus de vidage de mémoire, il n'y a aucun moyen (à part de la réflexion), vous pouvez vous débarrasser de ces données avant GC coups de pied dans.

Avec un tableau, vous pouvez explicitement effacer les données après que vous avez terminé avec lui: vous pouvez remplacer le tableau avec ce que vous voulez, et le mot de passe ne sera pas présente dans le système, même avant la collecte des ordures.

Donc oui, c' est un problème de sécurité - mais même en utilisant char[] seulement réduit la fenêtre d'opportunité pour un attaquant, et c'est seulement pour ce type d'attaque.

EDIT: Comme indiqué dans les commentaires, il est possible que les piles soient déplacés par le garbage collector de laisser vaguer les copies des données dans la mémoire. Je crois que c'est spécifique à l'implémentation - le GC peut effacer la mémoire comme il va, pour éviter ce genre de chose. Même si elle le fait, il y a encore le temps pendant lequel l' char[] contient les caractères comme une attaque de la fenêtre.

Answer 2

Alors que d'autres suggestions ici semblent valides, il y a une autre bonne raison. Avec la plaine String vous avez beaucoup plus de chances de accidentellement l'impression que le mot de passe de journaux, d'écrans ou de certains autres insécurité. char[] moins vulnérable.

Réfléchissez à ceci:

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

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

Impressions:

String: Password
Array: [C@5829428e

Answer 3

Pour citer un document officiel, le Java Cryptography Architecture guide dit ceci à propos de char[] vs String des mots de passe (à propos de chiffrement par mot de passe, mais c'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: Objects de type String sont immuables, c'est à dire, il n'y a pas de méthodes définies que vous permettent de modifier (écraser) ou remettez à zéro le contenu d'un String après l'utilisation. Cette fonctionnalité permet de s' String objets impropres à le stockage de la sécurité des informations sensibles comme les mots de passe utilisateur. Vous devraient toujours de recueillir et de stocker de la sécurité de l'information sensible dans une char tableau à la place.

Directive 2-2 de l'Sûr des Directives de Codage pour le Langage de Programmation Java, la Version 4.0 a également dit quelque chose de semblable (bien qu'il soit à l'origine dans le contexte de l'exploitation forestière):

Directive 2-2: Ne pas enregistrer des informations hautement sensibles

Certaines informations, telles que les numéros de Sécurité Sociale (SSNs) et les mots de passe, est très sensible. Ces informations ne doivent pas être conservés pour plus longtemps que nécessaire, ni où il peut être vu, même par les administrateurs. Par exemple, il ne doit pas être envoyé à des fichiers journaux et sa présence ne doit pas être détectable par les recherches. Certains transitoire les données peuvent être conservées dans mutable structures de données, telles que des tableaux de char, et effacées immédiatement après l'utilisation. La compensation des structures de données a réduit efficacité typique d'exécution Java systèmes comme les objets sont déplacés dans mémoire de manière transparente pour le programmeur.

Cette directive a également des implications pour la mise en œuvre et l'utilisation de niveau inférieur bibliothèques qui n'ont pas de sémantique de la connaissance des données ils sont traiter avec. Comme un exemple, un faible niveau d'analyse de chaînes la bibliothèque peut enregistrer le texte. Une application peut analyser un SSN avec la bibliothèque. Cela crée une situation où les SSNs sont disponible pour les administrateurs, avec l'accès aux fichiers journaux.

Answer 4

Des tableaux de caractères (char[]) peut être effacé après l'utilisation par le réglage de chaque personnage à zéro et les Chaînes non. Si quelqu'un peut en quelque sorte voir l'image mémoire, ils peuvent voir un mot de passe en texte clair si les Chaînes de caractères sont utilisés, mais s' char[] est utilisé, après la purge de données avec des 0, le mot de passe est sécurisé.

Answer 5

Certaines personnes croient 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 d'un attaquant de lire le mot de passe de votre système et ignore complètement le fait que l'attaquant a déjà besoin de suffisamment accès à détourner la mémoire JVM pour ce faire. Un attaquant avec beaucoup d'accès peut attraper votre clé d'événements qui font cela complètement inutile (autant que je sache, donc s'il vous plaît corrigez-moi si je me trompe).

Mise à jour

Merci pour les commentaires que j'ai pour mettre à jour ma réponse. Apparemment il y a deux cas où cela peut ajouter une (très) légères amélioration de la sécurité, car elle réduit le temps d'un mot de passe pourrait atterrir sur le disque dur. Pourtant, je pense que c'est trop pour la plupart des cas d'utilisation.

• Votre système cible peut être mal configuré, ou vous devez supposer qu'il est et vous devez être paranoïaque à propos de core dumps (peut être valable que si les systèmes ne sont pas gérés par un administrateur).
• Votre logiciel doit être trop paranoïaque pour empêcher les fuites de données avec l'attaquant d'obtenir l'accès au matériel (des choses comme TrueCrypt).

Si possible, la désactivation de la core dumps et le fichier d'échange serait de prendre soin de problèmes. Cependant, ils nécessitent des droits d'administrateur et peut réduire la fonctionnalité (moins de mémoire d'utilisation) et en tirant la RAM à partir d'un système en cours d'exécution serait toujours une préoccupation valable.