La réponse dépend toujours de votre modèle de menace. La sécurité est toujours intégrée dans un équilibre entre sécurité et convivialité. Votre approche dérange les pirates qui tentent de pénétrer dans le compte, mais également un utilisateur qui ne fait qu'une erreur de saisie de 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 à très haut risque. Si vous deviez stocker des secrets nucléaires à l'air libre sur Internet, le fait que chaque mot de passe échoué vous mène à un compte qui a accès à de faux documents qui ne révèlent pas réellement de 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 pratiquement toutes les tentatives de force brute et présente des comportements d'utilisabilité que la plupart des utilisateurs sont prêts à accepter.

Tromper un attaquant avec de faux positifs n'est pas une mauvaise idée, et ce n'est pas nouveau. Ce qui suit peut vous intéresser.

Camouflage cryptographique

CA technologies a breveté une technologie appelée Camouflage cryptographique.

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 pour qu'un seul mot de passe le déchiffre correctement, mais de nombreux mots de passe le déchiffreront pour produire une clé suffisamment valide pour tromper un attaquant. Pour certaines applications, cette méthode protège une clé privée contre les attaques par dictionnaire, comme le fait une carte à puce, mais entièrement dans le logiciel.

Ce n'est pas exactement ce dont vous parlez (ils protéger une clé, pas un 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 déchiffré le code.

Souricière

