Oui, mais ..

Pour que les choses soient claires et claires ... Nous parlons d'un compromis de base de données uniquement lorsqu'un attaquant a accès à la base de données mais pas au code source de l'application. Dans ce cas, l'attaquant obtiendra les hachages de mot de passe mais ne pourra pas les déchiffrer et obtenir les mots de passe d'origine à cause de l'algorithme personnalisé de Dave. Donc, dans le cas d'une violation de base de données uniquement, oui, l'algorithme de mot de passe de Dave protégera davantage les mots de passe que s'il avait utilisé MD5 ou SHA1.

Cependant Ce n'est qu'une voie possible pour fuites du système. Il y a un fait clé qui détruit les "mathématiques" qui font que l'algorithme homebrew de Dave semble raisonnable.

La moitié de toutes les violations commencent en interne.

(sources 1 2 3) Ce qui est très décevant, une fois que vous l'avez laissé pénétrer. Sur la moitié des violations causées par des employés, la moitié sont accidentelles et la moitié sont intentionnelles . L'algorithme de Dave peut être utile si vous ne vous inquiétez que d'une fuite de base de données. Si c'est tout ce qui vous inquiète, alors le modèle de menace contre lequel vous vous protégez est erroné.

Pour ne choisir qu'un seul exemple, les développeurs ont par définition accès au code source de l'application. Par conséquent, si un développeur obtient un accès en lecture seule à la base de données de production, il dispose désormais de tout ce dont il a besoin pour déchiffrer facilement les mots de passe. L'algorithme personnalisé de Dave est désormais inutile, car il repose sur des hachages anciens et faciles à déchiffrer.

Cependant, si Dave avait utilisé un algorithme de hachage de mot de passe moderne et utilisé à la fois un sel et du poivre, le développeur qui a gagné l'accès à un vidage de base de données uniquement n'aurait absolument rien d'utile.

Ce n'est qu'un exemple aléatoire, mais le point global est simple: il y a beaucoup de fuites de données qui se produisent dans le monde réel où un hachage approprié aurait arrêté les dégâts réels alors que l'algorithme de Dave ne pouvait pas.

En résumé

Tout est question de défense en profondeur. Il est facile de créer une mesure de sécurité qui peut protéger contre un type particulier d'attaque (l'algorithme de Dave est une légère amélioration par rapport à MD5 pour la protection contre les fuites de bases de données uniquement). Cependant, cela ne sécurise pas un système. De nombreuses brèches du monde réel sont assez compliquées, tirant parti des faiblesses à plusieurs points d'un système pour finalement faire de réels dégâts. Toute mesure de sécurité qui commence par l'hypothèse "C'est le seul vecteur d'attaque dont je dois m'inquiéter" (ce que Dave a fait) va se tromper dangereusement.

Cela ne répond pas spécifiquement à la question sur le protocole de Dave, mais je voulais aborder la question plus générale, pour les Daves du monde entier qui écrivent leurs propres hachages. Il y a quelques choses, Daves, que vous devez réaliser:

