Est-il possible de rendre les attaques par force brute inefficaces en donnant de fausses réponses positives aux tentatives de connexion échouées?
Je n'ai aucune expérience ou connaissance scientifique en sécurité, je voulais juste demander si c'est possible parce que je m'y intéresse.
Que se passe-t-il si je crypte les données et que chaque mot de passe les décrypte, mais que le bon ne crée pas un fouillis de données inutile? La même chose pourrait être faite avec une connexion: de fausses données de connexion conduisent à de faux comptes factices et seuls les bons détails de connexion vous permettent d'accéder aux bons comptes.
Ne serait-ce pas une meilleure méthode de cryptage parce que vous ne pouvez pas simplement essayer des mots de passe mais devez regarder le résultat pour voir si c'est le bon?
La réponse dépend toujours de votre modèle de menace. La sécurité est toujours liée à un équilibre entre sécurité et convivialité. Votre approche gêne les pirates qui tentent de s'introduire dans le compte, mais gêne également un utilisateur qui ne fait que mal saisir son mot de passe. Si le faux compte est suffisamment crédible pour tromper un attaquant, il peut également être suffisamment crédible pour tromper un utilisateur valide. Cela pourrait être très mauvais.
Cela peut être souhaitable dans des environnements à risque extrêmement élevé. Si vous deviez stocker des secrets nucléaires en plein air sur Internet, avoir chaque mot de passe échoué vous mènerait à un compte qui a accès à de faux documents qui ne révèlent pas réellement des secrets nationaux pourrait être assez puissant. Cependant, dans la plupart des cas, cela n'est pas nécessaire.
Vous devez également considérer les alternatives. Une approche très populaire consiste à verrouiller le compte après N tentatives, ce qui arrête fondamentalement toutes les tentatives de force brute et a des comportements d'utilisabilité que la plupart des utilisateurs sont prêts à accepter.
Tromper un attaquant avec des faux positifs n'est pas une mauvaise idée, et ce n'est pas nouveau. Les éléments suivants peuvent vous intéresser.
Camouflage cryptographique
CA technologies a breveté une technologie connue sous le nom de Cryptographic Camouflage .
Un point sensible de la cryptographie à clé publique est de savoir comment protéger la clé privée. Nous décrivons une méthode de protection des clés privées à l'aide du camouflage cryptographique. Plus précisément, nous ne chiffrons pas la clé privée avec un mot de passe trop long pour une attaque exhaustive. Au lieu de cela, nous le chiffrons afin qu'un seul mot de passe le déchiffre correctement, mais de nombreux mots de passe le déchiffrent pour produire une clé qui semble suffisamment valide pour tromper un attaquant. Pour certaines applications, cette méthode protège une clé privée contre les attaques de dictionnaire, comme le fait une carte à puce, mais entièrement dans un logiciel.
Ce n'est pas exactement ce dont vous parlez (ils protègent une clé, pas l'accès) mais le concept est le même. Vous déjouez une attaque par force brute en rendant difficile ou impossible de déterminer si vous avez réellement craqué le code.
Piege a souris
En 1984, Michael Crichton (auteur d'Andromeda Strain et bien d'autres) a écrit une nouvelle centrée sur un pirate qui pensait voler des fichiers top secrets. Il avait deviné le bon mot de passe, mais à son insu, l'ordinateur l'authentifiait en fait non pas en regardant son mot de passe mais en raison de la vitesse et de la manière dont il utilisait le clavier et la souris - une sorte de mécanisme d'authentification biométrique. Il a échoué l'authentification. Mais l'ordinateur ne lui a pas dit qu'il avait échoué - au lieu de cela, il lui a présenté une fausse copie des documents secrets, qu'il a ensuite téléchargés et tenté de vendre sur le marché noir.
Encore une fois, ce n'est pas exactement la même chose que ce que vous demandez, mais cela démontre (dans la fiction, de toute façon) l'utilisation de faux positifs pour contrecarrer une attaque.
Pour vous donner une réponse directe, oui , il est possible de réduire l'efficacité des attaques par force brute et cela peut être fait comme vous l'avez suggéré, mais ne devrait pas. Vous pouvez obtenir des résultats très similaires simplement en implémentant des délais de temporisation entre chaque tentative échouée et la prochaine supposition. En outre, (juste à votre connaissance) des technologies très sophistiquées et similaires ont déjà été conçues et mises en œuvre pour cette chose exacte. Des produits comme Canary , Honey Pots et Honey Docs offrent tous des choses similaires comme de faux environnements, appareils, serveurs, comptes, etc.
L'effet est minuscule
Supposons que votre système transforme la force brute pratique du décryptage des quatre premiers octets (de manière réaliste, le premier bloc beaucoup plus grand, mais peu importe) au décryptage complet, par ex. quatre gigaoctets de données chiffrées, ce qui rend les tentatives de bruteforce environ un milliard de fois ou 2 ^ 30 fois plus lentes.
Maintenant, cela peut vous sembler une grande différence, mais en réalité cet effet est minuscule par rapport à d'autres alternatives. Une échelle tout simplement "un milliard de fois plus lente" n'est tout simplement pas tant que ça dans le monde de la cryptographie. Pourquoi s'embêter avec une complexité supplémentaire qui pourrait ne pas atteindre le ralentissement prévu ou introduire de nouveaux bogues, si simplement ajouter 30 bits supplémentaires à la longueur de la clé de cryptage fait la même chose, et augmenter la taille de la clé par exemple 128 bits (si ce n'est pas déjà suffisant) à 256 bits fournit un incomparablement effet beaucoup plus important que cela?
La plupart ont déjà été dit, je veux juste offrir une autre perspective.
Imaginez que vous tentiez de sécuriser une maison avec cette technique. Vous laisseriez l'intrus donner accès à une cave s'il essaye d'ouvrir la porte pendant un certain temps.
La question est, voudriez-vous un intrus même là-bas? L'intrus se rendra très certainement compte qu'il n'a pas obtenu ce qu'il voulait après un certain temps et essaiera de s'en éloigner. Et vous devrez maintenir la sécurité supplémentaire de la cave que vous avez préparée.
Donc, d'une certaine manière, vous n'augmentez que la quantité de travail pour tromper les attaquants (inexpérimentés) pendant un certain temps.
On dirait que vous parlez d'une forme de "chiffrement déniable" ou de "déni plausible" dans le contexte de la cryptographie; c'est-à-dire un autre secret qui déchiffre en texte clair plausible mais non authentique. Voir https://en.wikipedia.org/wiki/Deniable_encryption pour plus de détails.
Mais à strictement parler, si quelqu'un a la capacité de forcer votre texte chiffré, il découvrira potentiellement tous les textes en clair plausibles, puis, sur la base de toute connaissance qu'il a déjà sur le contexte, il pourra décider lequel des textes en clair est l'original authentique une. La première partie peut être effectuée par des pseudo-IA, mais la deuxième partie a toujours besoin d'un humain.
Le problème avec les clés est qu'elles existent en tant que données et non en tant que code en cours d'exécution. Même avec l'exemple CA et Crichton, ce qui se produit est qu'une procédure hors bande se produit qui vous fournit des réponses raisonnables pour chaque essai de déchiffrement. Mathématiquement, cela est impossible au niveau d'un texte chiffré et de tentatives de force brute.
Quelque chose comme ça a été fait dans certaines versions du logiciel de compression RAR (au début, je ne sais pas si c'est toujours comme ça). Une archive chiffrée serait déchiffrée par n'importe quel mot de passe entré, mais un mot de passe incorrect entraînerait une sortie de charabia. Cela a été fait pour empêcher le forçage brutal des mots de passe, ce qui était possible à l'époque pour les archives Zip qui renvoyaient immédiatement une erreur de "mauvais mot de passe".
Pour l'accès à distance, comme d'autres l'ont dit, de simples verrouillages et retards peuvent fonctionner.
Pour les mots de passe, vous disposez d'un hachage unidirectionnel. Pour valider le mot de passe, vous devez le hacher de nouveau et comparer les deux hachages. Le fait d'avoir plusieurs mots de passe simples pour produire une correspondance valide avec un seul hachage est considéré comme indésirable: cela signifie que le hachage est faible et a des "collisions".
Il est donc heureux que vous soyez intéressé par les lecteurs chiffrés.
Ce que vous décrivez - de faux disques "externes" remplis de fausses données protégeant le lecteur "interne" crypté - est possible et a été fait dans truecrypt (qui est malheureusement décédé depuis).
Ce qui suit est ma propre compréhension naïve, et certains ou tous peuvent être faux. Je n'ai jamais utilisé cette fonctionnalité, mais je l'ai trouvée intéressante.
Truecrypt vous a permis de spécifier un deuxième mot de passe, qui déverrouillerait une "couche" du lecteur chiffré (peut-être limité à un conteneur externe, j'oublie). Cela avait des problèmes évidents; les disques externes ignoraient les disques internes, qui étaient stockés dans "l'espace vide" des disques externes cryptés. Ainsi, les changements dans les externes pourraient détruire les lecteurs internes. En outre, les horodatages sur les lecteurs internes n'ont pas été automatiquement mis à jour lorsque vous avez accédé au lecteur crypté. Ainsi, une personne ayant accès à votre machine pourrait dire quand vous avez modifié pour la dernière fois le fichier du lecteur chiffré, et pourrait comparer ces horodatages aux heures modifiées en dernier sur le lecteur chiffré, et immédiatement dire que vous l'utilisiez plus récemment, donc il doit y avoir un entraînement intérieur.
Mais l'idée était que vous avez le lecteur externe un mot de passe facile à deviner, comme password123, y mettre des trucs vaguement secrets, et cela ferait croire à vos adversaires qu'ils étaient entrés dans votre lecteur crypté.
Rien de moins - tout ce qui vient de renvoyer des ordures (bruit aléatoire équivalent à un lecteur non formaté) aurait été trivial à contourner en vérifiant une "chaîne magique" sur le lecteur déchiffré qui serait requise sur n'importe quel lecteur réel mais peu probable dans un lecteur de déchets .
Même chose avec les documents cryptés: la plupart des types de fichiers ont des chaînes magiques, donc si vous savez quel type de fichier est contenu, tout brouillage effectué peut être forcé par la force de trouver toutes les façons de produire la chaîne magique.
Cela ne signifie pas que c'est une mauvaise idée, cependant - si la chaîne magique est, disons, "jfif", alors seulement environ un mot de passe sur 16 millions aboutira à cette chaîne magique. Mais si la longueur de la clé est, disons, 2 ^ 1024, alors ils ont seulement réduit cela à 2 ^ 1000 - ce qui, bien sûr, est certainement 16 millions de fois plus rapide à craquer, mais prendra toujours littéralement pour toujours = se fissurer.
Les fautes de mots de passe occasionnelles ne feraient pas croire à quelqu'un qu'ils avaient décrypté le fichier, mais simplement rechercher la chaîne magique ne serait pas suffisant.