Mise à jour

Le fait que vous ayez besoin de poser cette question est la réponse elle-même - vous ne savez pas ce qui ne va pas avec l'empilement de ces primitives, et par conséquent ne pouvez pas connaître les avantages ou des faiblesses.

Faisons une analyse sur chacun des exemples que vous avez donnés:

md5 (md5 (sel) + bcrypt (mot de passe))

Je peux voir quelques problèmes ici. Le premier est que vous êtes en train de faire du sel. Quel avantage cela donne-t-il? Aucun. Cela ajoute de la complexité, et le sel est simplement destiné à être unique pour éviter les collisions de mots de passe et les attaques de pré-calcul (par exemple, table arc-en-ciel). Utiliser MD5 ici n'a aucun sens, et pourrait en fait affaiblir le schéma puisque MD5 a connu des collisions insignifiantes. En tant que tel, il existe une petite possibilité que l'introduction de MD5 ici puisse signifier que deux sels uniques produisent le même hachage MD5, résultant en un sel effectivement dupliqué. C'est mauvais.

Ensuite, vous utilisez bcrypt sur le mot de passe. D'accord. Eh bien, la plupart des implémentations de bcrypt nécessitent un salt en interne, donc cela est déjà techniquement invalide. Disons que vous le savez, et que vous vouliez dire bcrypt (md5 (salt), mot de passe) . Cette partie tombe toujours à la faiblesse que j'ai décrite ci-dessus, mais ce n'est pas trop minable - supprimez le MD5 et c'est une utilisation standard de bcrypt.

Enfin, vous MD5 le tout. Pourquoi fais-tu ça? Quel est le but? Quel avantage cela apporte-t-il? Pour autant que je sache, il n'y a aucun avantage. Au détriment, cela ajoute plus de complexité. Puisque la plupart des implémentations de bcrypt utilisent la notation $ 2a $ rounds $ salt $ hash , vous allez devoir écrire du code pour analyser cela afin de pouvoir extraire la partie de hachage et stocker le reste séparément. Vous allez également avoir besoin d'une implémentation MD5, ce qui n'était pas nécessaire.

Donc, en termes d'empreinte de code pour les vecteurs d'attaque potentiels, vous êtes passé d'une simple implémentation de bcrypt à une implémentation de bcrypt avec un code d'analyse personnalisé et une implémentation MD5, et du code glue pour tout coller. Pour un bénéfice nul, et une vulnérabilité potentielle dans la gestion du sel.

Le suivant:

scrypt (bcrypt (mot de passe + sel))

Celui-ci n'est pas si mal, mais encore une fois, vous avez besoin d'un peu de code pour analyser les résultats de bcrypt en hash et salt / round count séparément. Dans ce cas, je suppose qu'il y a un léger avantage, car bcrypt et scrypt fonctionnent de manière différente pour à peu près le même objectif, ce qui le rendrait un peu plus difficile pour qu'un attaquant extrêmement bien financé crée des ASIC personnalisés pour casser votre plan. Mais est-ce vraiment nécessaire? Allez-vous vraiment vous retrouver dans une situation où un État-nation consacrera quelques millions de dollars simplement pour casser votre hachage? Et, si ce cas se présente, est-ce que cela dérangera vraiment l'attaquant de devoir dépenser quelques millions de plus pour doubler son nombre de puces?

Un autre problème potentiel avec la combinaison de bcrypt et de scrypt de cette manière est qu'il y a eu très peu d'étude sur la façon dont les deux interagissent. En tant que tel, nous ne savons pas s'il existe des cas étranges qui peuvent causer des problèmes. Comme exemple plus évident, prenez le pavé unique. Nous calculons c = m ^ k pour un message m et une clé parfaitement aléatoire également longue k , et nous obtenons une sécurité parfaite. Alors faisons-le deux fois , pour encore plus de sécurité! Cela nous donne c = m ^ k ^ k ... oh, attendez, cela nous donne juste m . Donc, parce que nous n'avons pas pris le temps de bien comprendre comment fonctionnaient les internes du système, nous nous sommes retrouvés avec une véritable vulnérabilité de sécurité. C'est évidemment plus compliqué dans le cas des KDF, mais le même principe s'applique.

Et enfin:

sha1 (md5 (scrypt (mot de passe + md5 (sel))) )

Encore une fois, nous rencontrons le problème du sel de MD5. Je suis également intrigué par MD5 en utilisant le hachage SHA1. Quel avantage cela pourrait-il avoir, si vous utilisez déjà un KDF lent comme scrypt? Les quelques nanosecondes qu'il faudrait pour calculer ces hachages sont pâles par rapport aux centaines de millisecondes qu'il faudrait pour calculer le résumé scrypt du mot de passe. Vous ajoutez de la complexité pour une couche de «sécurité» absolument hors de propos, ce qui est toujours une mauvaise chose. Chaque ligne de code que vous écrivez est une vulnérabilité potentielle.

