Faisons en sorte que l'utilisateur utilise un mot de passe sécurisé



Il



était une fois suffisant d'avoir une grand-mère diabolique à l'entrée de la salle des machines pour protéger le mot de passe.Il y a longtemps, à l'époque des premiers mainframes, il y avait une excellente authentification à deux facteurs. Avant de saisir votre mot de passe personnel dans le terminal, il fallait passer par la cabine avec un gardien. Tout cela a automatiquement réduit la surface d'attaque à quelques personnes qui avaient physiquement accès au terminal. C'est alors que les modems, le hachage et autres joies du monde moderne sont apparus, lorsque les mots de passe sont régulièrement divulgués par millions.



Si vous avez des utilisateurs et qu'ils se connectent avec un mot de passe, je vous suggère de jeter un autre regard sur les dernières recommandations d'organisations telles que le National Institute of Standards and Technologies et le National Cyber ​​Security Center .



En particulier, il n'est plus à la mode d'exiger la rotation des mots de passe. Et d'exiger certains symboles dans les meilleures traditions de la blague sur "FUCKING ROSE" aussi. Passons en revue les principaux points et essayons de rendre les utilisateurs plus pratiques et plus sûrs.



L'authentification n'est pas binaire



Non, je comprends que les adhérents à des formulations strictes vont maintenant commencer à ressentir du ressentiment. En théorie, l'utilisateur est connecté ou non. Vous ne pourrez pas vous connecter un peu. Pourtant, les guides modernes de sécurité de l'information impliquent une approche non binaire de la confiance des utilisateurs.



Un utilisateur parfaitement fiable a réussi à saisir correctement le mot de passe et à se connecter à partir d'un appareil autorisé. Un peu moins confiance en un utilisateur qui s'est connecté à partir d'un appareil de confiance, mais qui a fait une erreur lors de la saisie du mot de passe. Et c'est vraiment mauvais si l'utilisateur a entré le mot de passe correctement, mais que l'appareil n'est pas fiable, le deuxième facteur n'est pas confirmé et l'adresse IP appartient au nœud de sortie de Thor. Dans le troisième cas, il est temps d'appuyer sur l'interrupteur avec l'inscription «Alarm! Le loup a volé les lapins! "



Notre tâche, en tant que personnes fournissant le service, est de mettre les gens à l'aise, en sécurité et pas très douloureux s'ils font des erreurs. Par conséquent, il convient de placer certains signes d'activité anormale afin d'inclure certaines mesures supplémentaires pour protéger le compte. Par exemple, après 3-5 entrées de mot de passe incorrectes, invitez l'utilisateur à passer par le CAPTCHA. Oui, tout le monde le déteste, mais la plupart des utilisateurs ne le rencontreront pas. Et ceux qui ont déclassé leur cote de confiance ralentiront un peu avant de saisir à nouveau le mot de passe. Mais nous allons couper les attaques automatiques par force brute.



Pas besoin de limiter la longueur maximale du mot de passe





Les mots de passe longs sont plus sûrs. Laissez les utilisateurs les utiliser.



Eh bien, ce n'est pas du tout nécessaire. Des mots de passe gras de plusieurs mégaoctets peuvent potentiellement se produire avec des débordements dans des endroits inattendus ou d'autres effets étranges. Mais la longueur maximale conditionnelle de 300 caractères est garantie pour convenir à tout utilisateur typique. De plus, le NIST adhère aux mêmes recommandations:

L'authentificateur doit permettre à l'utilisateur d'utiliser des mots de passe mémorables d'au moins 64 caractères.


Et pour les services particulièrement doués, le NIST fournit également une autre recommandation importante:

La troncature du mot de passe de l'utilisateur n'est pas autorisée.


Oui, il existe des services extrêmement étranges qui pensent que 12 caractères suffiront, ce qui signifie que les 28 autres peuvent être coupés en toute sécurité et ne vérifier le hachage que du premier fragment. Je ne sais pas ce que l’esprit concerné en a pensé, mais les mêmes organisations bancaires en souffrent souvent. Ne fais pas ça. Si l'utilisateur veut utiliser un morceau d'Iliad en deux avec des fragments de textes du groupe Bloodstock, laissez-le l'utiliser.



Assurez-vous que tous les caractères ASCII sont valides



Il y a certains problèmes avec les caractères spéciaux. Par exemple, l'utilisation de "{} / \" ou d'autres caractères similaires peut être potentiellement invalide dans certaines situations. Disons que les accolades peuvent briser le JSON valide et provoquer le blocage du traitement des mots de passe. Ou le caractère apostrophe, qui peut être utilisé dans l'injection SQL. Oui, le formulaire de saisie du mot de passe peut également être une porte d'entrée pour une attaque.



En théorie, vous pourriez simplement interdire l'utilisation de tels symboles pour vous faciliter la tâche. Mais ce faisant, vous réduirez l'entropie du mot de passe de l'utilisateur et le rendre gênant pour lui si le mot de passe est généré automatiquement. Vous devrez sélectionner certains modèles pour les exceptions. Encore une fois, en référence au NIST Marx :

