Discussion :

[xenos]

Bonjour,

Il semblerait que le hash md5() a été cassé ...

Quel hash me conseilleriez vous ?

De plus comment faire pour permettre une évolution du système ? En effet, ce n'est qu'une question de temps avant que le hash que vous me proposiez ne soit lui même cassé ...

Donc à ce moment là il faudra utiliser un autre système ... mais comme les mots de passe seront hashés, comment les faire évoluer vers une autre plate forme ?

D'avance merci pour vos réponses !

[Mr N.]

Quel est ton besoin ? Pourquoi utilises-tu md5 ?

[xenos]

C'est pour crypter les mots de passe enregistrés dans les tables.

[Mr N.]

Donc le md5 n'est contenu que dans la base. Il faut donc que le vilain ait accès à la base pour se procurer ces md5. Du coup si il a accès à la base, il peut tout faire sans avoir besoin de regarder les mots de passe (qu'ils soient cryptés ou non) : drop database ou pire s'accorder des droits...
Maintenant si il prend un md5 et le casse, il va obtenir le mot de passe d'un utilisateur. Avec un peu de chance il pourra s'en resservir sur un autre site, les gens ayant tendance à ne pas multiplier les mots de passe et garder le meme d'un site à l'autre. Mais bon ça relève plus de la responsabilité de l'utilisateur. Il faut bien comprendre que le risque zero n'existe pas...

[julp]

Ce sujet est largement abordé dans le tutoriel Chiffrement et hash en PHP contre l'attaque Man in the middle.

[xenos]

Ce sujet est largement abordé dans le tutoriel Chiffrement et hash en PHP contre l'attaque Man in the middle.

Justement c'est en ayant lu ce tutoriel que je me permet de poser cette question !

En choisissant l'un des hash proposé par l'auteur, comment par la suite le faire évoluer ... question qui ne trouve malheureusement pas de réponse, il me semble, dans ce tutoriel ...

[julp]

L'évolution n'est pas possible : c'est le principe même du hash (irréversibilité). Le jour où vous souhaitez changer la manière dont ils sont stockés (grain de sel et/ou l'algorithme même - md5 vers shaX) vous devrez changer le mot de passe ou le forcer à tous vos utilisateurs : vous en régénérez des nouveaux aléatoirement que vous envoyez par mail à vos différents utilisateurs (en les invitant à en changer à leur prochaine connexion). Les solutions sont plus que limitées à ce niveau. C'était bien la question au moins ?

[xenos]

Oui, c'était bien ça ...

Dans ce cas ne vaut il mieux pas ne pas mettre de hash si de tout façon d'ici quelques années il sera cassé et qu'on sera alors obligé de le trainer indéfiniment sans moyen d'amélioration ?

[Taum]

Salut,

Dans ce cas ne vaut il mieux pas ne pas mettre de hash

... et laisser les mots de passe en clair dans la base de données ? Je ne suis pas sur que ça soit la meilleure solution ...

D'autre part il faut bien comprendre ce qu'on entends par 'casser'. Pour le MD5, si je me fie à ce que dis Wikipedia :

Le MD5 a été cassé durant l'été 2004 par des chercheurs chinois [...] leur attaque a permis de découvrir une collision complète (ie. deux messages différents qui produisent la même empreinte) sans passer par une méthode de type recherche exhaustive.
L'algorithme développé par les Chinois concerne des collisions quelconques et ne permet pas de réaliser une collision sur une empreinte spécifique (ie. à partir de l'empreinte d'un message, réaliser un autre message qui produit la même empreinte).
On peut désormais générer une infinité de collisions avec un texte T à partir de deux messages M1 et M2 de même longueur qui sont en collision. Il suffit de concaténer M1 et M2 avec T, tel que T1 = M1 + T et T2 = M2 + T, afin d'obtenir une collision complète entre T1 et T2. On ne peut toutefois pas générer une signature particulière et la falsification de documents reste un exercice difficile.

On parle ici de collisions, ce qui ne concerne pas vraiment le stockage de mot de passe.

D'autre part les attaques de type Brute-force ou Rainbow attack peuvent être relativement bien évitées en utilisant un système de grain de sel (salt).


L'évolution n'est cependant pas totalement impossible.
On pourrait par exemple imaginer d'avoir une colonne indiquant le type de hashage du mot de passe. Lorsque l'utilisateur s'identifie, tu auras alors la possibilité de déterminer si il utilise un algo de hashage "obsolète" et mettre alors à jour les données pour utiliser un nouvel algorithme.

Cependant honnêtement, ça me parait très compliqué pour l'intérêt apporté. Tout dépendra vraiment de la sécurité requise par ton système et combien de temps tu peux espérer l'exploiter.

[xenos]

Merci Taum pour ta réponse très pertinente !

C'est exactement ce que je demandais.

Bonne journée à tous, et bon développement !

[bigben99]

et à la limite, si demain ton mdp hashé en sha1 devenait obsolète, tu pourrais t'en sortir en hashant le mot de passe déjà hashé en sha1 que tu as dans ta base.
Dans ce cas, ton utilisateur n'aura même pas à changer de mdp.

hashxxx(sha1(mdp))

et quand l'utilisateur se connecte, tu appliques de nouveau les deux fonctions