Maintenant, souvenez-vous de ce que j'ai fait au début de ma réponse. Si, à un moment quelconque de cette réponse, vous pensiez "oh oui, je n'y ai pas pensé", alors mon argument est prouvé.

Vous rencontrez ce que je décrirais comme La fausse maxime de Dave:

Si j'ajoute plus de choses cryptographiques, ce sera plus sécurisé.

C'est un trait commun parmi développeurs, et je l'ai cru une fois aussi. Cela va de pair avec le déni d'autres principes, comme le Principe de Kerckhoff. En fin de compte, vous devez réaliser et accepter que l'obscurité n'est pas un rail de sécurité; c'est une béquille pour une crypto faible. Si votre crypto est forte, elle n'a pas besoin de béquille.

Les primitives cryptographiques peuvent être empilées en toute sécurité et augmenter la sécurité si, et seulement si, vous connaissez suffisamment bien les primitives pour comprendre leurs faiblesses et comment ces faiblesses interagissent. Si vous ne les connaissez pas ou si vous ne comprenez pas les détails, c'est ainsi que vous obtenez le protocole de Dave.

Le problème est que très peu de gens les connaissent tous assez bien pour juger si une certaine combinaison est sûre. C'est pourquoi il faut que ce soit quelque chose qui soit publié et révisé, s'il n'a pas été révisé, vous n'avez aucun moyen de savoir s'il est aussi fort que scrypt ou s'il est plus proche de CRC32.

Donc, si vous n'êtes pas un expert - il est fort possible que vous ayez quelque chose de plus faible que la primitive la plus faible que vous avez utilisée (voir le protocole de Dave) et vous ne le sauriez pas. Ou du moins vous ne le sauriez pas tant qu'il n'est pas fissuré - trouver les mots de passe de vos utilisateurs sur Pastebin n'est pas tout à fait le moyen idéal de déterminer que le schéma est défectueux.

Je suis d'accord qu'un certain degré d'obscurité peut aide d'un point de vue de la défense en profondeur, mais le système sous-jacent doit être sécurisé.

Entre scrypt , bcrypt et PBDKF2 - au moins l'un d'entre eux sera pris en charge sur à peu près toutes les plates-formes. Ceux-ci sont connus et bien testés - ils offrent différents niveaux de protection, mais ils sont toujours beaucoup plus sûrs qu'un empilement bizarre de md5 et sha1 .

Pour votre question spécifique de combiner scrypt et bcrypt, rappelez-vous que ces fonctions ont un coût configurable et que vous voulez augmenter ce coût autant que possible, tout en le maintenant tolérable pour votre utilisation spécifique. Par exemple, si vous pouvez utiliser bcrypt avec jusqu'à X itérations (au-delà de quoi il est trop cher pour votre serveur et votre nombre moyen de connexions utilisateur par seconde), ou scrypt avec jusqu'à Y itérations, alors vous ne pouvez pas utiliser scrypt (bcrypt) avec des itérations X pour bcrypt puis Y itérations pour scrypt: ce sera au-delà votre budget CPU.

Ainsi, si vous cascade scrypt et bcrypt, vous devez utiliser les deux avec moins d'itérations que ce que vous auriez pu faire avec un seul. Vous n'obtenez pas le meilleur des deux mondes en les enchaînant simplement. En fait, le mieux que vous puissiez espérer est une sorte de moyenne entre les deux. Et cela se fait au prix d'un code plus complexe, ce qui est intrinsèquement mauvais quand on parle de sécurité (ou, d'ailleurs, de maintenabilité).

En plus de la réponse d'Adam, j'aimerais également mentionner que chaque fois que vous utilisez la cryptographie, vous devriez avoir une raison forte et inévitable de le faire. Dans vos exemples ci-dessus, cela n'existe pas.

  md5 (md5 (sel) + bcrypt (mot de passe)) scrypt (bcrypt (mot de passe + sel))  

Les algorithmes bcrypt et scrypt sont déjà suffisamment puissants et considérés comme effectivement incassables. Quel problème essayez-vous de résoudre? Et pourquoi pensez-vous que combiner leurs résultats (en particulier avec md5 ) le résoudra? Dans le meilleur des cas, vous avez probablement simplement réduit la difficulté de déchiffrer le mot de passe à celle du hachage le plus faible, plutôt que d'améliorer réellement la sécurité. Et le pire des cas est terriblement indéfini.

  md5 (sha1 (md5 (md5 (mot de passe) + sha1 (mot de passe + sel)) + mot de passe))  

