Version imprimable
Bonjour,
Je travaille sur une application Swing qui nécessite une authentification avec login et mot de passe. l'erreur réside dans ce dernier.
Lorsque j'exécute l'application sous Netbeans, l'application marche. Mais lorsque je fais "Clean & Build" pour générer le JAR, voilà l'erreur qui s'affiche :
.Code:warning: [deprecation] getText() in javax.swing.JPasswordField has been deprecated
Merci pour vos renseignements.
Ce n'est pas une erreur, c'est un warning. Tout fonctionne comme il devrait, mais Netbeans t'avertit qu'il vaut mieux pas le faire fonctionner comme ça, ça risque de poser problème.
Comme le dit la JavaDoc, il vaut mieux utiliser getPassword()
Pourquoi : lorsqu'on utilise un JPasswordField, c'est qu'on a pas envie que ce qui est tapé dedans traîne n'importe où pour être récupéré par quelqu'un qui passe par là. Or une String, comme n'importe quel objet, peut exister en mémoire pour un temps imprévisible et y être récupéré assez facilement par un espion quelconque si on lui en laisse le temps. Et getText() renvoie une String.
getPassword() renvoie un char[], qui est aussi un objet et donc un objet qui peut exister en mémoire pour un temps imprévisible... Mais contrairement à une String, il est possible de modifier un char[] pour ne contenir que des zéros une fois qu'on a fini de s'en servir, ce qui protège contre un espionnage s'il se fait après utilisation.
Merci infiniment thelvin.
Mouais, vous pensez vraiment que ca a un intéret de ne pas passer par un String ?
Personnellement, vu que ca implique d'avoir acces au PC cible, ca me semble un peu tordu d'aller se palucher tous les String de la JVM en esperant en trouver un qui contient un mot de passe d'une appli swing desktop (donc pas forcement le plus utilisé pour les appli avec mot de passe interessant à recuperer type appli bancaire). Ce serait quand meme plus simple de mettre un petit hook sur un clavier ou bien de faire des captures d'ecran ou ce genre de chose...
Ceci dit, s'il y a des arguments que je ne vois pas, n'hésitez pas à éclairer ma lanterne...
Ceci dit, j'ai toujours trouvé cette justification assez moyenne, car souvent, on a besoin de faire passer ce password par des moulinettes diverses qui, elles, n'acceptent que des String, comme par exemple de l'authentification LDAP, une requête sur un webservice, etc :aie:
Moi je donne le point de vue de la bibliothèque Java. Personnellement je pense que ça ne sert pas à grand-chose, effectivement parce que le reste du monde ne gère pas les char[], et aussi qu'il y a des manières plus réalistes d'espionner.
Mais dans un contexte de véritable sécurité sensible, si cette méthode n'existait pas, on serait obligé de refaire un JPasswordField pour éviter les String. Ce serait agaçant. Là on est pas obligé. (Mais de là à l'annoncer deprecated... -_-°)
Tout à fait d'accord avec toi, je voulais juste faire remarquer que dans la liste des deprecated java, celui là il est tout en haut de la liste "je m'en bat le roubignolle" quand je reçois un warning. Tu au plus il gagne un @suppresswarning :ptdr:
Pour moi, la seule explication qui peut justifier ca, ce serait qu'il soit possible d'aller fouiller dans la mémoire de la JVM sans avoir acces à la machine qui la fait tourner. C'est possible, ca (ca parait un peu gros mais bon) ?
Parce que si la seule maniere c'est de faire tourner un exe avec droit admin, je vois pas du tout l'interet de blinder ca. Ca revient à mettre des barreaux en acier sur une fenetre alors que la porte est ouverte...
Le principe de la sécurité est que tout est toujours possible, et qu'il faut limiter les dommages lorsque ça arrive, pour ne pas être le maillon le plus faible.
Par exemple, la mémoire peut se retrouver dans un dump qui sera envoyé ailleurs. Si ce dump contient un char[] qui a été rempli de zéros, on s'en fout. S'il contient la String, c'est un maillon faible.
C'est vrai, on pourrait imaginer quelqu'un qui dump la mémoire de la JVM pour l'envoyer à une personne tierce (pour debug par exemple). Et donc, ce serait mauvais d'avoir le mot de passe dedans. M'enfin bon, si c'est le meilleur exemple qu'on arrive à trouver, ca me parait pas etre la faille du siecle :)
Autre exemple concret: la mémoire, après la fin de la JVM, est réallouée à un autre process, comme word, sans être nettoyée (écriture de 0s), l'utilisateur word fait une sauvegarde rapide (dump mémoire => doc) et envoie ce doc à quelqu'un. Les analyses par le passé de ce genre de fichier doc on démontré qu'on y trouvait: des mots de passes, des numéros de carte de crédit, des token d'authentifications, ....
Autre exemple: c'est écrit sur le swap pour une raison X ou Y, 2 heures après le disque dur passe à la trappe (remplacement) et on met le disque dur en vente après avoir effacé la partition principale, mais pas la swap.