MD5 pour les mots de passe

Utiliser md5 salé pour les mots de passe est une mauvaise idée. Pas à cause des faiblesses cryptographiques de MD5, mais parce qu'il est rapide. Cela signifie qu'un attaquant peut essayer milliards de mots de passe candidats par seconde sur un seul GPU.

Ce que vous devez utiliser, ce sont des constructions de hachage délibérément lentes, telles que scrypt, bcrypt et PBKDF2. Le SHA-2 salé simple n'est pas assez bon car, comme la plupart des hachages à usage général, il est rapide. Consultez Comment hacher les mots de passe en toute sécurité? pour plus de détails sur ce que vous devez utiliser.

MD5 pour l'intégrité des fichiers

L'utilisation de MD5 pour l'intégrité des fichiers peut ou non être un problème pratique, en fonction de votre scénario d'utilisation exact.

Les attaques contre MD5 sont des attaques par collision, pas des attaques pré-image. Cela signifie qu'un attaquant peut produire deux fichiers avec le même hachage, s'il a le contrôle sur les deux. Mais il ne peut pas correspondre au hachage d'un fichier existant qu'il n'a pas influencé.

Je ne sais pas si les attaques s'appliquent à votre application, mais personnellement, je commencerais à migrer même si vous le pensez pas. Il est beaucoup trop facile d'oublier quelque chose. Mieux vaut prévenir que guérir.

La meilleure solution dans ce contexte est SHA-2 (SHA-256) pour le moment. Une fois que SHA-3 sera normalisé, ce sera également un bon choix.

Pour compléter la réponse de @CodesInChaos, MD5 est souvent utilisé à cause de la Tradition , et non à cause des performances. Les personnes qui utilisent des bases de données ne sont pas les mêmes que celles qui s'occupent de la sécurité. Ils ne voient souvent aucun problème à utiliser des algorithmes faibles (par exemple, voir la blague d'un algorithme que MySQL utilisait pour hacher les mots de passe). Ils utilisent MD5 parce qu'ils utilisaient autrefois MD5 et sont habitués à utiliser MD5.

Les performances sont beaucoup plus souvent discutées que mesurées; et pourtant, logiquement, il ne peut y avoir de problème de performance s'il n'y a rien à mesurer. En utilisant un cœur d'un processeur de base, vous pouvez hacher plus de 400 Mo par seconde avec MD5, plus près de 300 Mo / s avec SHA-1 et 150 Mo / s avec SHA-256. D'un autre côté, un disque dur décent produira des données à un taux encore plus bas (100 à 120 Mo / s serait typique), de sorte que la fonction de hachage n'est presque jamais le goulot d'étranglement. Par conséquent, il n'y a pas de problème de performances par rapport au hachage dans les bases de données.

Les recommandations habituelles, pour les fonctions de hachage, sont:

1. Ne le faites pas. Vous ne devez pas utiliser d'algorithmes cryptographiques élémentaires, mais des protocoles qui assemblent plusieurs algorithmes afin qu'ils fournissent collectivement certaines fonctionnalités de sécurité (par exemple le transfert de données avec confidentialité et intégrité).

2. Vraiment, ne le faites pas. Pour stocker les mots de passe (plus précisément, les jetons de vérification de mot de passe), ne faites pas un mélange personnalisé d'une fonction de hachage et de sels; utiliser une construction qui a été étudiée spécifiquement pour une telle utilisation. Cela signifie normalement bcrypt ou PBKDF2.

3. Si une fonction de hachage est effectivement ce qui fait le travail, alors utilisez SHA-256. Envisagez d'utiliser toute autre fonction uniquement si un problème sérieux avec SHA-256 (très probablement ses performances ) a été dûment détecté et mesuré.

J'utilise actuellement des hachages salés (hachages salés MD5).

Si vous salez des hachages MD5, vous ne voulez certainement pas utiliser MD5. Il semble que vous deviez utiliser PBKDF2 ou bcrypt.

Pour autant que je sache, cela a toujours été l'algorithme de choix parmi de nombreux DBA.

Ce n'est pas une raison impérieuse.

