Récemment, j'ai eu le temps de réfléchir à nouveau à la façon dont la fonction de réinitialisation sécurisée des mots de passe devrait fonctionner, d'abord lorsque j'ai intégré cette fonctionnalité dans , puis en aidant une autre personne à faire quelque chose de similaire. Dans ce deuxième cas, je voulais lui donner un lien vers une ressource canonique contenant tous les détails sur la mise en œuvre sécurisée de la fonction de réinitialisation. Cependant, le problème est qu'il n'existe pas de telle ressource, du moins pas une qui décrive tout ce que je considère comme important. C'est pourquoi j'ai décidé de l'écrire moi-même.
Vous voyez, le monde des mots de passe oubliés est en réalité assez mystérieux. Il existe de nombreux points de vue différents, tous totalement acceptables, et une quantité de points de vue plutôt dangereux. Il est probable que vous ayez croisé chacun d'eux en tant qu'utilisateur final ; c'est pourquoi j'essaierai d'utiliser ces exemples pour montrer qui fait les choses correctement et qui ne le fait pas, et sur quoi il faut se concentrer pour une mise en œuvre réussie de la fonction dans votre application.
Stockage des mots de passe : hachage, cryptage et (oh !) texte en clair
Nous ne pouvons pas discuter de ce qu'il faut faire avec les mots de passe oubliés avant de discuter de la manière de les stocker. Dans la base de données, les mots de passe sont stockés dans l'un des trois types principaux :
- Texte en clair. Il existe une colonne contenant le mot de passe stocké en texte normal.
- Chiffré. Généralement par cryptage symétrique (une clé est utilisée pour le chiffrage et le déchiffrement), et les mots de passe chiffrés sont également stockés dans une seule colonne.
- Haché. Processus unidirectionnel (le mot de passe peut être haché, mais ne peut pas être déchiffré) ; le mot de passe, on l'espère, est accompagné d'un sel, et chacun d'eux se trouve dans sa propre colonne.
Clarifions d'abord la question la plus simple : ne stockez jamais les mots de passe en texte clair ! Jamais. Une seule vulnérabilité à une , une copie de sauvegarde mal faite ou l'une des dizaines d'autres erreurs simples – et c'est tout, game over, tous vos mots de passe – c'est-à-dire, désolé, les mots de passe de tous vos clients deviendront d'intérêt public. Bien sûr, cela signifiera une énorme probabilité que d'intérêt public deviennent pour tous leurs comptes dans d'autres systèmes. Et ce sera votre responsabilité.
Le chiffrement est meilleur, mais il a ses faiblesses. Le problème du chiffrement réside dans le déchiffrement ; on peut prendre ces chiffres apparemment fous et les transformer à nouveau en texte clair, et lorsque cela se produit, nous revenons à une situation où les mots de passe sont lisibles. Comment cela se produit-il ? Un petit défaut s'infiltre dans le code qui s'occupe du déchiffrement du mot de passe, le rendant accessible au public — c'est une méthode. Les pirates accèdent à la machine où les données chiffrées sont stockées — c'est la deuxième méthode. Une autre méthode consiste à voler une sauvegarde de la base de données, et quelqu'un obtient également la clé de chiffrement, qui est souvent stockée de manière très peu fiable.
Et cela nous amène à la hachage. L'idée du hachage est qu'il s'effectue dans un sens ; la seule façon de comparer le mot de passe saisi par l'utilisateur avec sa version hachée est de hacher l'entrée et de les comparer. Pour empêcher les attaques utilisant des outils comme les « tables de hachage » (pour plus de détails, lisez mon sur le stockage cryptographique). En fin de compte, avec une bonne mise en œuvre, nous pouvons avec une grande confiance considérer que les mots de passe hachés ne redeviendront jamais du texte clair (je parlerai des avantages des différents algorithmes de hachage dans un autre article).
Un bref argument sur le hachage et le chiffrement : la seule raison pour laquelle vous aurez un jour besoin de chiffrer un mot de passe plutôt que de le hacher est lorsque vous devez voir le mot de passe en texte clair, et vous ne devriez jamais vouloir cela, du moins dans le cas d'un site web standard. Si vous en avez besoin, il est probable que vous fassiez quelque chose de mal !
Attention !
Un peu plus bas dans le texte de l'article, il y a une partie d'une capture d'écran du site pornographique AlotPorn. Elle est soigneusement recadrée, et il n'y a rien d'autre que ce qu'on peut voir à la plage, mais si cela peut quand même poser des problèmes, n faites pas défiler la page vers le bas.
Réinitialisez toujours le mot de passe, jamais ne le rappelez
Vous a-t-on déjà demandé de créer une fonction de rappel mot de passe ? Faites un pas en arrière et réfléchissez à cette demande dans l'autre sens : pourquoi cette "rappel" est-il nécessaire ? Parce que l'utilisateur a oublié son mot de passe. Que voulons-nous vraiment faire ? L'aider à se reconnecter au système.
Je comprends que le mot "rappel" est utilisé (souvent) au sens conversationnel, mais en réalité, nous essayons de aider l'utilisateur à revenir en ligne en toute sécurité.Puisque la sécurité est essentielle, il y a deux raisons pour lesquelles un rappel (c'est-à-dire envoyer le mot de passe à l'utilisateur) n'est pas approprié :
- L'e-mail est un canal peu sûr. Tout comme nous ne transmettrions rien de confidentiel par HTTP (nous utiliserions HTTPS), il n'est pas approprié de transmettre des informations par e-mail, car son niveau de transport est peu sûr. En réalité, c'est bien pire que de transmettre des informations via un protocole de transport non sécurisé, car les e-mails sont souvent stockés sur des disques, accessibles aux administrateurs système, transférés et diffusés, accessibles aux logiciels malveillants, etc. Un e-mail non chiffré est un canal extrêmement peu sécurisé.
- En tout cas, vous ne devriez pas avoir accès au mot de passe. Relisez la section précédente sur le stockage — vous devez avoir un hachage de mot de passe (avec un bon sel robuste), c'est-à-dire que vous ne devez en aucun cas pouvoir extraire le mot de passe et l'envoyer par e-mail.
Permettez-moi de démontrer le problème avec l'exemple de : Voici une page de connexion typique :
Il est évident que le premier problème réside dans le fait que la page de connexion n'est pas chargée via HTTPS, mais le site propose également d'envoyer le mot de passe ("Send Password"). C'est peut-être un exemple de l'utilisation conversationnelle mentionnée ci-dessus, alors faisons un pas de plus et voyons ce qui se passe :
Cela ne semble pas beaucoup mieux, malheureusement ; et l'e-mail confirme qu'il y a un problème :
Cela nous parle de deux aspects importants d'usoutdoor.com :
- Le site ne hache pas les mots de passe. Au mieux, ils sont chiffrés, mais il est très probable qu'ils soient stockés en texte clair ; il n'y a pas de preuve du contraire.
- Le site envoie un mot de passe permanent (nous pouvons revenir et l'utiliser encore et encore) par un canal non sécurisé.
Une fois cela clarifié, nous devons vérifier si le processus de réinitialisation est effectué de manière sécurisée. Tout d'abord, il est nécessaire de s'assurer que la personne qui fait la demande a le droit d'effectuer la réinitialisation. En d'autres termes, nous avons besoin d'une vérification d'identité avant cela; examinons ce qui se passe lorsque l'identité est confirmée sans vérification préalable que le demandeur est bien le propriétaire du compte.
La liste des noms d'utilisateur et son impact sur l'anonymat
Ce problème est mieux illustré visuellement. Problème :
Voyez-vous? Notez le message « There is no user registered with this email address » (« Aucun utilisateur enregistré avec cette adresse e-mail »). Le problème survient manifestement lorsque un tel site confirme la présence d'un utilisateur enregistré avec cette adresse e-mail. Bingo — vous venez de découvrir le fétichisme pornographique de votre mari / patron / voisin !
Il va de soi que la pornographie est un exemple canonique de l'importance de la vie privée, cependant, le danger de relier une identité à un site Web spécifique est beaucoup plus vaste que la situation potentiellement embarrassante décrite ci-dessus. L'une des menaces est l'ingénierie sociale; si un attaquant peut associer une personne à un service, il disposera d'informations qu'il pourra commencer à exploiter. Par exemple, il pourrait contacter la personne en se faisant passer pour un représentant du site Web et demander des informations supplémentaires, essayant de réaliser .
De telles pratiques engendrent également le risque de « dénombrement de noms d'utilisateur », où il est possible de vérifier l'existence d'une collection entière de noms d'utilisateur ou d'adresses e-mail sur un site Web par des requêtes groupées simples et en analysant les réponses. Vous avez une liste d'adresses e-mail de tous les employés et quelques minutes pour écrire un script ? Alors vous comprenez le problème !
Quelle est l'alternative ? En fait, elle est assez simple et merveilleusement mise en œuvre sur :
Ici, Entropay ne divulgue absolument rien sur l'existence d'une adresse e-mail dans son système à quiconque ne possède pas cette adresse. Si vous possédez cet e-mail et qu'il n'existe pas dans le système, vous recevrez un e-mail comme celui-ci :
Bien sûr, il existe des situations acceptables dans lesquelles quelqu'un pense, qu'il s'est inscrit sur le site. mais ce n'est pas le cas, ou l'a fait avec une autre adresse e-mail. L'exemple ci-dessus gère habilement les deux situations. Évidemment, si l'adresse correspond, vous recevrez un e-mail facilitant la réinitialisation du mot de passe.
La subtilité de la solution Entropay choisie est que la vérification de l'identité est effectuée par e-mail avant toute vérification en ligne. Certains sites demandent aux utilisateurs de répondre à une question secrète (plus de détails ci-dessous) à avant que la réinitialisation puisse commencer ; cependant, le problème est qu'il faut répondre à la question en fournissant un type d'identification (e-mail ou nom d'utilisateur), ce qui rend ensuite presque impossible de répondre de manière intuitive sans révéler l'existence du compte d'utilisateur anonyme.
Avec cette approche, il y a une légère diminution de l'utilisabilité, car lorsqu'une tentative de réinitialisation d'un compte inexistant est effectuée, il n'y a pas de rétroaction immédiate. Bien sûr, c'est tout l'intérêt d'envoyer un e-mail, mais du point de vue d'un utilisateur final, s'il saisit une mauvaise adresse, il ne le découvrira qu'à la réception de l'e-mail. Cela peut provoquer une certaine tension de sa part, mais c'est un faible prix à payer pour un processus si rare.
Une autre remarque, un peu à l'écart du sujet : les fonctions d'aide à la connexion qui révèlent la validité du nom d'utilisateur ou de l'adresse e-mail présentent le même problème. Répondez toujours à l'utilisateur avec le message "La combinaison nom d'utilisateur et mot de passe est invalide" (Your username and password combination is invalid), plutôt que de confirmer explicitement l'existence d'informations d'identification (par exemple, "le nom d'utilisateur est correct, mais le mot de passe est incorrect").
L'envoi d'un mot de passe de réinitialisation contre l'envoi d'une URL de réinitialisation
Le concept suivant que nous devons discuter concerne la façon de réinitialiser le mot de passe. Il existe deux solutions populaires :
- Générer un nouveau mot de passe sur le serveur et l'envoyer par e-mail
- Envoyer un e-mail contenant une URL unique facilitant le processus de réinitialisation
Malgré , le premier point ne doit jamais être utilisé. Son problème est qu'il implique la présence d'un mot de passe stocké, auquel on peut revenir et réutiliser à tout moment ; il a été transmis par un canal non sécurisé et reste dans vos courriers entrants. Il y a une probabilité que les courriers entrants soient synchronisés avec des appareils mobiles et un client de messagerie, plus ils peuvent être stockés en ligne dans un service de messagerie pendant une très longue période. L'idée est que la boîte mail ne peut pas être considérée comme un moyen fiable de stockage à long terme.
Mais en plus de cela, le premier point présente un autre problème sérieux : il facilite grandement le blocage de compte avec malveillance. Si je connais l'adresse e-mail de la personne qui possède le compte sur le site, je peux le bloquer à tout moment simplement en réinitialisant son mot de passe ; c'est une attaque de type « déni de service » servie sur un plateau d'argent ! C'est pourquoi la réinitialisation ne doit être effectuée qu'après une vérification réussie des droits de la personne qui en fait la demande.
Lorsque nous parlons de l'URL de réinitialisation, nous faisons référence à l'adresse du site web, qui est unique pour ce cas précis de réinitialisation. Évidemment, elle doit être aléatoire, ne doit pas être facile à deviner et ne doit contenir aucun lien externe vers le compte, facilitant la réinitialisation. Par exemple, l'URL de réinitialisation ne doit pas simplement être un chemin comme « Reset/?username=JohnSmith ».
Nous voulons créer un jeton unique, qui pourra être envoyé par e-mail sous forme d'URL de réinitialisation, puis le comparer à l'enregistrement sur le serveur avec le compte utilisateur, confirmant ainsi que le propriétaire du compte est bien la même personne qui essaie de réinitialiser le mot de passe. Par exemple, le jeton peut être sous la forme « 3ce7854015cd38c862cb9e14a1ae552b » et stocké dans une table avec l'ID de l'utilisateur qui effectue la réinitialisation et l'heure de génération du jeton (plus de détails à ce sujet un peu plus bas). Lors de l'envoi de l'e-mail, il contient une URL comme « Reset/?id=3ce7854015cd38c862cb9e14a1ae552b », et lorsque l'utilisateur la charge, la page vérifie l'existence du jeton, après quoi elle confirme les informations de l'utilisateur et permet de changer le mot de passe.
Bien sûr, puisque le processus décrit ci-dessus (nous l'espère) permet à l'utilisateur de créer un nouveau mot de passe, il faut garantir le chargement de l'URL en HTTPS. Non, , cette URL avec le token doit utiliser la sécurité de la couche de transport, pour que le formulaire de saisie du nouveau mot de passe ne puisse pas être attaqué par et le mot de passe créé par l'utilisateur soit transmis par une connexion sécurisée.
De plus, pour l'URL de réinitialisation, il est nécessaire d'ajouter une limite de temps au token, afin que le processus de réinitialisation puisse être effectué dans un délai spécifique, disons dans l'heure. Cela garantit que la fenêtre de réinitialisation est minimale, de sorte que la personne ayant reçu cette URL de réinitialisation ne puisse agir que dans ce très petit délai. Bien sûr, un attaquant peut recommencer le processus de réinitialisation, mais il devra obtenir un nouvel URL de réinitialisation unique.
Enfin, nous devons assurer l'unicité de ce processus. Après la fin du processus de réinitialisation, le token doit être supprimé afin que l'URL de réinitialisation ne soit plus valide. Le point précédent est nécessaire pour donner à un attaquant une très petite fenêtre pendant laquelle il peut manipuler l'URL de réinitialisation. De plus, bien sûr, après une réinitialisation réussie, le token n'est plus nécessaire.
Certaines de ces étapes peuvent sembler excessives, mais elles n'entravent absolument pas l'utilisabilité et en réalité renforcent la sécurité, même dans des situations que nous espérons rares. Dans 99% des cas, l'utilisateur s'engagera dans une réinitialisation pendant une très courte période et ne réinitialisera pas son mot de passe à nouveau dans un avenir proche.
Le rôle de la CAPTCHA
Oh, CAPTCHA, cet outil de protection que nous aimons tous détester ! En réalité, la CAPTCHA est principalement un moyen d'identification — êtes-vous un humain ou un robot (ou un script automatisé). Son but est d'éviter l'envoi automatique de formulaires, ce qui, bien sûr, peut peut être tenté comme méthode d'attaque. Dans le contexte de la réinitialisation des mots de passe, la CAPTCHA signifie que la fonction de réinitialisation ne peut pas être piratée par force brute, afin de soit spammer l'utilisateur ultérieurement, soit essayer de déterminer l'existence de comptes (ce qui, bien sûr, ne sera pas possible si vous avez suivi les conseils de la section sur la vérification d'identité).
Bien sûr, le CAPTCHA n'est pas parfait en soi ; il existe de nombreux cas de « piratage » de son système et d'atteinte de taux de réussite suffisants (60-70 %). De plus, il existe une solution, présentée dans mon post sur , où l'on peut payer des gens quelques centimes pour résoudre chaque CAPTCHA et obtenir un taux de réussite de 94 %. Cela signifie qu'il est vulnérable, mais cela (légèrement) augmente la barrière d'entrée.
Regardons un exemple avec PayPal :
Dans ce cas, le processus de réinitialisation ne peut simplement pas commencer tant que le CAPTCHA n'est pas résolu, donc théoriquement l'automatisation du processus est impossible. Théoriquement.
Cependant, pour la majorité des applications web, cela serait excessif et représente absolument une baisse de l'utilisabilité — les gens n'aiment tout simplement pas les CAPTCHA ! De plus, le CAPTCHA est quelque chose auquel l'on peut facilement revenir si nécessaire. Si le service commence à être attaqué (le logging est ici utile, mais nous y reviendrons plus tard), ajouter un CAPTCHA n'est pas compliqué.
Questions et réponses secrètes
Pour tous les moyens que nous avons examinés, nous pouvions réinitialiser le mot de passe simplement en ayant accès au compte de messagerie. Je dis « simplement », mais, bien sûr, obtenir illégalement l'accès au compte de messagerie d'autrui doit être un processus compliqué. Cependant .
En réalité, le lien ci-dessus sur le piratage du compte de Sarah Palin sur Yahoo ! sert deux objectifs ; d'abord, il illustre à quel point il est facile de pirater (certains) comptes de messagerie, ensuite, il montre comment on peut utiliser de mauvaises questions secrètes de manière malveillante. Mais nous y reviendrons plus tard.
Le problème de la réinitialisation des mots de passe totalement dépendante de l'e-mail est que l'intégrité du compte du site, dont le mot de passe que vous essayez de réinitialiser, devient dépendante à 100 % de l'intégrité du compte de messagerie. Quiconque a accès à votre e-mail, a accès à n'importe quel compte qui peut être réinitialisé simplement en recevant un e-mail. Pour de tels comptes, l'e-mail est « la clé de toutes les portes » de votre vie en ligne.
L'une des façons de réduire ce risque est de mettre en œuvre un modèle de question et réponse secrètes. Sans aucun doute, vous les avez déjà vus : vous choisissez une question à laquelle vous êtes le seul à connaître la réponse, après quoi on vous la pose lorsque vous réinitialisez votre mot de passe. Cela vous donne la certitude que la personne essayant de réinitialiser le mot de passe est bien le propriétaire du compte. doivent Revenons à Sarah Palin : l'erreur était que les réponses à sa question/se questions secrètes pouvaient être trouvées facilement. En particulier, lorsque vous êtes une personnalité publique aussi importante, des informations telles que le nom de jeune fille de votre mère, l'historique éducatif ou des lieux où quelqu'un a pu vivre dans le passé ne sont pas vraiment secrètes. En fait, une grande partie peut être trouvée par presque n'importe qui. C'est exactement ce qui est arrivé à Sarah :
Le hacker David Kernell a accédé au compte de Palin en trouvant des détails sur sa biographie, comme son université et sa date de naissance, puis en utilisant la fonction de récupération de mots de passe oubliés pour les comptes Yahoo !.
Tout d'abord, c'est une erreur de conception de la part de Yahoo ! En posant de telles questions simples, l'entreprise a essentiellement sabordé la valeur de la question secrète, donc la protection de son système. Bien sûr, réinitialiser un mot de passe pour un compte de messagerie est toujours plus compliqué, car vous ne pouvez pas confirmer la propriété en envoyant un e-mail au propriétaire (sans avoir une seconde adresse), mais, heureusement, aujourd'hui, il n'y a pas tant de moyens d'appliquer un tel système.
Revenons aux questions secrètes : il existe une option permettant à l'utilisateur de créer ses propres questions. Le problème est que cela donne souvent des questions horriblement évidentes :
De quelle couleur est le ciel ?
Les questions qui mettent les gens dans l'embarras, lorsque pour s'identifier la question secrète utilise
une personne (par exemple, dans un centre d'appels) : Avec qui j'ai couché à Noël ?
Ou des questions franchement stupides :
Comment ça s'écrit 'mot de passe' ?
En ce qui concerne les questions secrètes, il est nécessaire de sauver les utilisateurs d'eux-mêmes ! En d'autres termes, la question secrète devrait être déterminée par le site lui-même, et encore mieux, poser
une série de questions secrètes, parmi lesquelles l'utilisateur peut choisir. Et pas seulement choisir une ; idéalement, l'utilisateur devrait choisir deux ou plusieurs questions secrètesau moment de l'inscription au compte. au moment de l'enregistrement du compte., qui seront ensuite utilisés comme deuxième canal d'identification. Avoir plusieurs questions augmente la confiance dans le processus de vérification et offre également une certaine variabilité (ne pas toujours montrer la même question), tout en garantissant un peu de redondance au cas où l'utilisateur légitime aurait oublié son mot de passe.
À quoi doit ressembler une bonne question secrète ? Cela dépend de plusieurs facteurs :
- Elle doit être brève — la question doit être claire et sans ambiguïté.
- La réponse doit être précise — nous n'avons pas besoin d'une question à laquelle différentes personnes peuvent répondre de manière différente.
- Les réponses possibles doivent être variées — une question sur la couleur préférée de quelqu'un ne laisse qu'un très petit sous-ensemble de réponses possibles.
- La recherche de la réponse doit être difficile — si la réponse peut facilement être trouvée par n'importe qui (pensons aux personnes occupant des postes élevés), alors c'est mauvais.
- La réponse doit être constant dans le temps — si l'on demande le film préféré de quelqu'un, après un an, la réponse peut être différente.
Comme cela se passe, il existe un site Web dédié aux bonnes questions, appelé . Certaines questions semblent tout à fait correctes, d'autres ne passent pas certains des tests mentionnés ci-dessus, en particulier le test de « facilité de recherche ».
Permettez-moi de vous montrer comment les questions secrètes sont mises en œuvre chez PayPal et, en particulier, quels efforts le site déploie pour l'identification. Plus haut, nous avons vu la page de lancement du processus (avec CAPTCHA), et ici nous montrerons ce qui se passe après que vous ayez saisi l'adresse e-mail et résolu le CAPTCHA :
En conséquence, l'utilisateur reçoit un e-mail tel que celui-ci :
Jusque-là, tout est plutôt normal, mais voici ce qui se cache derrière cette URL de réinitialisation :
Ainsi, les questions secrètes entrent en jeu. En fait, PayPal permet également de réinitialiser le mot de passe en confirmant le numéro de carte de crédit, donc il existe un canal supplémentaire auquel de nombreux sites n'ont pas accès. Je ne peux tout simplement pas changer le mot de passe sans répondre à les deux questions secrètes (ou sans connaître le numéro de la carte). Même si quelqu'un accède à mon e-mail, il ne pourra pas réinitialiser le mot de passe de mon compte PayPal, à moins de connaître un peu plus d'informations personnelles à mon sujet. Quelles informations ? Voici les options de questions secrètes proposées par PayPal :
La question de l'école et de l'hôpital peut sembler légèrement problématique en termes de simplicité de recherche, mais les autres ne sont pas si mauvais. Cependant, pour renforcer la sécurité, PayPal exige une identification supplémentaire pour modifications les réponses aux questions secrètes :
PayPal est un exemple plutôt utopique de réinitialisation de mot de passe sécurisée : il utilise des CAPTCHA pour réduire le risque de force brute, exige deux questions secrètes, puis nécessite un autre type d'identification complètement distinct juste pour changer les réponses - et cela après que l'utilisateur s'est déjà connecté. Bien entendu, c'est exactement ce que nous attendions de PayPal ; c'est une organisation financière qui traite d'importantes sommes d'argent. Cela ne signifie pas que chaque réinitialisation de mot de passe doit suivre ces étapes — dans la plupart des cas, c'est excessif — cependant, c'est un bon exemple pour les cas où la sécurité est une affaire sérieuse.
La commodité du système de questions secrètes est que si vous ne l'avez pas mis en œuvre dès le départ, vous pouvez l'ajouter plus tard, si le niveau de protection du service l'exige. Un bon exemple de cela est Apple, qui a récemment mis en place ce mécanisme [article écrit en 2012]. Ayant commencé une fois à mettre à jour l'application sur mon iPad, j'ai vu la demande suivante :
J'ai ensuite vu un écran où il était possible de choisir plusieurs paires de questions secrètes et de réponses, ainsi qu'une adresse e-mail de secours :
En ce qui concerne PayPal, les questions sont choisies à l'avance et certaines d'entre elles sont en réalité assez bonnes :
Chaque paire de trois questions et réponses représente un ensemble distinct de questions possibles, donc il existe suffisamment de façons de configurer le compte.
Un autre aspect à considérer concernant la réponse à la question secrète est le stockage. La présence de texte brut dans la base de données présente presque les mêmes menaces que dans le cas des mots de passe, à savoir qu'une fuite de la base de données révèle instantanément la valeur et expose non seulement l'application, mais aussi potentiellement d'autres applications utilisant les mêmes questions secrètes (c'est encore une fois ). Une des options consiste en un hachage sécurisé (algorithme robuste et sel cryptographiquement aléatoire), mais contrairement à la plupart des cas de stockage de mots de passe, il peut y avoir une raison valable pour que la réponse soit visible comme un texte brut. Un scénario typique est la vérification d'identité par un opérateur en direct au téléphone. Bien sûr, dans ce cas, le hachage est également applicable (l'opérateur peut simplement saisir la réponse mentionnée par le client), mais dans le pire des cas, la réponse secrète doit être stockée à un certain niveau de stockage cryptographique, même si c'est juste un chiffrement symétrique. En résumé : traitez les secrets comme des secrets!
Et le dernier aspect des questions et réponses secrètes est qu'elles sont plus vulnérables à l'ingénierie sociale. Essayer de soutirer directement le mot de passe d'un compte est une chose, tandis que de lancer une conversation sur ses études (une question secrète populaire) en est une autre. En réalité, vous pouvez tout à fait discuter avec quelqu'un de nombreux aspects de sa vie qui peuvent représenter une question secrète, sans éveiller de soupçons. Bien sûr, l'essence même de la question secrète est qu'elle est liée à l'expérience de vie de quelqu'un, donc elle est mémorable, et c'est là que réside le problème — les gens aiment parler de leur expérience de vie! Il y a peu de choses à y faire, sauf choisir des options de questions secrètes qui ont moins de probabilité d'être extraites par ingénierie sociale.
[La suite suit.]
En tant que publicité
VDSina propose des serveurs fiables , chaque serveur étant connecté à un canal Internet de 500 mégabits et protégé gratuitement contre les attaques DDoS!
Source : habr.com
