bilbonsacquet a écrit :



C’est sûr, sauf le jour où le SHA n’est plus valable car on aura trouvé comment le mettre en défaut.



Cela engendre aussi de devoir régulièrement changer la façon dont les hash sont générés en permettant la conversion sans devoir réinitialiser le mot de passe en question.







Tu n’as pas l’air de savoir de quoi tu parles.



“SHA” ne désigne plus un protocole mais une famille de protocoles aujourd’hui.



Mais surtout, on est loin, très loin, de devoir changer régulièrement de fonction de hachage. SHA-1, introduit en 1995, ne souffre que d’attaques (trouver des collisions, cf mon précédent message) encore assez théoriques (pas franchement applicables en pratique) 20 ans après. À cause de ces vulnérabilités cependant, il est conseillé de ne plus l’utiliser.

La sous-famille des SHA-2, introduite en 2001, ne connaît à l’heure actuelle aucune réelle attaque. Cependant, comme elle se base sur SHA-1, on craint qu’il y ait des vulnérabilités sous-jacentes, d’où la création de SHA-3, basée sur un schéma différent.



Bref, la durée de vie d’une fonction de hachage dépasse allègrement les 10 ans, au bas mot…

Alors la gestion d’un changement de fonction de hachage, honnêtement, c’est le cadet des soucis en sécurité " />

bilbonsacquet a écrit :



Le problème c’est que ça ne suffit pas… Car même des mots de passe chiffrés peuvent être déchiffrés, suffit de la puissance de calcul nécessaire.







C’est plutôt faux. En fait une société un tant soit peu responsable ne va pas stocker les mots de passe chiffrés, mais les hashs de mots de passe. Le principe d’une fonction de hachage est d’associer à une chaîne de bits une autre chaîne de bits, de façon déterministe (c’est une fonction), mais qui paraisse aléatoire : impossible à partir de h(x) de connaître x. En gros. Pour authentifier l’utilisateur, lorsque celui-ci entre un mot de passe x’, le système calcule h(x’) et compare avec le hash stocké sur ses serveurs : s’ils correspondent, c’est tout bon ; sinon l’authentification échoue.



C’est pour ça qu’une bonne fonction de hachage doit pouvoir résister aux collisions, càd que personne ne doit être en mesure d’exhiber x et y distincts tels que h(x) = h(y). Un adversaire ne doit pouvoir être authentifié que s’il entre effectivement le bon mot de passe, et pas un autre.

Stocker simplement le hash est encore une mesure trop faible, sensible aux attaques par dictionnaire (l’adversaire se crée une grande base de données de la forme (x, h(x)). Lorsqu’il chope un hash h sur le serveur, il cherche dans sa base s’il n’avait pas calculé un x tel que h = h(x) ; auquel cas l’adversaire a retrouvé le mdp). Des techniques de salage permettent de contrer ce type d’attaques.



Ces mesures sont connues depuis longtemps et pourtant certaines entreprises ne les mettent pas en place, alors qu’il ne me semble pas que ce soit particulièrement difficile… un bon exemple était Orange, qui il y a un an à peine, lorsque je le testais en prétendant oublier mon mdp, me renvoyait… mon mot de passe. C’est donc bien qu’il était stocké en clair sur leurs serveurs… et avec les news récentes je me demande s’ils ont changé ça depuis.



Cependant, les techniques de salage permettent surtout de contrer des attaques “pêche au filet” ; il reste toujours possible pour l’adversaire d’effectuer des attaques ciblées, et donc il sera toujours conseillé de changer son mot de passe en cas de fuite.



Un autre problème est que si l’adversaire parvient à s’installer sur le serveur cible, il pet sûrement avoir accès aux mots de passe en clair de tout utilisateur qui souhaite se connecter. Même en supposant que l’entreprise chiffre (un protocole à clé publique me semble le plus simple même si je ne sais pas si cela est viable en pratique en termes de complexité) les mots de passe lorsque ceux ci transitent depuis le terminal utilisateur jusqu’à ses serveurs, il faut bien le déchiffrer à un moment ou à un autre.