En 1984, Michael Crichton (auteur d'Andromeda Strain et de nombreux autres) a écrit une courte histoire centrée sur un pirate informatique qui pensait voler des fichiers top secrets. Il avait deviné le bon mot de passe, mais à son insu, l'ordinateur l'authentifiait en réalité non pas en regardant son mot de passe, mais à la vitesse et à 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 a 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, en tout cas) l'utilisation de faux positifs pour contrecarrer une attaque.

Pour vous donner une réponse claire, 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 entre chaque tentative infructueuse et la prochaine estimation. En outre, (juste pour 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 éléments similaires tels que de faux environnements, appareils, serveurs, comptes, etc.

L'effet est minuscule

Supposons que votre système transforme la force brute pratique de déchiffrer les quatre premiers octets (de manière réaliste, le premier bloc beaucoup plus gros, mais peu importe) à avoir à déchiffrer le plein, par exemple. quatre gigaoctets de données chiffrées, ce qui rend les tentatives de force brute environ un milliard de fois ou 2 ^ 30 fois plus lentes.

Maintenant, cela peut vous sembler une grande différence, mais en fait cet effet est minuscule par rapport à d'autres alternatives. Une échelle simplement «milliard de fois plus lente» n'est tout simplement pas si importante 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 chiffrement fait la même chose, et augmenter la taille de la clé par ex. 128 bits (si cela ne suffit pas déjà) à 256 bits fournit un effet incomparablement beaucoup plus important que cela?

La plupart a déjà été dit, je veux juste offrir une autre perspective.

Imaginez que vous essayiez de sécuriser une maison avec cette technique. Vous laisseriez l'intrus donner accès à une cave s'il essaie d'ouvrir la porte pendant un certain temps.

La question est, voudriez-vous même un intrus là-bas? L'intrus se rendra certainement compte qu'il n'a pas obtenu ce qu'il voulait après un certain temps et essaiera de s'éloigner de là. Et vous auriez à maintenir la sécurité supplémentaire pour la cave que vous avez préparée.

Donc, d'une certaine manière, vous ne faites qu'augmenter la quantité de travail pour vous-même pour tromper les attaquants (inexpérimentés) pendant un certain temps.

On dirait que vous parlez d'une forme de «cryptage déniable» ou de «déni plausible» dans le contexte de la crypto; c'est-à-dire un secret alternatif qui se déchiffre en texte clair plausible mais non authentique. Voir https://en.wikipedia.org/wiki/Deniable_encryption pour plus de détails.

Mais à proprement parler, si quelqu'un a la capacité de forcer brutalement votre texte chiffré, il découvrira potentiellement tout des textes en clair plausibles, puis, sur la base des connaissances qu'ils ont déjà sur le contexte, ils seront en mesure de décider lequel des textes en clair est le texte original authentique. La première partie peut être réalisée par des pseudo-IA, mais la seconde partie a encore 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, une procédure hors bande se produit qui vous fournit des réponses raisonnables pour chaque tentative de déchiffrement. Mathématiquement, cela est impossible au niveau d'un texte chiffré et des tentatives de force brute.

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 le hachez à nouveau et comparez les deux hachages. Avoir plus d'un mot de passe simple produit une correspondance valide avec un seul hachage est considéré comme indésirable: cela signifie que le hachage est faible et qu'il a des "collisions".

Il est donc peu probable que vous soyez intéressé par les lecteurs chiffrés.

Ce que vous décrivez - de faux lecteurs "externes" remplis de fausses données protégeant le lecteur "interne" chiffré - est possible, et a été fait en truecrypt (qui malheureusement est mort 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 jugée intéressante.

Truecrypt vous a permis de spécifier un deuxième mot de passe, qui déverrouillerait une "couche" du lecteur chiffré (aurait pu être limité à un conteneur externe, je oublier). Cela avait des problèmes évidents; les lecteurs externes n'étaient pas au courant des lecteurs internes, qui étaient stockés dans «l'espace vide» des lecteurs externes chiffrés. Ainsi, des changements dans ceux extérieurs pourraient détruire les pulsions intérieures. En outre, les horodatages sur les lecteurs internes n'étaient pas automatiquement mis à jour lorsque vous avez accédé au lecteur chiffré. Ainsi, quelqu'un ayant accès à votre machine pourrait dire quand vous avez modifié le fichier du lecteur crypté pour la dernière fois, et pourrait comparer ces horodatages aux heures de dernière modification sur le lecteur crypté, et dire immédiatement que vous l'avez utilisé plus récemment, donc il doit y avoir un lecteur interne.

Mais l'idée était que vous avez le lecteur externe avec un mot de passe facile à deviner, comme password123, mettez des trucs vaguement secrets là-dedans, et cela ferait de vos adversaires pense qu'ils sont entrés dans votre lecteur crypté.

Rien de moins - tout ce qui vient de renvoyer des déchets (bruit aléatoire équivalent à un lecteur non formaté) aurait été trivial à contourner en recherchant une "chaîne magique" sur le lecteur décrypté qui serait nécessaire sur n'importe quel lecteur réel mais peu probable dans un lecteur de déchets.

Même chose avec les documents chiffrés: la plupart des types de fichiers ont des chaînes magiques, donc si vous savez quel type de fichier est contenu, alors tout brouillage effectué peut être forcé de trouver tous les moyens de produire la chaîne magique .

Cela ne veut pas dire que c'est une mauvaise idée, cependant - si la chaîne magique est, disons, "jfif", alors seulement environ un mot de passe sur environ 16 millions aboutira à cette chaîne magique. Mais si la longueur de la clé est, disons, 2 ^ 1024, alors ils l'ont seulement réduite à 2 ^ 1000 - ce qui, bien sûr, est certainement 16 millions de fois plus rapide à craquer, mais prendra littéralement une éternité à craquer.

Les fautes de frappe occasionnelles de mot de passe ne feraient pas penser à quelqu'un qu'il a déchiffré le fichier, mais il ne suffirait pas de rechercher la chaîne magique.

Quelque chose comme ça a été fait dans certaines versions du logiciel de compression RAR (dans les premiers jours, 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 erroné entraînerait une sortie chaotique. Cela a été fait pour empêcher le forçage brutal des mots de passe, ce qui à l'époque était possible pour les archives ZIP qui renvoyaient immédiatement une erreur de "mauvais mot de passe".