Tous les caractères ASCII [RFC 20] imprimables, y compris l'espace, doivent être des mots de passe valides. Les caractères Unicode [ISO / ISC 10646] doivent également être valides.


Oui. Tout est correct. Ceci est votre mal de tête et des tests supplémentaires. Mais si l'utilisateur veut utiliser ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ ou මෙයද ඉතා දුෂ්කර මුරපදයකි, laissez-le faire. Ou ajoutez un caractère burrito à votre mot de passe pour la force cryptographique. A le droit de.



En outre, prenez du retard par rapport à l'utilisateur avec l'obligation d'utiliser des caractères spéciaux. Oui, ne le touchez pas. Laissez-le utiliser ce qu'il veut. Les études sur les fuites massives suggèrent que les gens utilisent encore des substitutions stupides avec des caractères spéciaux, ce qui n'améliore pas du tout la situation. Plus précisément, Microsoft écrit:

La plupart des gens utilisent le même modèle, par exemple, une lettre majuscule comme premier caractère, des caractères spéciaux et des chiffres aux deux dernières positions. Les cybercriminels en sont conscients et personnalisent leurs attaques par dictionnaire avec des substitutions typiques telles que «s» pour «$», «a» pour «@» et «i» pour «l».


Oui, le même Microsoft, à cause duquel des millions de personnes chaque mois proposent un nouveau mot de passe qui ne coïncide pas avec les précédents, contenant des caractères spéciaux et des lettres dans des cas différents. Ce sont eux qui écrivent désormais «Éliminer les exigences de composition des personnages» dans leurs directives.



Après tout, à la fin, des utilitaires typiques comme cain et abel, hashcat, john the ripper peuvent trouver un mot de passe pendant plusieurs heures, voire quelques minutes sur une carte vidéo typique, si un mot de vocabulaire standard et un modèle de remplacement typique ont été utilisés.



N'utilisez pas d'indices de mot de passe



Il est beaucoup plus sûr d'enterrer à jamais un mot de passe oublié que de stocker une indication pour l'utilisateur en texte clair dans la base de données.



En 2013, Adobe a divulgué sa base de données de mots de passe. Il était chiffré de manière tordue, mais le plus désagréable était qu'il contenait des indices de récupération, que Randal Monroe n'a pas manqué de se moquer dans xkcd.

Le même avis est partagé par le NIST, qui ne recommande pas de stocker des indices sous quelque forme que ce soit. Oublié - restaurer par e-mail avec tous les contrôles supplémentaires.



Réduisez la charge sur le cerveau de l'utilisateur



Le National Cyber ​​Security Center a publié une infographie sympa . Permettez-moi de citer un petit passage:



Notez que le principal problème avec les mots de passe est qu'un bon mot de passe est aléatoire et presque impossible à mémoriser. S'il existe de nombreux services, l'utilisateur utilisera presque inévitablement le même mot de passe dans la mesure du possible. Les plus avancés feront quelque chose comme "myp@ssword_habr.com". Naturellement, compromettre un mot de passe à un endroit compromet automatiquement les comptes de tous les autres services.

Par conséquent, laissez l'utilisateur utiliser des gestionnaires de mots de passe. Oui, c'est comme un portefeuille spécial pour les cartes bancaires qui vous permet de les perdre en même temps. Mais ici, il faut comprendre que le compromis d'un stockage de mots de passe hors ligne est une situation plutôt rare, contrairement au compromis des mêmes mots de passe sur différentes ressources. Un gestionnaire de mots de passe n'a pas besoin d'être parfait. Il doit être meilleur que le même type de mots de passe partout. Ne soyez pas comme un service méchant qui bloque la possibilité de coller un mot de passe dans un champ du presse-papiers. Cela oblige clairement l'utilisateur à abandonner le gestionnaire de mots de passe et à utiliser l'option faible.



Le deuxième point dit qu'il n'est pas nécessaire de forcer l'utilisateur à changer son mot de passe s'il n'y a pas de signes évidents de son compromis. Cela ne le motive qu'à utiliser le modèle avec le même mot de passe. Il est préférable de déclencher l'alarme si le mot de passe apparaît dans l'un des nombreux dictionnaires qui ont fui. Naturellement, vous ne pouvez pas laisser l'utilisateur créer un mot de passe qui a déjà été inclus dans les dictionnaires.



conclusions



  1. Soyez plus gentil avec l'utilisateur. Ne le forcez pas à trouver des schémas typiques et à faire des choses stupides. Les exigences habituelles standard le poussent directement à cela. Suivez simplement quelques points:
  2. Utilisez l'authentification par clé au lieu de mots de passe, le cas échéant.
  3. Ne laissez pas l'utilisateur utiliser un mot de passe s'il se trouve dans les bases de données du dictionnaire. Peu importe s'il les a divulgués là-bas ou par quelqu'un d'autre.
  4. , . . .
  5. , .
  6. , .













All Articles