Une raison de ralentir les mots de passe de hachage générés aléatoirement par notre site?
Le site que je maintiens est en production depuis 3 ans. Lorsque vous vous inscrivez, le site génère pour vous un grand mot de passe hexadécimal aléatoire (20 chiffres). Il est stocké MD5 haché non salé.
Quand j'ai dit au développeur principal que MD5 est mauvais pour les mots de passe, il a dit que si les méchants l'obtiennent, il n'y a aucun moyen de le casser parce que le mot de passe est aléatoire. Et même si le méchant le craque, nous le générons afin que les utilisateurs ne puissent pas le réutiliser sur d'autres sites.
Comment puis-je le convaincre que nous devons utiliser les meilleures pratiques? Il est très têtu ...
Ok, donc le site génère un mot de passe aléatoire pour chaque utilisateur au moment de l'inscription. Une question importante est de savoir si un utilisateur peut définir manuellement son mot de passe ultérieurement, ou s'il est obligé d'utiliser un mot de passe généré par le site au hasard. Examinons les deux cas séparément.
Mots de passe aléatoires
Pour autant que je sache, c'est le scénario que vous décrivez dans la question. Malheureusement, votre développeur a (principalement) raison . Au moins environ une seule itération de hachage vs un gros hachage lent. Votre question a en quelque sorte la saveur d'appliquer aveuglément les "meilleures pratiques" sans considérer à quoi ces pratiques étaient destinées. Pour un exemple brillant de ceci, voici une bonne lecture:
Suggestion
Passez de MD5 à SHA256, ajoutez probablement un sel par utilisateur et envisagez peut-être de passer à 32 mots de passe de caractères. Mais l'ajout d'une grande fonction de hachage lent augmentera la charge de votre serveur pour peu ou pas de sécurité supplémentaire (au moins sauf toute autre gaffe dans votre implémentation).
Comprendre le hachage comme une atténuation par force brute
La quantité de travail qu'un attaquant de force brute qui a volé votre base de données doit faire pour casser les hachages de mot de passe est à peu près:
entropy_of_password * number_of_hash_iterations * slowness_of_hash_function
où entropy_of_password est le nombre de possibilités, ou "devinabilité" du mot de passe. Tant que cette "formule" est supérieure à 128 bits d'entropie (ou facteur de travail équivalent/nombre d'instructions de hachage à exécuter), alors vous êtes bon. Pour les mots de passe choisis par l'utilisateur, le entropy_of_password est extrêmement faible, vous avez donc besoin de beaucoup d'itérations (comme 100 000) d'une fonction de hachage très lente (comme PBKDF2 ou scrypt) pour augmenter le facteur de travail.
Par "20 chiffres hexadécimaux", je suppose que vous voulez dire qu'il y a 1620 = 280 mots de passe possibles, ce qui est inférieur aux "meilleures pratiques" 2128, mais à moins que vous ne soyez un gouvernement ou une banque, vous disposez probablement d'une sécurité par force brute suffisante à partir de l'entropie du mot de passe uniquement.
Les sels ne servent également à rien ici, car le pré-calcul de tous les hachages est comme 280 * 32 bits/hachage, ce qui correspond à environ 1 ZB (ou 5000 x la capacité de tous les disques durs de la planète combinés ). Les tables arc-en-ciel aident un peu cela, mais franchement, tout attaquant capable de le faire mérite de nous pwn tous.
Vous voulez toujours hacher le mot de passe pour empêcher l'attaquant de retirer gratuitement le texte en clair, mais une itération de hachage est suffisante. Passez de MD5 à SHA256 cependant, et pensez peut-être à passer à 32 mots de passe de caractères.
Mots de passe du cerveau humain
Les commentateurs de ce fil semblent obsédés par l'idée que, malgré votre déclaration selon laquelle le site génère des mots de passe, les utilisateurs peuvent en fait choisir leurs propres mots de passe.
Dès que l'utilisateur a la possibilité de changer le mot de passe, une seule itération de hachage n'est pas une option pour stocker le mot de passe désormais à faible entropie. Dans ce cas, vous avez raison, vous devez faire toutes les bonnes pratiques pour le stockage des mots de passe.
Salaison
Dans les deux cas (mots de passe choisis par l'utilisateur ou aléatoires), vous voulez probablement un sel par utilisateur.
Si choisi par l'utilisateur , les sels font partie des meilleures pratiques. dit Nuff.
Si aléatoire , @GordonDavisson souligne une attaque vraiment sympa dans les commentaires [1] , [2] basé sur l'observation qu'une recherche de base de données est essentiellement gratuite par rapport à un calcul de hachage. Calculer un hachage et le comparer avec tous les hachages de tous les utilisateurs est essentiellement le même coût que le comparer avec le hachage d'un utilisateur spécifique. Tant que vous êtes heureux d'entrer dans n'importe quel compte (plutôt que d'essayer de casser un spécifique compte), alors plus il y a d'utilisateurs dans le système, plus efficace l'attaque.
Par exemple, supposons que vous voliez le mot de passe haché non salé db d'un système avec un million de comptes (environ 220). Avec 220 comptes, vous vous attendez statistiquement à obtenir un coup dans les 2 premiers60 suppositions. Vous faites toujours O (280) devine, mais O (260) hachait * O (220) Recherches db ~ = O (260) hacha.
Les sels par utilisateur sont le seul moyen d'empêcher d'attaquer tous les utilisateurs au prix d'attaquer un utilisateur.
Complétant la réponse de Mike Ounsworth , votre développeur est probablement correct, à condition qu'il génère correctement ses nombres aléatoires.
Si vous amorcez votre PRNG qui génère mal ces mots de passe, un attaquant peut déduire l'état de votre PRNG pour prédire les futurs mots de passe. Par exemple, dans un cas pathologique dans lequel vous utilisez un Twister Mersenne avec un état interne non rafraîchi entre les sessions, l'attaque suivante est viable:
- Je demande un grand nombre de comptes en séquence
- Vous générez un nombre d'octets correspondant à partir de votre PRNG et vous les envoyez tous
- J'utilise ces octets pour déduire l'état interne de votre PRNG au moment où vous avez généré mes mots de passe
- J'en déduis l'état interne de votre PRNG au moment où vous avez généré les mots de passe de chaque utilisateur suivant. Chaque futur mot de passe que votre PRNG génère peut être prédit par En outre, le MT peut être exécuté à l'envers pour générer toutes ses sorties précédentes à partir d'un moment connu
- J'ai maintenant calculé chaque mot de passe utilisé par votre système sans avoir accès à votre base de données
Assurez-vous d'utiliser une source aléatoire cryptographiquement sécurisée. La langue intégrée de votre langue PRNG peut ne pas l'être.
De plus, comment vos utilisateurs se souviendront-ils réellement de ces mots de passe? Générer quelque chose de long et d'imprévisible ne fera que faire économiser à vos utilisateurs password.txt sur leur bureau. Si le mot de passe est destiné à être caché dans un fichier de configuration quelque part, vous n'avez probablement aucun problème réel, mais si c'est quelque chose qui est censé vivre dans la tête d'un utilisateur, vous surestimez massivement les capacités de vos utilisateurs, et probablement les obligeant à inventer leurs propres failles de sécurité.
Comme d'autres l'ont dit, inverser le MD5 d'un nombre aléatoire de 80 bits est un problème difficile, donc si quelqu'un a obtenu votre table de hachage, il ne sera probablement pas en mesure d'accéder aux comptes d'utilisateurs.
Cependant, vous voudrez peut-être déterminer où les utilisateurs stockent ces nombres aléatoires de 80 bits. Ça ne va probablement pas être dans leur tête. Dans le meilleur des cas, c'est dans une application de dépôt de trousseau ou de mot de passe raisonnablement sécurisée. Dans le pire des cas, ils auront un fichier avec PASSWORDS_FOR_YER_APP.TXT dans leur répertoire personnel.