Le «protocole de Dave» n'est-il pas bon si seulement la base de données, et non le code, est divulguée?
J'ai lu "La sécurité du mot de passe de mon développeur est-elle correcte ou incorrecte, et pourquoi?" , mais il y a encore une question dans mon esprit:
Même si quelqu'un utilise un mauvais algorithme de sécurité artisanal comme Dave, un attaquant ne peut pas obtenir le vrai mot de passe si l'attaquant ne fait que compromettre la base de données, pas le serveur. réponse de Mark Burnett à la question de Dave semble prouver ma supposition.
Encore une fois, prenez le code de Dave comme exemple. Dave utilise des fonctions de hachage non sécurisées/rapides, md5 et sha1, donc oui, vous pouvez facilement casser son mot de passe (obtenir le texte brut) de la base de données. Mais vous ne pouvez toujours pas obtenir le vrai mot de passe si son serveur n'est pas compromis.
Oui mais..
Pour le rendre agréable et clair ... 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 en raison de l'algorithme personnalisé de Dave. Donc, dans le cas d'une violation de la 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 avenue possible pour les fuites du système. Il y a un fait clé qui supprime les "mathématiques" qui font que l'algorithme homebrew de Dave semble raisonnable.
La moitié de toutes les infractions commencent en interne.
(sources 12 ) Ce qui est très inquiétant, une fois que vous l'avez laissé entrer. De la moitié des infractions causées par les employés, la moitié d'entre elles sont accidentelles et la moitié sont intentionnelles . L'algorithme de Dave peut être utile si tout ce qui vous inquiète est une fuite de base de données uniquement. Si c'est tout ce qui vous inquiète, le modèle de menace contre lequel vous vous protégez est faux.
Pour ne prendre qu'un 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 à casser.
Cependant, si Dave avait utilisé un algorithme de hachage de mot de passe moderne et utilisé à la fois du sel et du poivre, le développeur qui aurait eu accès à un vidage de base de données 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 dommages réels lorsque l'algorithme de Dave ne pouvait pas.
En résumé
Il s'agit 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 base 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, profitant des faiblesses à plusieurs points dans un système pour finalement faire des dégâts réels. Toute mesure de sécurité qui commence par l'hypothèse "C'est le seul vecteur d'attaque dont je dois m'inquiéter" (c'est 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 répondre à 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:
- Vous n'êtes pas un cryptographe . Ce n'est pas un peu contre vous; Moi non plus. Mais même si vous étiez un cryptographe, vous devez être le meilleur au monde pour être certain que votre algorithme n'a aucun défaut qui pourrait compromettre la sécurité, car même les experts messpalot (les quatre mots sont des liens séparés). Entre autres choses, les défauts potentiels dans les hachages comprennent:
- Réversibilité accidentelle. Peut-être que vous ne le pensiez pas, mais vous mettez trop d'informations dans le "hachage", et maintenant elles peuvent être trivialement inversées, même sans force brute. Pour un exemple d'algorithme "complexe" qui est néanmoins assez facile à inverser, regardez les générateurs linéaires congruentiels.
- Pas assez de complexité sur les CPU, GPU, ASIC, etc. Ceci est étonnamment difficile à faire; il y a une raison pour laquelle il n'y a, par exemple, que trois bibliothèques pour faire du hachage de mot de passe, et elles sont toutes basées sur les mêmes idées. À moins que vous ne soyez intimement familier avec le fonctionnement des GPU et des ASIC, vous allez très 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 complexité où vous l'exécutez réellement, combiné avec le dernier point. Il est très facile de pointer vers vos tests de performances et de dire: "Écoutez, cela me prend 30 secondes pour faire 30 hachages, c'est génial! Sauf que vous n'êtes, encore une fois, pas un cryptographe ou un développeur de GPU, vous ne réalisez donc pas que vos ajouts et multiplications complexes peuvent en fait être répliqués assez facilement sur les GPU, de sorte qu'ils peuvent casser 30 millions de hachages en 30 secondes, tout en faisant 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 d'un vrai générateur de nombres aléatoires, lorsqu'elle est alimentée en entrée variable. En pratique, nous ne pouvons pas vraiment y arriver, mais nous pouvons obtenir incroyablement fermer. 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 à partir de bonnes primitives de chiffrement solides, vous pouvez toujours les assembler incorrectement.
- Vous n'êtes pas un programmeur en 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 les algorithmes, même les vôtres. Pour une très brève liste 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":
Et tout cela est juste penser exclusivement aux attaques hors ligne sur les bases de données, où la réflexion est faite par un étudiant qui ne se spécialise même pas en cybersécurité. Je vous garantis que j'ai raté 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 que c'est un exercice pour le lecteur de comprendre comment vous pourriez mal utiliser même une bonne crypto. Enfin, j'ai entièrement omis la classe d'erreurs courante où le développeur utilise cryptage où il devrait utiliser hashes, que je vois occasionnellement.
Donc, en somme, Dave, chaque fois que vous pensez avoir la meilleure idée d'un hachage interne secret à utiliser pour votre code de production et qu'il n'est pas pour utiliser un standard, off- produit public, testé à fond, souvenez-vous de ceci:
Non.
Utilisez simplement bcrypt. (Ou Argon2 )
(En remarque, si vous construisez simplement un algorithme pour le plaisir et/ou l'auto-éducation, n'hésitez pas à ignorer tout cela. Construire votre propre algorithme pour protéger les mots de passe en production est dangereux car vous allez construire un algorithme faible qui offre peu ou pas de protection. Construire 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 de la crypto.)
Dans le cas d'une violation de la base de données et non du code source, Dave aurait amélioré les choses par rapport à SHA1 simple . Mais...
Le code source risque également de fuir, comme explique Conor Mancone .
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 éléments internes de l'algorithme de hachage. Si rien d'autre, Dave a créé un petit enfer de maintenance pour ceux qui le suivent, et les gros dégâts ne sont jamais bons pour la sécurité.
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 lire comment 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.
La petite protection supplémentaire donnée par l'algorithme homebrew aurait pu être obtenue avec un poivre à la place. C'est mieux qu'un algorithme homebrew de toutes les manières possibles.
Alors 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 qu'il est terrible par rapport à un véritable algorithme de hachage de mot de passe, et c'est exactement ce que le brassage à domicile a empêché Dave de mettre en œuvre.
Pour faire court, 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 cryptée.
Les autres articles expliquent assez bien les raisons pour lesquelles vous ne devriez pas écrire votre propre crypto, dans un environnement où l'attaquant peut voir la valeur crypté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 crypté.
Il y a ce qu'on appelle un "canal latéral". Les canaux latéraux sont (généralement1) des choses imprévues 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 avec le "crypté"2 valeur. 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. Imaginons 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. Imaginez 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; } // ERROR!
string result;
foreach(char 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 : input, password) {
c_in = daves_magic_that_takes_1s(c_in)
if(c_in != c_db){ return false}
}
return true; // valid password!
}
Imaginons maintenant que le mot de passe valide soit "mot de passe" et que l'attaquant essaie l'entrée "a". Cela échoue, car les mots de passe n'ont pas la bonne longueur. L'attaquant peut essayer au hasard différents mots de passe. Chaque mot de passe incorrect plus ou moins long que "mot de passe" prend moins d'une seconde à traiter. Disons qu'ils essaient bientôt "12345678". "12345678" a la même longueur que "mot de passe", il faut donc une seconde pour le traiter. Le timing est différent et l'attaquant s'en aperçoit. Ils essaient plusieurs fois de vérifier, et c'est cohérent.
L'attaquant essaie maintenant plusieurs mots de passe de 8 caractères. Ils prennent tous 1 seconde. L'attaquant a découvert un canal latéral qui leur indique que le mot de passe valide comporte probablement 8 caractères. Ils doivent maintenant déterminer quel mot de passe à 8 caractères est le bon.
L'attaquant commence à essayer au hasard des mots de passe de 8 caractères. Finalement, ils essaient "p2345678" et remarquent que cela prend 2 secondes. Ils testent un groupe et découvrent que toutes les tentatives commençant par "p" prennent 2 secondes. L'attaquant suppose que l'algorithme possède un canal latéral qui lui indique le nombre de caractères corrects.
Maintenant, au lieu d'avoir à essayer tous les 96 ^ 8 mots de passe pour forcer brutalement le mot de passe valide, l'attaquant n'a plus qu'à essayer 96 * 8 mots de passe3. Selon le nombre de mots de passe pouvant être testés en parallèle, ils peuvent probablement réussir à forcer le mot de passe en un temps très raisonnable. C'est super pour l'attaquant! Et c'est terrible pour la sécurité de votre système.4
Comment protéger contre les canaux latéraux de synchronisation? Nous garantissons que toutes les opérations où la synchronisation entraînerait une fuite d'informations sensibles DOIVENT toujours prendre le même temps pour s'exécuter.
Cela peut ressembler à un exemple très simple. C'est arrivé dans la nature. La recherche de NVD pour "canal latéral de synchronisation" 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, le temps que prend quelque chose ne vous dit rien sur l'entrée.
Dans le monde réel, les canaux secondaires sont incroyablement faciles à 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-schéma de protection contre les canaux latéraux. L'algorithme de Dave peut très bien avoir à la fois des canaux secondaires évidents et subtils qu'il ne découvrira jamais, mais que les chercheurs et attaquants savent rechercher, et peuvent assez facilement écrire des tests automatisés pour détecter.5
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 crypto, et utilisez ces effets secondaires pour apprendre le secret protégé.
Notes de fin
1: Eh bien, si vous êtes un agent du renseignement ou un bon journaliste de presse, vous avez probablement intentionnellement mis en place des canaux secondaires afin de pouvoir communiquer avec vos agents/sources sans que "l'ennemi" le sache. De même, si vous êtes sournois, vous pouvez créer un protocole de cryptage avec un canal latéral dans le but de divulguer des informations secrètes.
2: Puisque nous pouvons et devons toujours supposer 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 cryptographie personnalisés "cryptage" ou "décryptage" ... peut-être "chiffrement non sécurisé" ou "déchiffrement cassé" ...
3: J'ignore les attaques par force brute réussies, en moyenne, lorsque l'attaquant a essayé 50% + 1 mots de passe, pour des raisons de simplicité de description. Je me concentre sur les canaux secondaires, pas sur les attaques par force brute. Je passe également en revue les mathématiques d'une attaque par force brute, car cela est également tangentiel au sujet principal; certains Google-Fu au nom du lecteur devraient localiser de nombreuses ressources qui entrent dans les détails.
4: "1 seconde est beaucoup trop lent", non? Aucun système du monde réel n'a pu ê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 montrant que vous pouvez statistiquement tester le timing de l'ordre des millisecondes sur les transactions HTTP.
5 En fait, je serais prêt à parier qu'il existe des cadres ou des outils existants (probablement les deux) que vous pouvez utiliser pour tester votre application pour des canaux secondaires évidents, si vous deviez exercer votre Google-Fu.
Attaques connues en texte brut/texte choisi en clair
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 accès en lecture à la base de données.
Supposons en outre que vous suspectez (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" que 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 une faiblesse de md5 en choisissant soigneusement les mots de passe.
Vous pouvez également "deviner" que l'algorithme est
$hash = sha1(md5($pass . $salt . 'abc') . 'def');
puis essayez à nouveau de forcer brutalement.
Quelque chose d'aussi compliqué que 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 discuté avec @Conor Mancone et @Anders , donc j'ai décidé de l'écrire. Corrigez-moi si je me trompe à nouveau.
md5 Et sha1 Sont cassés, mais pas comme je pense comment 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 original), 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é le 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 billion hash/s. Prenons-le comme 2^40 hash/s Pour plus de commodité, puisque 2^40 > 100 billion. Pour le forcer brutalement, il faut encore 2^128 / 2^40 = 2^88 seconds = 9.80719764 × 1018 years. Et bien sûr, je pense que personne ne pré-calculerait une telle table Rainbow.
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 sont pas différents 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 quelques-uns dans les commentaires.
Sel, poivre, fonction de hachage
Enfin, je pense que je comprends parfaitement ces 3 concepts et leurs cas d'utilisation/combinaisons.
Tout d'abord, je résume 3 types d'attaques par moi-même: 1. attaque par force brute (la méthode "essayez tout") 2. attaque Rainbow table (la recherche directe inversée) 3. attaque par dictionnaire ($pepper. $common_password. $salt Force brute, partiellement brute, par rapport à 1.)
Donc je pense:
- Le sel vise à défendre l'attaque de la table Rainbow.
- Une bonne fonction de hachage (lente) vise à défendre l'attaque par force brute.
- Pepper vise principalement à défendre les attaques de dictionnaire, étant donné que le serveur n'est pas compromis.
Expliquez avec un exemple:
( Sel ) Il faut savoir qu'un sel n'est pas très important comme beaucoup de gens le décrivent. Cela ne défend qu'une chose, c'est qu'un attaquant ne peut pas simplement faire une recherche inversée dans sa table Rainbow pour obtenir votre mot de passe non haché. Si l'on utilise seulement salt + fast hash function (Pas de poivre sur le serveur), alors un attaquant peut faire une force brute pour chaque mot de passe haché. Bien sûr, une autre condition préalable est que vous ne demandiez pas à votre utilisateur de stocker un long mot de passe 128bit Pour l'enregistrement :).
Donc :
salt + fast hash functionNe défend pas l'attaque par force brute. Qu'il puisse défendre l'attaque de la table Rainbow ou l'attaque du dictionnaire n'a plus d'importance maintenant.salt + slow hash functionDéfend l'attaque par force brute. Il défend également l'attaque de la table Rainbow. Il ne défend pas l'attaque par dictionnaire.
( Pepper ) Mais pour la combinaison salt + fast hash function, Si vous utilisez un poivre 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 :
salt + fast hash function + long pepper(e.g.128bits) + server not compromisedpeut désormais défendre l'attaque par force brute. Il défend également l'attaque de la table Rainbow et l'attaque du 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é à craquer salt + fast hash function + long pepper(e.g.128bits) + server gets compromised est la même que quelqu'un utilise uniquement un fast hash function.
Donc :
salt + fast hash function + long pepper(e.g.128bits) + server gets compromisedne défend pas l'attaque par force brute. Qu'il puisse défendre l'attaque de la table Rainbow ou l'attaque du dictionnaire n'a plus d'importance maintenant.- Mais si vous utilisez une fonction de hachage sécurisée/lente, les choses changent.
salt + slow hash function + pepper (not necessary to be very long e.g. 6 chars maybe good enough?) + server gets compromiseddéfendre l'attaque par force brute. Il défend également l'attaque de la table Rainbow. Il ne défend pas l'attaque par dictionnaire.
Qu'en est-il de salt + slow hash function, N'est-ce pas suffisant? Cette combinaison défend l'attaque par force brute et l'attaque de la table arc-en-ciel. Mais il ne défend pas l'attaque par dictionnaire. Ajouter du poivre sur le serveur est facile, pourquoi pas?
Dites quelque chose à Dave
Comme vous pouvez le voir ci-dessus, un poivre est juste quelque chose que vous utilisez pour effectuer une conversion côté serveur.
C'est la "conversion sur le serveur" qui compte vraiment, tant que le serveur n'est pas compromis.
Pour exmaple, 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 de merde sur le serveur comme Dave le fait, vous faites également une conversion. Dans les deux cas, l'attaquant doit compromettre le serveur. Pour les premiers, l'attaquant peut simplement saisir votre valeur constante. Pour ce dernier, l'attaquant a besoin de comprendre comment fonctionne votre truc de merde et doit faire le contraire.
Donc, mon point est, je pense que l'idée de Dave est tout à fait correcte (faites 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 l'enfer si cela ajoute de plus en plus de complexité. Une "conversion" comme la concaténation d'un poivre sur le serveur suffit largement. 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 du côté serveur).
Bien qu'il soit utile d'utiliser un algorithme personnalisé "caché", il existe déjà un moyen trivial et établi de créer des algorithmes de hachage sécurisés personnalisés: Pepper *
Parce que l'option très bon marché, très rapide et très sûre d'utiliser un Pepper existe, les personnes qui écrivent à la place un algorithme de cryptographie à 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ément) sécurisé écrit par quelqu'un qui ne connaît pas grand-chose aux 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 son absence) 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é à domicile.
Parce que ça tourne souvent mal. Et la personne qui l'a écrit ne peut pas le tester, si quelqu'un a une hypothèse erronée lors de l'écriture, il/elle l'a toujours lors du test. Un test indépendant coûte étonnamment cher/prend beaucoup de temps - bien plus que de l'écrire.
Vous devez également inclure toutes les modifications associées. Savoir "il ne peut pas y avoir de problème, car ..." 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 difficile de comprendre à quel point c'est difficile.