Quand est-il dangereux de hacher

Une fonction de hachage cryptographique fiable convertit le texte en clair en texte d'une longueur donnée. Cela garantit la «persistance»: la difficulté de restaurer les premier et deuxième prototypes. Ou, en langage clair sur la première propriété, la difficulté d'obtenir un tel texte, dont la valeur de la fonction de hachage sera égale à celle spécifiée.

La complexité de la récupération est comprise comme le fait que pour trouver le premier prototype [une fonction de hachage cryptographique fiable], il est nécessaire de remplir une moyenne d'au moins $$$2 ^ {n-1}$opérations de hachage où $$$n$- le nombre de bits dans la sortie de la fonction de hachage cryptographique. Prenant une fonction de hachage moderne avec une grande taille de sortie (à partir de 256 bits), le développeur du système d'information est sûr qu'il est impossible de restaurer les données d'origine à partir de la valeur de la fonction de hachage. Le plus souvent, il a raison.

Mais il existe un ensemble important de cas où, malgré la fiabilité de la fonction de hachage, la restauration de l'image inverse ou même du texte source n'est pas un problème. C'est le cas lorsque l'utilisation d'une fonction de hachage est inutile. C'est le cas lorsque le nombre de variantes du texte source est consultable .

Exemple: numéro de téléphone . Différents numéros de téléphone avec le préfixe "+7" et 10 chiffres sont $$ . Les appareils modernes optimisés pour itérer sur les valeurs de hachage trient des millions de hachages par seconde. Cela signifie que le calcul des valeurs des fonctions de hachage pour tous les numéros de téléphone possibles avec un préfixe ne dépasse pas quelques secondes.

Exemple: numéro de carte de crédit (PAN, numéro de carte de paiement ). Souvent, le numéro de carte est masqué, révélant les 4 (6) premiers et / ou les 4 derniers chiffres, tout en cachant le reste. La carte comporte 16 chiffres. Est-il possible de hacher les numéros de carte afin de les cacher à l'attaquant? Non. Si un attaquant a reçu 8 chiffres de 16 (les 4 premiers et les 4 derniers), ainsi que la valeur de la fonction de hachage à partir du numéro de carte complet, il peut récupérer le numéro complet en moins d'une seconde. Pour ce faire, il devra tout trier $$ options de nombre.

Un exemple intéressant avec une adresse e-mail . Il semblerait que par la valeur d'une fonction de hachage fiable, il soit impossible de restaurer l'adresse d'origine. Le nombre de variantes différentes de 8 lettres latines et 10 chiffres donne déjà $$ options pour les noms des boîtes aux lettres sans tenir compte des différents domaines des services de messagerie ( @mail.ru , @gmail.com , etc.). Si vous prenez d'autres caractères autorisés, ainsi que l'allongement de l'adresse, il y a encore plus d'options. Mais ... Jusqu'en 2006, le projet Blue Frog (Blue Frog) fonctionnait, qui offrait à ses utilisateurs une protection anti-spam. Il a utilisé la notification automatique des fournisseurs au sujet du spam envoyé depuis leurs serveurs, ce qui a obligé les annonceurs à refuser d'envoyer du spam à au moins les adresses qui participaient au projet. Pour comprendre si la boîte appartient au participant ou non, un fichier a été distribué avec une liste de valeurs de la fonction de hachage cryptographique à partir de l'adresse de boîte aux lettres de chaque membre.

On a supposé que les spammeurs vérifieraient chacune de leurs adresses pour envoyer des publicités sur cette liste et exclure les correspondances trouvées. Cependant, la présence d'un fichier avec les valeurs de la fonction de hachage a permis aux attaquants de faire exactement le contraire: identifier les participants au projet et leur envoyer des flux renforcés de messages dénués de sens afin de refuser d'utiliser le projet Blue Frog. Quelque temps après cette attaque (ainsi que d'autres, y compris les attaques DDoS sur les serveurs), le projet a arrêté son travail.

Comme précédemment, l'utilisation de tout sel fourni avec la valeur de la fonction de hachage n'affecte pas le temps d'énumération (mais protège toujours contre les attaques par dictionnaire).

Solutions possibles pour les cas décrits.

1. Hachage non pas les valeurs elles-mêmes, mais la concaténation de la valeur d'origine et de certains secrets stockés séparément. Par exemple, pas dans la table de base de données (avec les valeurs des fonctions de hachage), mais dans la configuration du serveur d'applications. Avec un succès similaire, au lieu de hacher, vous pouvez utiliser la fonction de cryptage de bloc sur une clé secrète.
2. Utilisez des fonctions de hachage non seulement fiables, mais également lentes en informatique. Tant pour le cryptanalyste que pour l'utilisateur légal. Un exemple de telles fonctions est PBKDF2, bcrypt, scrypt, Argon2, pour lequel, lors de l'appel d'une fonction, nous indiquons en outre le nombre d'itérations de hachage. Cependant, si l'augmentation de la longueur de la sortie de la fonction de hachage d'un seul bit (sur 256 ou 512) augmente la complexité de l'attaque du cryptanalyste par un ordre binaire (par un facteur de deux), l'augmentation du nombre d'itérations pour la fonction de hachage PBKDF2 doublera la complexité des attaques par seulement deux. fois. Autrement dit, l'obtention d'une valeur de hachage même par un utilisateur légal devient coûteuse en termes de ressources informatiques et d'énergie dépensée.