Comment certains sites (par exemple les banques en ligne) ne demandent-ils que des caractères spécifiques à un mot de passe sans le stocker en texte clair?
Je pensais Comment un système peut-il imposer un nombre minimum de caractères modifiés ... répondrait à ma question, mais il semble que ce soit un cas différent.
Lorsque je me connecte à mon compte bancaire en ligne, je suis invité à saisir trois chiffres aléatoires à partir d'un code PIN à quatre chiffres et trois caractères aléatoires à partir de mon mot de passe (long, aléatoire).
De ma compréhension limitée de tout cela, la banque n'est pas en mesure de créer mon hachage de mot de passe à partir de cette connexion car ils n'ont pas mon mot de passe complet. Alors, stockent-ils mon mot de passe en texte clair et comparent-ils les caractères individuels? Est-ce un bon équilibre entre commodité et sécurité?
Invité à poser cette question par ce billet de blog: Qui se soucie de la sécurité des mots de passe? NatWest pas
Bien que je ne sache pas explicitement comment les banques gèrent cette exigence, un processus alternatif à celui mentionné par @rakhi consisterait à utiliser un cryptage réversible HSM .
L'idée est que le mot de passe complet serait stocké dans la base de données cryptée à l'aide d'un chiffrement symétrique (par exemple, AES). Ensuite, lorsque les caractères du mot de passe sont transmis à l'application, ils sont introduits dans le HSM avec le mot de passe crypté.
Le HSM pourrait alors déchiffrer le mot de passe et confirmer que les 3 caractères sont comme prévu, renvoyant une réponse de réussite/échec à l'application. Donc, à aucun moment, le mot de passe n'est conservé en clair (sauf dans le HSM qui est considéré comme sécurisé).
Cela correspondrait à la manière dont le cryptage PIN peut être géré par les réseaux ATM (par exemple, le cryptage symétrique et les HSM)
Chaque fois que vous rencontrez un cas où la connaissance de votre mot de passe autre que le hachage du mot de passe complet est nécessaire, vous pouvez supposer que le mot de passe n'est pas haché. Bien que PCI-DSS ait été mentionné, il n'y a aucune réglementation à ma connaissance qui s'applique aux banques qui cryptent ou hachent les informations de mot de passe. PCI-DSS ne couvre pas les informations de votre compte bancaire, y compris la connexion avec votre PIN ou une variante de celui-ci.
S'ils sont bons, le mot de passe est stocké en utilisant le cryptage. S'ils ne sont pas si bons, ils pourraient en effet être stockés en texte clair.
J'avoue que j'aime plutôt le compromis ici. Toute la base de données de mots de passe peut être exposée à un plus grand risque d'attaque si elle est compromise, mais je contrerais que la sécurité des banques devrait être plus élevée. Si un compromis de la base de données était suspecté, tout devrait être changé, qu'il soit haché ou chiffré de toute façon. Dans les deux cas Avec cette méthode particulière, il faut beaucoup plus de temps et une plus grande complexité à un attaquant pour obtenir suffisamment d'informations utiles pour lancer une attaque avec un enregistreur de frappe.
Quelque chose de tangentiellement lié: http://projecteuler.net/index.php?section=problems&id=79
Le plan de NatWest me semble d'une valeur douteuse. Dans le schéma de NatWest, une attaque de phishing peut probablement voler la totalité de votre PIN et tout ou la plupart de votre mot de passe. Voici comment fonctionnerait l'attaque de phishing.
Le site de phishing présenterait un faux écran de connexion, demandant 3 chiffres du PIN et 3 caractères du mot de passe).
L'utilisateur saisirait sa réponse.
Le site de phishing présenterait désormais une réponse indiquant que l'entrée était incorrecte et inviterait à nouveau l'utilisateur.
De nombreux utilisateurs supposeraient probablement qu'ils ont entré quelque chose de mal et réessayer.
Si le phishing est intelligent, la deuxième invite du site de phishing demandera un autre ensemble de chiffres et de caractères. Si l'utilisateur essaie une deuxième fois, le site de phishing peut apprendre les 4 chiffres du PIN et 6 caractères du mot de passe de l'utilisateur. (Notez que NatWest oblige les utilisateurs à choisir un mot de passe contenant 6- 8 caractères, donc 6 caractères du mot de passe sont garantis pour être tout ou presque.) À ce stade, la partie est terminée.
Par conséquent, il n'est pas clair pour moi que le programme de NatWest vous achète quoi que ce soit.
Dans une question similaire , un commentaire de @captaincomic a lié à cet article: Mots de passe partiels - Comment? (De Archive.org) Il explique comment autoriser cette fonctionnalité sans stocker le mot de passe sous une forme récupérable ou hacher chaque caractère séparément - en utilisant le schéma de partage secret de Shamir.
Ce n'est que tangentiellement lié, mais David Aspinall (Université d'Edimbourg) et Mike Just (Université de Glasgow Caledonian) ont publié un article sur les mots de passe partiels en 2013: "Give Me Letters 2, 3 and 6!": Partial Password Implémentations & Attaques .
Leur article examine les attaques en ligne pour lesquelles le mécanisme de stockage principal n'est pas pertinent, mais il fait une remarque passagère qui est pertinente à votre question:
Pour prendre en charge le protocole partiel, l'implémentation devra soit stocker du texte brut pour le mot de passe, soit concevoir un mécanisme pour effectuer des vérifications unidirectionnelles sur toutes les combinaisons qui peuvent être interrogées (qui peut être un grand nombre pour les mots de passe longs). Nous n'enquêtons pas sur ce mode d'attaque ici.
Non, ce qu'ils font, c'est hacher chaque personnage et le stocker ou stocker le mot de passe en clair dans, espérons-le, un appareil sécurisé, par exemple HSM.
Ce n'est pas une mauvaise approche; la banque demande à l'utilisateur d'entrer un nombre de caractères (par exemple, HSBC est 3 à partir de positions aléatoires). Cela signifie que si un cheval de Troie, un enregistreur de frappe ou un site de phishing ont capturé ces 3 caractères, ils n'ont pas le mot de passe complet.
Il permet également à la banque d'utiliser le mot de passe partiel pour authentifier les utilisateurs par téléphone, etc. sans se fier à des questions secrètes ou à un mot de passe différent, là encore sans que la personne du centre d'appel connaisse le mot de passe complet
Quelques problèmes qui explique probablement pourquoi il n'est pas plus largement utilisé:
Le principal est que vous ne souhaitez pas stocker le mot de passe en clair (en fait, des réglementations comme PCI-DSS l'interdisent). L'approche consiste donc à créer un hachage unidirectionnel du mot de passe et à le stocker. Lorsque l'utilisateur entre le mot de passe, celui-ci est haché et comparé au hachage stocké, s'il correspond, l'utilisateur est authentifié. Avec un mot de passe partiel, vous devez soit stocker le mot de passe avec un cryptage réversible, ce qui n'est pas la meilleure pratique, soit stocker un grand nombre de hachages, par ex. pour HSBC avec un anniversaire plus chaque caractère du mot de passe nécessite un hachage séparé. Vous devez également imposer une longueur de mot de passe maximale afin de pouvoir allouer les champs de la base de données pour stocker tous les hachages (bien qu'il existe probablement des technologies de base de données et d'application plus intelligentes qui contourneraient ce problème)
Il encourage les utilisateurs à sélectionner des mots de passe faibles, par exemple si j'ai un mot de passe complexe à 8 caractères: tpEz% e2S. Essayer de se rappeler ce que le 2ème, 4ème et 5ème caractère est difficile, ce qui encourage les utilisateurs à sélectionner un simple dictionnaire Word.
De plus, s'il n'y a pas de fonctionnalités de type de verrouillage de compte, il est exponentiellement plus facile de deviner ou de forcer brutalement 3 caractères que 8 caractères.
La confiance que le mot de passe complet n'est pas connu pourrait être déplacée, par exemple si le mot de passe est Fulham et que vous connaissez F, l, h, vous pouvez peut-être faire une estimation décente du mot de passe complet
Un site de phishing qui a simplement demandé le 1er, le 3, le 5, puis a déclaré un mot de passe incorrect et a changé pour demander le 2, le 4, le 6 pourrait également obtenir le mot de passe complet car l'utilisateur l'entrerait probablement avant d'y réfléchir à deux fois
Du point de vue de la commodité de l'utilisateur, cela signifie qu'ils ne peuvent pas utiliser les navigateurs mémoriser le mot de passe ou un gestionnaire de mots de passe comme Lastpass ou 1Password
La plupart des banques s'éloignent de l'utilisation d'un nom d'utilisateur et d'un mot de passe, par exemple HSBC offre un jeton RSA pour les clients professionnels, Barclays a un lecteur de carte à puce EMV, presque tous utilisent une technologie de détection comme l'authentification adaptative RSA pour établir une base de référence du navigateur, de l'emplacement, du profil d'utilisation, de la vitesse, etc. pour l'authentification passive et la détection d'utilisation non autorisée.