1. Vous n'êtes pas un cryptographe . Ce n'est pas un reproche contre vous; Je n'en suis pas un non plus. Mais même si vous étiez un cryptographe, il vous faudrait être le meilleur au monde pour être certain que votre algorithme ne présente aucun défaut susceptible de compromettre la sécurité, car même les experts mess up a lot (les quatre mots sont des liens séparés). Entre autres choses, les failles potentielles dans les hachages incluent:
   • Réversibilité accidentelle. Peut-être que vous ne le pensiez pas, mais vous mettez trop d'informations dans le "hachage", et maintenant cela peut être inversé de manière triviale, même sans force brute. Pour un exemple d'algorithme "complexe" qui est néanmoins assez facile à inverser, regardez les générateurs congruentiels linéaires.
   • Pas assez de complexité sur les CPU, GPU, ASIC, etc. C'est étonnamment difficile à faire; il y a une raison pour laquelle il n'y a que trois bibliothèques pour faire le hachage de mot de passe, et elles sont toutes basées sur les mêmes idées. À moins que vous ne soyez intimement familiarisé avec le fonctionnement des GPU et ASIC, vous allez probablement créer quelque chose qui peut être exécuté beaucoup plus rapidement sur les GPU que sur les CPU, annulant instantanément toutes les autres protections dont vous disposez.
   • Trop de complexité là où vous l'exécutez, combiné avec le dernier point. Il est très facile d'indiquer vos tests de performances et de dire: "Écoutez, il me faut 30 secondes pour faire 30 hachages, c'est super!" Sauf que vous n'êtes, encore une fois, pas un cryptographe ou un développeur de GPU, donc vous ne réalisez pas que vos ajouts et multiplications complexes peuvent en fait être répliqués assez facilement sur les GPU, de sorte qu'ils peuvent déchiffrer 30 millions de hachages en 30 secondes, tout en DoSing votre service en essayant de vous connecter plus d'une fois par seconde.
   • Uniformité insuffisante. La sortie d'une fonction de hachage de mot de passe théoriquement parfaite est impossible à distinguer de celle d'un véritable générateur de nombres aléatoires, lorsqu'elle est alimentée en entrée variable. En pratique, nous ne pouvons pas tout à fait y arriver, mais nous pouvons être incroyablement proches. Votre algorithme pourrait ne pas l'être. Et non, «regarder» au hasard ne signifie pas qu'il est en fait assez proche; si vous êtes assez inexpérimenté pour écrire votre propre crypto secret pour une "meilleure" sécurité, vous êtes assez inexpérimenté pour ne pas savoir comment détecter le vrai hasard.
   • Même si vous construisez votre algorithme entièrement hors , des primitives cryptographiques solides, vous pouvez toujours les mal assembler.
2. Vous n'êtes pas un programmeur de cybersécurité . Il y a probablement un meilleur mot pour cela, mais le fait est que vous ne vous êtes pas spécialisé dans l'écriture de code qui implémente correctement des algorithmes, même ceux comme le vôtre. Pour une très liste brève des problèmes possibles qui pourraient être visibles uniquement à partir de la base de données, chacun étant lié au premier résultat Google pour "[item] attack":
   • Analyse de fréquence
   • Texte en clair connu
   • Rémanence des données

Et tout cela est juste de penser exclusivement aux attaques hors ligne sur les bases de données, où la réflexion est menée par un étudiant qui ne se spécialise même pas en cybersécurité . Je vous garantis que j'ai manqué pas mal de choses. J'ai complètement ignoré tous les autres vecteurs d'attaque pour les MITM, les clients malveillants, etc. J'ai également omis de mentionner toutes les erreurs qui pourraient se produire même si vous utilisiez un produit standard; Considérez cela comme un exercice pour le lecteur de comprendre comment vous pourriez utiliser même une bonne crypto-monnaie. Enfin, j'ai complètement omis la classe commune d'erreurs où le développeur utilise le chiffrement là où il devrait utiliser des hachages , que je vois parfois.

Donc, en résumé, Dave, chaque fois que vous pensez avoir la meilleure idée pour un hachage interne secret à utiliser pour votre code de production et il n’est pas d’utiliser un standard, -le produit public, testé de manière approfondie, souvenez-vous de ceci:

Ce n'est pas le cas.

Utilisez simplement bcrypt. (Ou Argon2)