Cette solution est encore pire. Il implémente manuellement un schéma de hachage répété, mais sans suffisamment de tours pour réellement imposer un facteur de travail significatif aux attaquants.

En un mot, le problème est que:

• vous ' re jeter autour de la cryptographie sans réellement avoir un problème à résoudre
• vous avez considérablement augmenté la probabilité d'introduire des failles dans votre implémentation
• vous avez probablement réduit la sécurité au plus faible des algorithmes de hachage, et
• vous avez introduit un scénario du pire des cas inconnu où aucun n’existait auparavant

Si vous appliquez des opérations non sécurisées à un algorithme sécurisé, vous pouvez définitivement interrompre la fonction de hachage. Votre nouvelle fonction pourrait même être bien pire que le lien le plus faible.

Pourquoi les attaquants ne l'utilisent-ils pas pour briser les fonctions sécurisées? Cela ne les aide pas. Par exemple, si j'écrase les 440 premiers bits d'un mot de passe stocké en toute sécurité à l'aide de bcrypt avec des zéros, je peux facilement trouver un mot de passe correspondant par force brute, mais ce mot de passe ne fonctionnera que sur mon propre algorithme terrible. Une implémentation sensée la rejetterait probablement.

La remise à zéro de gros morceaux d'un hachage est clairement mauvaise, mais même des opérations sûres peuvent être combinées en quelque chose de dangereux. Ajouter deux nombres (modulo n pour garantir une longueur constante) est «sûr». En général, aucune entropie n'est perdue. Néanmoins, h (x) + h (x) mod n réduit la qualité du hachage h (x) d’un bit, car le résultat est toujours pair. L'opérateur tout aussi sûr XOR fait encore pire, car h (x) XOR h (x) renvoie toujours zéro.

Ces pièges sont assez évidents, mais ils ne le sont pas tous. Gardez à l'esprit que, comme toujours, il est trivial d'inventer un schéma suffisamment bon pour que vous ne trouviez pas vous-même de faiblesses, mais très difficile d'en inventer un là où personne d'autre ne le peut.

Les fonctions de hachage sont construites par des cryptographes et détruites par des cryptographes. Il existe de nombreuses fonctions de hachage fortes ainsi que des fonctions faibles encore utilisées aujourd'hui. Les programmeurs doivent faire confiance aux cryptographes et à la fonction de hachage. S'il y avait jamais une vulnérabilité dans la fonction de hachage, vous en entendrez sûrement parler sur Internet ou par l'intermédiaire de collègues, puis les cryptographes mèneront sûrement une enquête approfondie. Avec tout algorithme de hachage sécurisé, la seule faiblesse connue peut être une attaque bruteforce.

La combinaison de fonctions de hachage n'ajoute presque aucune sécurité supplémentaire et tout ce que vous voudrez peut-être ajouter est probablement déjà implémenté dans la fonction.

Le salage d'un mot de passe est idéal pour réduire l'efficacité contre les tables arc-en-ciel de sorte qu'un mot de passe ne puisse pas être simplement "recherché". Que vous hachiez une fonction deux fois ou que vous changiez la fonction de hachage, il s'agit essentiellement de saler le mot de passe. Et la plupart des fonctions incluent une méthode simple pour saler, il n'est donc vraiment pas nécessaire de l'implémenter.

Disons que je veux créer mon propre hachage sécurisé parce que tout le monde le fait. Et comme je ne suis pas un cryptographe, j'en aurai besoin "vraiment" sécurisé, car bien sûr, chaque programmeur sait faire un hachage sécurisé au lieu d'utiliser les sécurisés déjà créés. Je crée donc ma fonction de hachage sournoise, mod10 (md5 (sha1 (bcrypt (mot de passe + sel)))).

Comme vous pouvez le voir dans ma fonction de hachage, elle est vraiment sécurisée car j'utilise tellement de différents des choses dedans. Bien sûr, dans cet exemple stupide, il est facile de voir qu'il n'y aura que 10 sorties différentes possibles. Mais en utilisant simplement une seule fonction de hachage sécurisée, cela aurait complètement évité cela.

Bien sûr, votre système devrait être sécurisé si l'attaquant a le code source, mais il est très probable que votre l'attaquant n'aura pas accès à votre code source et ne pourra probablement pas deviner votre hachage farfelu, rendant toute tentative de force brute impossible

Nous supposons donc qu'un attaquant s'est emparé de la table de base de données qui contient les hachages. Je suppose qu'il est très probable qu'un attaquant puisse également obtenir les fichiers de la page Web. Vos systèmes exécutant ces services sont peut-être le même exploit qui a permis à votre base de données d'être prise. Un serveur de base de données est configuré pour que le public ne puisse pas y accéder directement. En revanche, votre serveur web contenant votre code, est en première ligne.

