Convertir Leet-parler au texte en clair

Je suis d'accord, je suis d'accord :) "De-1337-ifing" n'est pas trivial du tout. Un exemple rapide serait que «4 '==' A» en 1337, SOO, voulez-vous interdire les 4?

---

Je pense que l'OP veut empêcher les mots de passe comme "L33T HAXX0R", qui est assez trivial et probablement plutôt commun. Il a 8 caractères, au moins un nombre et un caractère spécial, mais n'est pas sécurisé.

---

@Stephen, même la question de l'OPS veut minimiser cela ... et ils obtiendraient quelque chose comme "Leet Haxxor" ou "Elite Hacker" selon les règles qu'ils suivent, ils seraient mieux à ajouter "L33T HAXX0R" au dictionnaire de mauvais mots de passe.

---

@Stephen Cleary, alors une meilleure idée peut être d'ajouter des expressions communes L33T-Dites comme 1337, H4X0R, etc. au dictionnaire et ne permettez pas aux mots de passe de contenir des sous-chaînes de ces mots.

---

Je ne pense pas que l'OP n'est intéressé que par des formulations communes de 1337, comme H4X0R, etc., mais également l'utilisation de 1337 dans un mot de passe pour se conformer à ses règles. Par exemple, si j'utilise normalement "Escobar" comme mot de passe, il ne permettra pas "Esc0b4r" - bien, au moins c'est comme ça que j'interprète sa description de problème :)

---

@ Jonathon: Je suis d'accord avec toi. Je soulignais simplement que cette réponse ne répond pas vraiment au problème de l'OP - il envisage déjà de définir des exigences de mot de passe fortes.

---

Eh bien, tout comme essayer d'aider quelqu'un dans "l'entreprise" quand vous êtes dans "ça", vous devez parfois expliquer que ce qu'ils demandent n'est pas vraiment ce qu'ils veulent.

---

Merci a tous. Beaucoup de ces suggestions sont déjà en cours dans le système, je ne les ai pas mentionnées parce qu'elles n'étaient pas terriblement pertinentes pour la question. J'ai une mesure de complexité en termes de bits d'entropie conformément à la publication NIST sur le sujet. Les mots de passe doivent être au moins équivalents à 56 bits (configurables par la police). Mais un chèque de dictionnaire est un complément important à cela. "P @ S5W0RD" peut passer des chèques de regex simples, et même ressembler à une bonne entropie, mais ce n'est pas un bon mot de passe, car il s'agit d'un mot de dictionnaire qui a été leuné qui ajoute une surcharge triviale à une attaque didiconaire.

---

@Dano: Pourquoi seriez-vous vulnérable à une attaque de dictionnaire?

---

J'espère que nous ne l'sommes pas. Il existe un principe dans la sécurité appelée défense en profondeur. Même si nous vous bloquons après avoir dit 5 tentatives infructueuses et que vous prenez d'autres précations, il est préférable d'avoir plusieurs couches de défense plutôt que de compter sur une seule couche ... forte comme elle peut être.

---

Si le problème impensable et quelqu'un a obtenu nos mots de passe hachés à partir de la base de données, ils pourraient facilement exécuter un dictionnaire de 10 000 mots contre ceux hachés pour les matchs. Ils n'ont besoin que d'un utilisateur d'avoir utilisé un mot de dictionnaire. Léification simple complémentaire (la manière dont beaucoup d'utilisateurs ajoutent les symboles requis) et l'attaquant pourrait ajouter 5 variations LEET à chaque mot de dictionnaire et ne sera toujours qu'à 50 000 hachages dont ils ont besoin d'effectuer. C'est seulement équivalent à une clé 8 bits

---

@Dano je vous entends et je n'essaie pas d'être difficile. J'ai ajouté du code dans une autre réponse. Je me sens comme si je dois être snarky et mentionner que si quelqu'un obtient vos mots de passe hachés, Leet Parle est le moindre de vos problèmes :)

---

@Dano 50 000 possibilités serait d'une clé de 16 bits non de 8 bits. Oups.

---

-1. Les mots leunes réduisent le caractère aléatoire des mots de passe et les rendent plus propices lorsqu'ils sont attaqués avec des dictionnaires. Il s'agit donc d'une obligation ISO / IEC 27K d'empêcher les utilisateurs d'utiliser des mots de dictionnaire et des organisations doivent simplement se conformer. Les exigences que vous avez mentionnées devraient compléter le dictionnaire LEETED, ne pas le remplacer.

---

Je pense qu'une carte Leet => Ungeet serait meilleure, car vous n'auriez pas à taper Leetrules.add pour chaque paire.

---

Merci, c'est parfait. Extensible, simple. Ces substitutions pourraient être dans un fichier pour le rendre encore plus extensible. Les suffixes comme -xor et -Zorz pourraient simplement être supprimés. N'y a-t-il plus de plus à Leet que de ce chiffrement de substitution? Gaspilleur? Choix intéressant de mot de passe.

---

Bien que je puisse y avoir plus de grammaire impliquée avec Leet que la substitution. Traiter avec les grammaires était une partie de CS que je ne me souciais pas.

---

En ce qui concerne la construction de la grammaire et des remplacements supplémentaires, la fonction ne reviendrait probablement jamais seulement 1 résultat d'un mot de passe entrant. Si vous souhaitez être retourné, un tableau de chaque remplacement possible (c'est-à-dire H4CK = HACK, HAX, HAXX), je pourrais alors aider à l'élargir. Comme il est maintenant, j'ai commandé des remplacements spécifiquement pour ne pas gâcher les remplaçants qui se déroulent plus tard.

---

@FOSCO Même avec la commande, je ne pense pas qu'il soit possible de cartographier une séquence Leet sur une seule séquence inexploitante: \ / \ 3 peut être traduite en vb, v \ e, \ ae, \ ae, etc ... peut-être retourner un ensemble de toutes les traductions possibles serait mieux?

---