(En passant, si vous construisez simplement un algorithme pour le plaisir et / ou l'auto-apprentissage, n'hésitez pas à ignorer tout cela. votre propre algorithme pour protéger les mots de passe en production est dangereux car vous allez créer un algorithme faible qui offre peu ou pas de protection. Construisez votre propre algorithme pour voir si vous pouvez le casser est un excellent moyen de passer le temps, de stimuler votre esprit et peut-être même d'apprendre un peu de crypto.)

En cas de violation de la base de données et non du code source, Dave pourrait avoir amélioré les choses par rapport à SHA1 simple . Mais ...

1. Le code source est également susceptible d'être divulgué, comme l'explique Conor Mancone.

2. L'homebrew pourrait bousiller le hachage, le rendant encore moins sûr qu'un simple SHA1. Dieu sait comment l'étrange engin de Daves interagit avec les composants internes de l'algorithme de hachage. Si rien d'autre, Dave a créé un petit enfer de maintenance pour ceux qui viennent après lui, et les gros dégâts ne sont jamais bons pour la sécurité.

3. Cela donne un faux sentiment de sécurité. Si Dave n'avait pas été aussi fier de sa brillante solution, il aurait peut-être pris le temps de se renseigner sur la façon de faire correctement le hachage de mot de passe. D'après la question, il est clair que Dave pense que ce qu'il a fait est mieux que de dire bcrypt. Ce n'est pas le cas.

4. La petite protection supplémentaire offerte par l'algorithme homebrew aurait pu être obtenue avec un pepper à la place. C'est mieux qu'un algorithme homebrew de toutes les manières possibles.

Donc oui, un homebrew pourrait être meilleur que SHA1 dans certaines circonstances très spécifiques. Si c'est mieux en moyenne, c'est une question ouverte, mais la réponse n'a pas vraiment d'importance. Le fait est que c'est terrible comparé à un véritable algorithme de hachage de mot de passe, et c'est exactement ce que le brassage à domicile a empêché de mettre en œuvre Dave.

En bref, Dave a foiré ça.

TLDR: La cryptographie non sécurisée n'est même pas sûre si vous ne pouvez pas voir la valeur chiffrée.

Les autres articles sont assez bons pour expliquer de nombreuses raisons pour lesquelles vous ne devrait pas écrire votre propre crypto, dans un environnement où l'attaquant peut voir la valeur chiffrée, mais il manque quelque chose de vraiment important: vous ne devriez pas non plus écrire votre propre crypto lorsque l'attaquant ne peut pas voir le message chiffré.

Il y a cette chose appelée "canal secondaire". Les canaux secondaires sont (généralement ¹ ) des choses involontaires qui fuient des informations sur ce que fait votre application. Par exemple, il faut peut-être plus de cycles CPU - et donc plus de temps - pour comparer un mot de passe partiellement correct à la valeur «chiffrée» ² . Cela permettrait à un attaquant d'accélérer une attaque par force brute pour apprendre lentement le mot de passe correct.

Prenons un exemple naïf. Supposons qu'il faut 1 seconde pour tester un seul caractère du mot de passe soumis par rapport à la valeur stockée dans la base de données. Prétendez que le mot de passe correct comporte 8 caractères et qu'un mot de passe invalide est rejeté au premier résultat incorrect. L'algorithme pourrait ressembler à quelque chose comme:

  boolean encrypt_password (string password) {if (not isascii (password)) {return false; } // ERREUR! résultat de la chaîne; foreach (car c: password) {result + = daves_magic_that_takes_1s (c)} return true;} boolean is_correct_password (input, pw_from_db) {if (input.length! = pw_from_db.length) {return false} foreach (char c_in, c_db: entrée, mot de passe) {c_in = daves_magic_that_takes_1s (c_in) if (c_in! = c_db) {return false}} return true; // mot de passe valide!}  

Maintenant, imaginons que le mot de passe valide est "password" et que l'attaquant essaie l'entrée "a". Cela échoue, car les mots de passe sont de longueur incorrecte. L'attaquant peut essayer au hasard différents mots de passe. Chaque mot de passe incorrect plus long ou plus court que "mot de passe" prend moins d'une seconde à traiter. Disons qu'ils essaieront bientôt "12345678". «12345678» a la même longueur que «mot de passe», le traitement prend donc une seconde. Le timing est différent et l'attaquant le remarque. Ils essaient plusieurs fois de vérifier, et c'est cohérent.

L'attaquant essaie maintenant plusieurs mots de passe à 8 caractères. Ils prennent tous 1 seconde. L'attaquant a découvert un canal secondaire qui leur indique que le mot de passe valide comporte probablement 8 caractères. Maintenant, ils doivent déterminer quel mot de passe à 8 caractères est le bon.

L'attaquant commence à essayer au hasard des mots de passe à 8 caractères. Finalement, ils essaient "p2345678" et remarquent que cela prend 2 secondes. Ils testent un tas et découvrent que toutes les tentatives qui commencent par "p" prennent 2 secondes pour se terminer. L'attaquant devine que l'algorithme a un canal secondaire qui lui indique le nombre de caractères corrects.

Maintenant, au lieu d'avoir à essayer tous les mots de passe 96 ^ 8 pour forcer brutalement le mot de passe valide, l'attaquant n'a plus que pour essayer 96 * 8 mots de passe ³ . En fonction du nombre de mots de passe pouvant être testés en parallèle, ils peuvent probablement forcer brutalement le mot de passe dans un délai très raisonnable. C'est génial pour l'attaquant! Et c'est terrible pour la sécurité de votre système. ⁴

Comment nous protégeons-nous contre les canaux de synchronisation? Nous garantissons que toutes les opérations où le timing entraînerait une fuite d'informations sensibles DOIVENT toujours prendre le même temps à exécuter.

Cela peut ressembler à un exemple très simple. C'est arrivé dans la nature. La recherche dans NVD de «canal côté minutage» vous permettra d'obtenir de nombreuses vulnérabilités du monde réel qui produisent toutes le même type de résultats, permettant à un attaquant d'apprendre des informations secrètes auxquelles il n'est pas autorisé. Par définition, si toutes les opérations prennent le même temps quelle que soit l’entrée, alors le temps que prend quelque chose ne vous dit rien sur l’entrée.

Dans le monde réel, les canaux secondaires sont incroyablement facile à introduire. Dave n'en a probablement même pas entendu parler, et est probablement un bon ingénieur soucieux des performances de son système - qui est en fait un anti-pattern pour se protéger des canaux secondaires. L'algorithme de Dave peut très bien avoir des canaux secondaires à la fois évidents et subtils qu'il ne découvrira jamais, mais que les chercheurs et les attaquants savent rechercher et peuvent assez facilement écrire des tests automatisés pour les détecter. ⁵

Donc, ce n'est pas parce que vous ne pouvez pas voir la crypto que vous ne pouvez pas voir les effets secondaires d'une mauvaise cryptographie, et utilisez ces effets secondaires pour apprendre le secret protégé.

Endnotes

^{1: Eh bien, si vous êtes un agent de renseignement ou un bon journaliste, vous avez probablement mis en place canaux latéraux afin que vous puissiez communiquer avec vos agents / sources sans que «l'ennemi» le sache. De même, si vous êtes sournois, vous pouvez créer un protocole cryptographique avec un canal secondaire dans l'intention de divulguer des informations secrètes.}

^{2: Puisque nous pouvons et devons toujours supposons que la cryptographie personnalisée n'est pas sécurisée (pour les raisons que d'autres ont mentionnées dans ce fil et plus), nous ne devrions probablement pas appeler l'utilisation d'algorithmes de cryptage personnalisés "cryptage" ou "décryptage" ... peut-être "cryptage non sécurisé" ou "décryptage cassé "...}

^{3: J'ignore les attaques par force brute qui réussissent, en moyenne, lorsque l'attaquant a essayé 50% + 1 mots de passe, par souci de simplicité de description. Je me concentre sur les canaux secondaires, pas sur les attaques par force brute. Je passe également sous silence les mathématiques d'une attaque par force brute, car c'est aussi tangentiel au sujet principal; certains Google-Fu au nom du lecteur devraient localiser de nombreuses ressources qui approfondissent les détails.}

^{4: "1 seconde est beaucoup trop lent", non? Aucun système du monde réel ne pourrait être vérifié pour les canaux latéraux de synchronisation du monde réel sur Internet, non? Faux. Je n'ai pas les références sous la main, mais il y a eu des recherches un certain nombre d'années pour montrer que vous pouvez tester statistiquement le timing de l'ordre de quelques millisecondes sur les transactions HTTP.}

^{5 En fait, je serais prêt à parier qu'il existe des frameworks ou des outils existants (probablement les deux) que vous pouvez utiliser pour tester votre application pour des canaux secondaires évidents, si vous deviez utiliser votre Google-Fu. sup>}

Attaques en clair connu / en texte clair choisi

Supposons que vous connaissiez le mot de passe d'un utilisateur particulier, ou mieux encore, que vous puissiez vous inscrire et créer votre propre mot de passe autant de fois que vous le souhaitez.

Et vous avez un accès en lecture à la base de données.

Supposons en outre que vous soupçonnez (ou savez ) qu'il s'agit d'un algorithme homebrew assez simple.

À ce stade, vous pouvez commencer à forcer brutalement l'algorithme et essayer d'obtenir le hachage dans la base de données. Par exemple, vous pourriez "deviner" l'algorithme est

  $ hash = md5 ($ pass. $ Salt. 'Some random string');  

Vous forceriez brutalement la chaîne aléatoire. Cela devient plus difficile à mesure que la chaîne s'allonge, mais vous pourrez peut-être exploiter certaines faiblesses de md5 en choisissant soigneusement les mots de passe. $ hash = sha1 (md5 ($ pass. $ salt. 'abc'). 'def');

puis réessayez le forçage brutal.

Quelque chose comme compliqué car l'algorithme de Dave serait extrêmement difficile sans quelques indices. Si vous saviez qu'une réorganisation des personnages était impliquée, cela aiderait.

J'ai appris beaucoup plus que cette question, en lisant la réponse de @Conor Mancone et en discuté avec @Conor Mancone et @Anders, alors je décide de l'écrire. Corrigez-moi si je me trompe à nouveau.

md5 et sha1 sont cassés, mais pas comme je pense que c'est

Je pensais à tort que la sortie de hachage de md5 et sha1 peut toujours être facilement fissurée (obtenir le texte d'entrée d'origine), quelle que soit la taille de l'entrée .

Non, ce n'est pas .

Si j'utilise un poivre assez long sur le serveur, même si j'utilise md5 ou sha1 pour hacher un mot de passe, il serait toujours sécurisé, étant donné que le serveur n'est pas compromis .

Par exemple: stockez md5 ($ 128bits_long_pepper. $ password) dans la base de données.
Même sans sel, vous ne pouvez pas le casser. Disons que votre vitesse de hachage md5 est de 100 milliards de hachages / s . Prenons cela comme 2 ^ 40 hash / s pour plus de commodité, puisque 2 ^ 40 > 100 milliards . Pour le forcer brutalement, il faut encore 2 ^ 128/2 ^ 40 = 2 ^ 88 secondes = 9,80719764 × 1018 ans . Et bien sûr, je pense que personne ne pré-calculerait une telle table arc-en-ciel.

Mais je ne dis pas que je choisirais md5 pour hacher mon mot de passe. Je ne le ferais pas. Parce qu'une fois que votre serveur est également compromis, ces mots de passe hachés ne diffèrent pas du texte clair.

Je suis un débutant et j'ai lu de nombreux articles très votés parlant de la gravité de md5 et sha1 , mais je ne vois aucune réponse à ce sujet ⬆️ . Je n'en remarque que dans les commentaires.

Fonction sel, poivre, hachage

Enfin, je pense que je comprends parfaitement ces 3 concepts et leurs cas d’utilisation / combinaisons.
Premièrement, je résume 3 types de attaques par moi-même: 1. attaque par force brute (la méthode «tout essayer») 2. attaque de table arc-en-ciel (la recherche inversée directe) 3. attaque par dictionnaire ( $ pepper. $ Common_password. $ Salt force brute, force partiellement brute, par rapport à 1.)

Donc je pense:

1. Salt vise à défendre l'attaque de table arc-en-ciel.
2. Une bonne fonction de hachage (lente) vise à défendre l'attaque par force brute.
3. Pepper vise principalement à défendre les attaques par dictionnaire, étant donné que le serveur n'est pas compromis.

Expliquez avec un exemple:

( Salt ) Il faut se rendre compte qu'un sel n'est pas une très grosse affaire comme beaucoup de gens le décrivent. Il ne défend qu'une chose, à savoir qu'un attaquant ne peut pas simplement effectuer une recherche inversée dans sa table arc-en-ciel pour obtenir votre mot de passe non haché. Si l'on utilise uniquement salt + fonction de hachage rapide (pas de poivre sur le serveur), alors un attaquant peut faire de la force brute pour chaque mot de passe haché. Bien sûr, une autre condition préalable est que vous n'avez pas besoin que votre utilisateur stocke un mot de passe long 128 bits pour l'enregistrement :).

Donc:

• salt + fonction de hachage rapide ne défend pas l'attaque par force brute. Qu'il puisse défendre une attaque de table arc-en-ciel ou une attaque de dictionnaire n'est pas important maintenant.
• salt + fonction de hachage lent défend les attaques par force brute. Il défend également l'attaque de la table arc-en-ciel. Il ne défend pas les attaques par dictionnaire.

( Pepper ) Mais pour la combinaison salt + fast hash , si vous utilisez un pepper assez longtemps sur le serveur, étant donné que votre serveur n'est pas compromis, seule la base de données le fait, le mot de passe sera toujours sécurisé.

Donc:

• sel + fonction de hachage rapide + poivre long (par exemple 128bits) + serveur non compromis peut maintenant défendre une attaque par force brute. Il défend également l'attaque de table arc-en-ciel et l'attaque par dictionnaire.

( fonction de hachage ) Mais une fois que le serveur est compromis, la combinaison ci-dessus est comme une merde. L'attaquant connaîtrait le poivre. La difficulté de cracker sel + fonction de hachage rapide + poivre long (par exemple 128bits) + serveur est compromis est la même que quelqu'un utilise uniquement une fonction de hachage rapide .

Donc:

• sel + fonction de hachage rapide + poivre long (par exemple, 128 bits) + le serveur est compromis ne défend pas l'attaque par force brute. Qu'il puisse défendre une attaque de table arc-en-ciel ou une attaque de dictionnaire n'est pas important maintenant.
• Mais si vous utilisez une fonction de hachage sécurisée / lente, les choses changent.
  sel + fonction de hachage lent + poivre (pas nécessaire pour être très long par exemple 6 caractères peut-être assez bien?) + le serveur est compromis défendre l'attaque par force brute. Il défend également l'attaque de la table arc-en-ciel. Il ne défend pas l'attaque par dictionnaire.

Et la salt + slow hash function , n'est-ce pas suffisant? Cette combinaison défend l'attaque par force brute et l'attaque de table arc-en-ciel. Mais il ne défend pas l'attaque par dictionnaire. Ajouter un poivre sur le serveur est facile, pourquoi pas?

Dites quelque chose pour Dave

Comme vous pouvez le voir ci-dessus, un poivre est juste quelque chose pour lequel vous l'utilisez faire quelques conversions côté serveur.
C'est la "conversion sur le serveur" qui compte vraiment, tant que le serveur n'est pas compromis.
Par exemple, vous prenez une constante aléatoire et la concaténez avec le mot de passe, hash ($ pepper. $ password, $ salt) , c'est un type de conversion. Donc, si vous inventez des algorithmes merdiques sur le serveur comme le fait Dave, vous faites également une conversion. Dans les deux cas, l'attaquant doit compromettre le serveur. Pour le premier, l'attaquant peut simplement saisir votre valeur constante. Pour ce dernier, l'attaquant doit comprendre comment fonctionne votre truc de merde et doit faire un inverse.

Donc mon point est, je pense que l'idée de Dave est tout à fait bonne (faire une conversion sur le serveur), mais il n'est tout simplement pas nécessaire d'ajouter une telle obscurité / complexité. Parce que la maintenance pourrait être comme un enfer si elle ajoute de plus en plus de complexité de cette manière. Une "conversion" comme la concaténation d'un piment sur le serveur est assez loin. Encore une fois, je pense que c'est après tout un problème de compromis. Et l'idée de Dave est juste depuis le début (il veut utiliser une sécurité supplémentaire côté serveur).

Bien qu'il soit utile d'utiliser un algorithme personnalisé "caché", il existe déjà un moyen simple et bien établi de créer des algorithmes de hachage sécurisés personnalisés: Pepper *

Parce que le très bon marché , une option très rapide et très sûre d'utiliser un Pepper existe, les gens qui écrivent à la place un algorithme cryptographique à partir de zéro pour être "plus sûr" sont toujours des novices. Donc non seulement le "protocole de Dave" est une perte de temps et d'argent, mais c'est aussi un protocole (supposé) sécurisé écrit par quelqu'un qui ne connaît pas grand-chose des protocoles sécurisés. Et cela est généralement considéré comme un choix imprudent, quelle que soit la sécurité réelle (ou l'absence de sécurité) dans le protocole de Dave.

* En bref, un poivre est un sel secret qui est le même pour tous les utilisateurs.

Règle générale: Ne faites pas de sécurité à la maison.

Parce que cela va souvent mal. Et la personne qui l'a écrit ne peut pas le tester, si quelqu'un a une mauvaise hypothèse en l'écrivant, il / elle l'a toujours lors du test. Un test indépendant est étonnamment coûteux / prend du temps - bien plus que de l'écrire.

Vous devez également inclure toutes les modifications associées. Savoir "qu'il ne peut pas y avoir de problème, parce que ..." n'est tout simplement pas une approche valable. Pour les mêmes raisons que ci-dessus.

La sécurité des logiciels est un sujet difficile. C'est tellement difficile qu'il est même difficile de comprendre à quel point c'est difficile.