Chaque fois que vous augmentez la complexité d'un algorithme ou même ajoutez plus de lignes de code, vous augmentez les points de défaillance de votre application. La combinaison d'algorithmes peut avoir des conséquences inattendues. Cela peut conduire à certains tell ou autres signes qui peuvent en fait affaiblir la force cryptographique du système.

Plus vous utilisez de bibliothèques dans votre application, plus le risque pour votre application en général est grand. Si une faille est trouvée dans une implémentation qui permet une faiblesse, l'exécution de code, etc. alors votre application est vulnérable. Si par hasard vous avez choisi un autre algorithme qui n'a pas été attaqué, votre coffre-fort pour le moment (bien sûr, vous pourriez aussi être du côté malchanceux de la chance).

N'oubliez pas KISS : restez simple, stupide, sinon vous risquez de vous perdre dans la complexité.

Je ne suis pas d'accord avec tout un tas de gens qui sont plus intelligents que moi et plus expérimentés en sécurité que moi. Donc je me trompe probablement.

Improviser votre propre fonction de hachage est une bonne idée - si vous le faites correctement. Suivez ces 3 étapes simples.

1. Identifiez une faiblesse ou une faille dans les fonctions de hachage existantes.
2. Improvisez votre propre fonction de hachage qui n'a pas cette faille.
3. Vérifiez que votre fonction de hachage improvisée possède toutes les forces des fonctions de hachage existantes.

Après avoir terminé l'étape 3, vous seriez un idiot de ne pas utiliser votre fonction de hachage improvisée.

Lors de la concaténation de différentes fonctions de hachage parce que vous vous inquiétez de celle, il est vital que vous appliquiez le sel avant d'appliquer le prochain algorithme de hachage, alors toute faiblesse de collision dans l'un des algorithmes ne corrompra pas la deuxième fonction de hachage que vous en utilisant:

scrypt (bcrypt (mot de passe + sel) + sel)

Mais je pense que scrypt est une technique établie maintenant, Argon 2i a remporté le concours de hachage de mot de passe et est censé être plus sécurisé et bcrypt existe depuis longtemps et s'est avéré sécurisé contre les contournements triviaux.

Par conséquent, ce qui suit aurait plus de sens, et combinerait la force de l'argon 2i, mais reviendrait à bcrypt si un futur attaquant montrait comment casser trivialement argon 2i, ce qui est actuellement considéré comme difficile:

bcrypt (Argon2i (mot de passe + sel) + sel)

Mais vous êtes moins probable faire une erreur si vous faites simplement:

scrypt (mot de passe + sel) Orbcrypt (mot de passe + sel)

Rappelez-vous, la plupart des violations sont dues à une erreur humaine r dans le code, il est préférable de rester simple et de revoir en profondeur votre code avec une analyse dynamique et statique et des réviseurs de code humains, pour vous assurer qu'aucune attaque par injection SQL ne passe (n'oubliez pas de toujours paramétrer vos requêtes de base de données!)

J'ai beaucoup appris avec ce fil, j'ai donc pensé de manière à comprendre facilement le résultat possible en combinant différentes méthodes (bien sûr, cela ne conviendra pas à tous les cas):

[W = faible, S = fort]:

  Formule | Exemple --------------- | ----------------- W (W) = W | md5 (sha1 (pwd)) W (S) = W | md5 (bcrypt (pwd)) S (W) = W | bcrypt (md5 (pwd)) S (S) = S- | bcrypt (scrypt (pwd)) // leur interaction est inconnue W + S = W | md5 (pwd) + brcypt (pwd) S + S = W | bcrypt (pwd) + scrypt (pwd) W '+ S "= S | md5 (pwd1) + brcypt (pwd2) // pwd1! = pwd2S' + S" = 2S | bcrypt (pwd1) + scrypt (pwd2) // pwd1! = pwd2SUBSTR (W) = W | substr (md5 (pwd), n); // Plus court la chaîne, le plus faibleSUBSTR (S) = S- | substr (bcrypt (pwd), n); // Plus la chaîne est courte, plus la chaîne est faible S + x = S + | bcrypt (pwd) + x // x = Variable str. sans rapport avec pwdS (S + x) = S- | bcrypt (scrypt (pwd) + x) // x = Variable str. sans rapport avec pwdROT13 (S) = S | ROT13 (bcrypt (pwd)) 

Ce que je veux réaliser ici est de montrer d'une manière simple que ces combinaisons n'ajouteront pas de sécurité supplémentaire dans la plupart des cas (donc la complexité supplémentaire est pas digne).