web-dev-qa-db-fra.com

Hachage du mot de passe pour augmenter l'entropie

Est-il sûr de hacher un mot de passe avant de l'utiliser dans une application pour augmenter l'entropie du mot de passe?

Cette pratique augmente-t-elle l'entropie lorsqu'un PBKDF est utilisé dans l'application elle-même ou le PBKDF lui-même augmente-t-il l'entropie du mot de passe?

Si un mot de passe aléatoire est haché avec md5, la sortie fournira-t-elle une entropie de 128 bits?

EDIT: Il est destiné à utiliser le résultat de la fonction de hachage comme mot de passe pour les fonctions cryptographiques et les applications comme AES-256, le courrier électronique et l'accès aux systèmes informatiques.

La procédure utilisée sera mot de passe -> hachage de mot de passe -> application

EDIT 2: Par exemple, si une application de messagerie électronique demande un mot de passe lors de l'inscription, le mot de passe prévu sera haché localement avant de lui être fourni.

passwordshashentropy
14
AXANO

Non, vous n'augmentez pas l'entropie en la hachant une, deux ou dix fois. Considérez l'entropie telle qu'elle semble provenir de l'entrée et non de la sortie. Vous ne pouvez pas ajouter d'entropie à l'aide d'un processus déterministe, car l'entropie du résultat ne compte pas.

Même si vous avez du code comme celui-ci:

$password = "123456";
$result = md5($password) . sha1($password) . hash('gost', $password);
echo $result;  //   e10adc3949ba59abbe56e057f20f
// 8941b84cdecc9c273927ff6d9cca1ae75945990a2cb1f
// 81e5daab52a987f6d788c372

Et vous vous retrouvez avec une chaîne effrayante de 136 octets, le mot de passe est toujours 123456, et tout attaquant utilisant brutalement votre mot de passe haché devra essayer, en moyenne, une seule fois, comme 123456 est le pire des mots de passe sur presque toutes les listes.

Si un mot de passe aléatoire est haché avec md5, la sortie fournira-t-elle une entropie de 128 bits?

Non, MD5 est déterministe, donc si l'attaquant sait que la chaîne est un hachage MD5, son entropie est l'entropie du mot de passe aléatoire que vous avez fourni.

Pour sécuriser le mot de passe, utilisez une dérivation de clé appropriée ( PBKDF2 est une bonne), demandez à l'utilisateur un mot de passe plus long et vérifiez si l'utilisateur suit les règles de base de mot de passe (aucun caractère répété dans une ligne, longueur appropriée, chiffres et caractères mélangés, casse mixte, des choses comme ça).

29
ThoriumBR

Une fonction de dérivation de clé n'augmentera pas l'entropie, mais elle rend les choses plus sécurisées. Un KDF a les fonctions suivantes:

  • Il crée une clé de la bonne longueur. De nombreux algorithmes de chiffrement prennent une longueur de taille fixe, comme 16 octets. En utilisant un KDF, vous pouvez utiliser un mot de passe de n'importe quelle longueur.
  • Il répartit l'entropie du mot de passe sur toute la clé. Les algorithmes de chiffrement sont censés fonctionner avec des clés à l'aspect aléatoire. Si tu utilises 1000000000000000 comme clé, cela peut introduire des problèmes de sécurité dans l'algorithme de chiffrement. Un KDF brouille le mot de passe en une clé au hasard.
  • Ça prend du temps. Pour ralentir les attaques par force brute, la dérivation des clés peut être ralentie de sorte que la tentative de plusieurs mots de passe prenne un temps déraisonnable.
4
Sjoerd

TL; DR

Le hachage d'un mauvais mot de passe avant de l'envoyer à un serveur en tant que mot de passe prend plus de temps, est inconfortable et moins sécurisé qu'un simple gestionnaire de mots de passe.

La question semble viser à abuser d'un algorithme de hachage en tant que gestionnaire de mots de passe très simple.

Utilisez un vrai ou n'importe quel vrai gestionnaire de mots de passe.

Je vais utiliser votre exemple pour montrer pourquoi ce sera une mauvaise idée:

  • Vous avez le mot de passe pas si "riche en entropie" 1111111111111
  • il aura le hachage 9DCBF642C78137F656BA7C24381AC25B

Maintenant, un attaquant obtient en quelque sorte une base de données où les mots de passe sont en texte clair (ce qui arrivait souvent dans le passé). Et pourquoi jamais il y recherchera accidentellement des hachages ayant du texte en clair (le mot de passe pas si "riche en entropie" en est un). Maintenant, il sait que l'utilisateur avec votre nom d'utilisateur/e-mail utilise "1111111111111" puis MD5, comme mot de passe. Quel est alors votre avantage? Un pas de plus que quelqu'un doit faire, mais en termes de sécurité, il n'y a pas de réelle différence.

Voici la différence ce qui pourrait arriver dans le monde réel:

Votre chemin:

ClearText - MD5 -> HashedClearText - envoyé au serveur (HTTP (S)) -> | | - MD5/SHA */... -> HashedHashedClearText

Voie normale:

ClearText - envoyé au serveur (HTTP (S)) -> | | - MD5/SHA */... -> HashedClearText

3
Serverfrog