J'ai travaillé avec beaucoup de DBA qui ont au moins 5 ans de retard dans la technologie générale (n'utilisant pas le contrôle de version, les scripts perl non formatés pour tout, etc.). Ils ont peut-être été des administrateurs de base de données particulièrement mauvais, mais je pense que cela vient avec l'état d'esprit extrêmement conservateur de ne pas changer les choses.

Juste pour compléter les réponses déjà données (dont la plupart sont excellentes), nous avons maintenant un exemple concret où une violation de données (Ashley Madison) conduit à une fuite de la table des mots de passe. Ils ont utilisé bcrypt avec un sel aléatoire pour hacher les mots de passe. Un chercheur en sécurité a décidé de prendre ces hachages et de les forcer brutalement. C'était le résultat

À la suite de tout cela, bcrypt impose des exigences herculéennes à quiconque tente de déchiffrer le dump Ashley Madison pour au moins deux raisons. Premièrement, 4 096 itérations de hachage nécessitent d'énormes quantités de puissance de calcul. Dans le cas de Pierce, bcrypt a limité la vitesse de sa plate-forme de craquage à quatre GPU à 156 suppositions dérisoires par seconde. Deuxièmement, parce que les hachages bcrypt sont salés, sa plate-forme doit deviner le texte brut de chaque hachage un par un, plutôt que tout à l'unisson.

"Oui, c'est vrai, 156 hachages par seconde", a écrit Pierce. "Pour quelqu'un qui a l'habitude de déchiffrer des mots de passe MD5, cela semble assez décevant, mais c'est bcrypt, donc je vais prendre ce que je peux obtenir."

Pierce a abandonné une fois qu'il a passé la barre des 4 000. Pour exécuter les six millions de hachages du pool limité de Pierce contre les mots de passe RockYou, il aurait fallu 19 493 ans, a-t-il estimé. Avec un total de 36 millions de mots de passe hachés dans la décharge d'Ashley Madison, il aurait fallu 116 958 ans pour terminer le travail.

En fin de compte, les seuls qu'il a pu déchiffrer étaient des mots de passe ridiculement simples ou courants (comme "123456").

Oui, MD5 n'est pas sécurisé, tout comme SHA-1, je recommande d'utiliser SHA-256 si la taille du résumé est un problème. N'oubliez pas que si vous le stockez dans une colonne BINARY, il prendra moins d'espace que s'il est stocké dans CHAR. Assurez-vous simplement que cela est fait correctement. MD5 est environ 2,3 fois plus rapide que SHA-256. D'autres benchmarks sont disponibles sur http://www.cryptopp.com/benchmarks.html

Pour faire court, c'est assez peu sûr maintenant à cause des tables arc-en-ciel, Rainbow table est une liste de hachages MD5 et de leurs chaînes correspondantes. Donc, fondamentalement, je considérerais d'autres alternatives telles que SHA1

Vous parlez tous d'insécurité, mais aucun d'entre vous n'a répondu directement à la question.

J'ai travaillé avec MD5 et Sha512, tous deux faciles à craquer une fois que je avait mis mon petit expert en hacker là-dessus, jusqu'à ce qu'il nous frappe tous les deux comme un tonnerre! Le moyen le plus simple et le plus efficace d'arrêter les "Mass Attacks" comme ceux décrits ci-dessus, est de régler un limiteur de tentatives de connexion, ce qui signifie:

  function checkbrute ($ user_id, $ mysqli) {// Obtenir l'horodatage de l'heure actuelle $ now = time (); // Toutes les tentatives de connexion sont comptées à partir des 2 dernières heures. $ valid_attempts = $ maintenant - (2 * 60 * 60); if ($ stmt = $ mysqli->prepare ("SELECT time FROM login_attempts WHERE user_id =? AND time > '$ valid_attempts'")) {$ stmt->bind_param ('i', $ user_id); // Exécute la requête préparée. $ stmt->execute (); $ stmt->store_result (); // S'il y a eu plus de 5 échecs de connexion if ($ stmt->num_rows > 5) {return true; } else {return false; }}}  

Vous obtenez mon point?
Le nombre maximum de combinaisons que le hacker veut essayer, il est limité à 5 échecs toutes les 2 heures. Vous pouvez même bloquer l'utilisateur après X tentatives.