Java, sécurité et les char[]

Cipher

En relisant une énième fois la certification SCJP pour Java 6 je suis resté quelques minutes sur une nouveauté : la classe java.io.Console (qui fait justement son appartition avec Java 6). Un point de sécurité est soulevé dans le livre au sujet de la méthode readPassword qu’il me semble intéressant de sortir de son contexte pour l’étendre.

En effet une particularité des JVM due à leur optimisation consiste lors du déréférencement d’un objet String à garder quelque part en mémoire l’objet, et à ne pas le supprimer même si dans le fond il est éligible au Garbage Collector. La raison étant que ces chaînes de caractères (qui sont souvent plutôt des morceaux de chaînes de caractères) peuvent être réutilisés sans passer par une phase d’allocation/désallocation qui peut à terme s’avérer coûteuse.

Partant de là le livre de la certification explique que pour éviter d’avoir un mot de passe conservé en mémoire à l’insu de l’application, la méthode readPassword renvoie un Array de char (char[]) qui lui sera bien désalloué aussitôt la référence du mot de passe mise à null. Bien que le mot de passe en tant que bits de données reste sûrement encore un peu en mémoire en l’état, au moins aucune référence n’y est faite dans la JVM et on peut espérer qu’il soit écrasé assez rapidement.

Mais pour aller au delà de la méthode readPassword, même si la saisie utilisateur est bien récupérée sous forme de char[], si de l’autre côté le SHA-1 (la signature du mot de passe), par exemple, est récupéré depuis la base de données, toujours pour l’exemple, sous forme de String, alors un programme malveillant est susceptible de chercher en mémoire ce qui y ressemble.
Ce qui est faisable, puisqu’un SHA-1 ressemble à ça :
AFBA34A2A11AB13EEBA5D0A7AA22BBB6120E177B
une séquence alphanumérique de taille constante égale à 40 caractères

L’algorithme a alors beau être un des plus sûr au monde (et c’est le cas de SHA-1), il est possible de confronter la signature à une bibliothèque de signatures connues, comme par exemple celle des mots du dictionnaire. Un mot de passe peu sûr (faisant partie du dictionnaire) sera alors cassé.

Bilan

Il me semble donc important de penser assez systématiquement à un objet char[] pour les données critiques en terme de sécurité.

(une séquence alphanumérique de taille constante égale à 40 caractères). L'algorithme a alors beau être un des plus sûres au monde (et c'est le cas de SHA-1), il est possible de confronter la signature à une bibliothèque de signatures connues, comme par exemple celle des mots du dictionnaire. Un mot de passe peu sûr (faisant partie du dictionnaire) sera alors cassé.

Nombre de vue : 27

COMMENTAIRES 2 commentaires

  1. Thierry A. dit :

    Le problème n’est pas la confidentialité de l’empreinte SHA-1 du mot de passe mais bien l’usage qui en est fait de cet algorithme. Certains recommandent d’utiliser du salage http://en.wikipedia.org/wiki/Salt_(cryptography) Cependant celà n’empêche pas les attaques par dictionnaire http://en.wikipedia.org/wiki/Dictionary_attack et par force brute http://en.wikipedia.org/wiki/Brute-force_attack.
    Il est ainsi recommandé d’utiliser bcrypt http://codahale.com/how-to-safely-store-a-password/ ou PBKDF2 http://en.wikipedia.org/wiki/PBKDF2. Il est préférable d’utiliser bcrypt si c’est possible. Ces deux méthodes ont pour principal effet de rendre lent le processus de hachage. Ansi, la force brute est en pratique inexploitable.

    Pour plus d’information de spécialistes de la sécurité, vous pouvez consulter les pages suivantes :
    http://crypto.stackexchange.com/questions/24/what-makes-a-hash-function-good-for-password-hashing/28#28
    http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage

  2. Thierry A. dit :

    J’ajoute qu’il n’est plus recommandé d’utiliser SHA-1 depuis son cassage en 2005 http://en.wikipedia.org/wiki/SHA-1. Il est préférable d’utiliser SHA-256 http://en.wikipedia.org/wiki/SHA-2. Il est à noter qu’un nouveau standard SHA-3 est en cours de développement et devrait être finalisé en 2012. Les progrès des attaques sur les fonctions SHA-2 nécessiteront alors un passage rapide à une des fonctions SHA-3.

AJOUTER UN COMMENTAIRE