Authentification à deux facteurs
Tout ce que vous avez lu dans concerne l'identification basée sur ce que sait celui qui demande. Il connaît son adresse e-mail, sait comment y accéder (c'est-à-dire qu'il connaît son mot de passe) et sait les réponses aux questions secrètes.
La « connaissance » est considérée comme un facteur d'authentification ; les deux autres facteurs courants sont ce que vous avez, par exemple, un appareil physique, et qui vous êtes, par exemple, les empreintes digitales ou la rétine de l'œil.
Dans la plupart des cas, la mise en œuvre de l'identification biométrique est peu réalisable, surtout lorsqu'il s'agit de la sécurité des applications web, c'est pourquoi lors de l'authentification à deux facteurs (two factor authentication, 2FA), on utilise généralement le deuxième attribut — « ce que vous avez ». L'un des choix populaires pour ce second facteur est un jeton physique, par exemple, :
Un jeton physique est souvent utilisé pour l'authentification dans les VPN d'entreprise et les services financiers. Pour s'authentifier dans le service, il faut utiliser à la fois le mot de passe et le code sur le jeton (qui change souvent) en combinaison avec un code PIN. Théoriquement, pour s'identifier, un attaquant doit connaître le mot de passe, avoir le jeton, ainsi que connaître le code PIN du jeton. Dans un scénario de réinitialisation de mot de passe, le mot de passe est évidemment inconnu, mais posséder le jeton peut servir à confirmer la propriété du compte. Bien sûr, comme c'est le cas avec toute mise en œuvre de protection, , mais cela augmente certainement la barrière à l'entrée.
L'un des principaux problèmes de cette approche est le coût et la logistique de mise en œuvre ; nous parlons de la livraison d'appareils physiques à chaque client et de la formation de ceux-ci à ce nouveau processus. De plus, les utilisateurs doivent avoir sur eux l'appareil, ce qui n'est pas toujours le cas avec un jeton physique. Une autre option consiste à mettre en œuvre le deuxième facteur d'authentification par SMS, qui dans le cas d'une 2FA peut servir à confirmer que la personne effectuant le processus de réinitialisation a le téléphone mobile du propriétaire du compte. Voici comment Google le fait :
Il est également nécessaire d'activer , mais cela signifie qu'à la prochaine réinitialisation de mot de passe, votre téléphone mobile pourrait devenir un second facteur d'authentification. Laissez-moi démontrer cela avec mon iPhone pour des raisons qui deviendront bientôt claires :
Après avoir identifié l'adresse e-mail du compte Google, il établit que la 2FA est activée et nous pouvons réinitialiser le compte par vérification, qui est transmise par SMS au téléphone mobile du propriétaire du compte :
Nous devons maintenant choisir le début du processus de réinitialisation :
Cette action entraîne l'envoi d'un e-mail à l'adresse enregistrée :
Cet e-mail contient l'URL de réinitialisation :
Lorsque vous accédez à l'URL de réinitialisation, un SMS est envoyé et le site Web demande de le saisir :
Voici ce SMS :
Après l'avoir saisi dans le navigateur, nous revenons à l'étape classique de réinitialisation de mot de passe :
Cela peut sembler un peu verbeux, et c'est le cas, mais le formulaire confirme que la personne réinitialisant a accès à l'adresse e-mail et au téléphone mobile du propriétaire du compte. Cependant, cela peut être jusqu'à neuf fois plus sûr que de réinitialiser un mot de passe uniquement via e-mail. Cependant, il y a des problèmes…
Le problème concerne les smartphones. L'appareil montré ci-dessous ne peut authentifier qu'un seul facteur d'authentification — il peut recevoir des SMS, mais pas d'e-mails :
Cependant, cet appareil peut recevoir des SMS et recevoir des e-mails de réinitialisation de mot de passe :
Le problème est que nous considérons l'e-mail comme le premier facteur d'authentification, et le SMS (ou même une application générant des tokens) comme le second, mais aujourd'hui ils sont combinés dans un seul appareil. Cela signifie évidemment que si quelqu'un accède à votre smartphone, tout ce confort se réduit à un seul canal ; ce second facteur « ce que vous avez » signifie que vous avez aussi le premier facteur. Et tout cela est protégé par un PIN à quatre chiffres… si le téléphone a même un PIN. et il a été verrouillé.
Oui, la fonction 2FA implémentée par Google fournit effectivement une protection supplémentaire, mais elle n'est pas protégée contre l'« idiot », et ne dépend certainement pas de deux canaux entièrement autonomes.
Réinitialisation par nom d'utilisateur contre réinitialisation par adresse e-mail
Faut-il autoriser la réinitialisation uniquement par adresse e-mail ? Ou l'utilisateur doit-il avoir la possibilité de réinitialiser également par nom ? Le problème de la réinitialisation par nom d'utilisateur est qu'il n'y a pas moyen d'informer l'utilisateur d'un nom d'utilisateur incorrect, sans révéler que quelqu'un d'autre pourrait avoir un compte avec ce nom. Dans la section précédente, la réinitialisation par e-mail garantissait que le véritable propriétaire de cette adresse e-mail recevrait toujours des retours sans divulguer publiquement son existence dans le système. Avec seulement un nom d'utilisateur, cela n'est pas possible.
Ainsi, la réponse est brève : seulement par e-mail. Si vous essayez de réinitialiser uniquement avec le nom d'utilisateur, des situations se présenteront où l'utilisateur se demandera ce qui se passe, ou vous allez révéler l'existence de comptes. Oui, ce n'est qu'un nom d'utilisateur, pas une adresse e-mail, et oui, n'importe qui peut choisir n'importe quel nom d'utilisateur (disponible), mais il y a toujours une forte probabilité que vous révéliez indirectement les propriétaires de comptes en raison de la tendance des utilisateurs à réutiliser les noms.
Que se passe-t-il alors lorsque quelqu'un oublie son nom d'utilisateur ? Si nous supposons que le nom d'utilisateur n'est pas immédiatement une adresse e-mail (ce qui arrive souvent), le processus est similaire à celui du début de la réinitialisation de mot de passe — on saisit l'adresse e-mail, puis on envoie un message à cette adresse, sans révéler son existence. La seule différence est que cette fois, le message contient uniquement le nom d'utilisateur, et non l'URL de réinitialisation de mot de passe. Soit cela, soit l'e-mail indiquera qu'il n'y a pas de compte pour cette adresse.
Vérification d'identité et précision des adresses e-mail
Un aspect clé de la réinitialisation des mots de passe, et même probablement le plus aspect clé est la vérification de l'identité de la personne essayant de réinitialiser. S'agit-il réellement du propriétaire légitime du compte, ou quelqu'un essaie-t-il de le pirater ou de causer des désagréments au propriétaire ?
Il est évident que l'email est le canal le plus pratique et le plus répandu pour la vérification d'identité. Il n'est pas à l'abri d'un usage inapproprié ('par un novice'), et il existe de nombreux cas où la simple capacité à recevoir des courriers sur l'adresse du propriétaire du compte n'est pas suffisante lorsque l'on nécessite un haut degré de confiance dans l'identification (c'est pourquoi la double authentification est utilisée), mais presque toujours, il s'agit du point de départ du processus de réinitialisation.
Si l'email joue un rôle dans l'assurance, il faut d'abord s'assurer que l'adresse email est réellement correcte. Si quelqu'un fait une erreur de caractère, il est évident que la réinitialisation ne commencera pas. Le processus de vérification de l'email au moment de l'inscription est une manière fiable de vérifier la validité de l'adresse. Nous l'avons tous vu en pratique : vous vous inscrivez, on vous envoie un email avec une URL unique sur laquelle vous devez cliquer, ce qui confirme que vous êtes bien le propriétaire de cet email. L'impossibilité de se connecter au système jusqu'à ce que ce processus soit terminé garantit une motivation pour confirmer l'adresse.
Comme pour de nombreux autres aspects de la sécurité, ce modèle réduit l'utilisabilité au profit d'un niveau de sécurité accru en ce qui concerne la vérification de l'identité de l'utilisateur. Cela peut être acceptable pour un site que l'utilisateur apprécie hautement et qui ajoutera volontiers une étape supplémentaire au processus (services payants, banque, etc.), mais de telles choses peuvent repousser l'utilisateur s'il perçoit le compte comme 'jetable' et l'utilise simplement comme un moyen de commenter un post, par exemple.
Identification de l'initiateur du processus de réinitialisation
Il est clair qu'il existe des raisons d'un usage malveillant de la fonction de réinitialisation, et les attaquants peuvent l'exploiter de multiples façons différentes. Une astuce simple que nous pouvons utiliser pour aider à confirmer la source de la demande (cette astuce fonctionne généralement ) consiste à ajouter l'adresse IP du demandeur dans l'email de proposition de réinitialisation. Cela fournit au destinataire certaines informations pour identifier la source de la demande.
Voici un exemple de la fonction de réinitialisation que je suis en train d'incorporer dans ASafaWeb :
Le lien « find out more » (« En savoir plus ») redirige l'utilisateur vers le site , qui fournit des informations telles que l'emplacement et l'organisation du demandeur de reset :
Bien sûr, toute personne souhaitant cacher son identité a de nombreuses façons d'obfusquer sa véritable adresse IP, mais cela offre un moyen pratique d'ajouter une identification partielle du demandeur, et dans de la plupart des certains cas, cela vous donnera une bonne idée de qui effectuera la demande de réinitialisation de mot de passe.
Notification de changements par e-mail
Ce post est imprégné d'un thème — la communication ; informez le propriétaire du compte autant que possible sur chaque étape du processus, sans divulguer quoi que ce soit qui pourrait être utilisé à des fins malveillantes. C'est également vrai dans les situations où le mot de passe a effectivement changé — faites-le savoir au propriétaire !
Les raisons du changement de mot de passe peuvent provenir de deux sources :
- Changement de mot de passe après connexion, car l'utilisateur souhaite un nouveau mot de passe
- Réinitialisation du mot de passe sans connexion, car l'utilisateur l'a oublié
Bien que ce post soit principalement consacré à la réinitialisation, la notification dans le premier cas réduit le risque que quelqu'un change le mot de passe à l'insu du propriétaire légitime. Comment cela peut-il se produire ? Un scénario très courant est l'obtention du mot de passe du propriétaire légitime (mot de passe réutilisé, divulgué par une autre source ; mot de passe obtenu par keylogging ; mot de passe facilement devinable, etc.), après quoi l'attaquant décide de le changer, bloquant ainsi le propriétaire. Sans notification par e-mail, le véritable propriétaire ne sera pas au courant du changement de mot de passe.
Évidemment, dans le cas d'une réinitialisation de mot de passe, le propriétaire aurait déjà dû initier le processus lui-même (ou contourner les méthodes de vérification d'identité décrites ci-dessus), donc le changement ne devrait pas être une surprise pour lui, mais une confirmation par e-mail sera un retour positif et une vérification supplémentaire. De plus, cela assure la continuité avec le scénario décrit ci-dessus.
Oh, et au cas où ce ne serait pas encore évident — ne pas envoyer le nouveau mot de passe par e-mail ! Cela peut faire rire certains, mais :
Logs, logs, logs et encore quelques logs
La fonctionnalité de réinitialisation de mot de passe est attrayante pour les cybercriminels : l'attaquant souhaite soit accéder au compte d'une autre personne, soit simplement causer des désagréments au propriétaire du compte ou du système. Beaucoup des pratiques décrites ci-dessus permettent de réduire la probabilité d'abus, mais ne les empêchent pas, et elles n'empêcheront pas les gens d'essayer d'utiliser la fonction de manière non prévue.
Pour reconnaître un comportement malveillant, la journalisation est une pratique absolument précieuse, et je fais référence à une journalisation très détaillée. Enregistrez les tentatives de connexion échouées, les réinitialisations de mot de passe, les modifications de mot de passe (c'est-à-dire lorsque l'utilisateur est déjà connecté) et pratiquement tout ce qui peut vous aider à comprendre ce qui se passe ; cela sera très utile à l'avenir. Enregistrez même des parties du processus, par exemple, une bonne fonction de réinitialisation doit inclure l'initiation de la réinitialisation via le site web (enregistrez la demande et les tentatives de connexion pour réinitialiser avec un nom d'utilisateur ou une adresse électronique incorrects), enregistrez la visite du site à l'URL de réinitialisation (y compris les tentatives d'utilisation d'un token incorrect), puis notez dans le journal le succès ou l'échec de la réponse à la question secrète.
Quand je parle de journalisation, je ne fais pas seulement référence à l'enregistrement du fait que la page a été chargée, mais aussi à la collecte d'un maximum d'informations, si elles ne sont pas confidentielles. Les gars, s'il vous plaît, ne logez pas les mots de passe ! Dans les journaux, vous devez enregistrer l'identité de l'utilisateur authentifié (il sera authentifié s'il change un mot de passe existant ou tente de réinitialiser le mot de passe d'une autre personne après s'être connecté), tous les noms d'utilisateur ou adresses électroniques qu'il essaie, ainsi que tous les tokens de réinitialisation qu'il tente d'utiliser. Mais il vaut également la peine d'enregistrer dans les journaux des aspects tels que les adresses IP et, si possible, même les en-têtes des requêtes. Cela vous permet de recréer non seulement ce que l'utilisateur (ou l'attaquant) essaie de faire, mais aussi ce que qui il est. qui La délégation de responsabilité à d'autres prestataires.
Délégation de la responsabilité à d'autres exécutants
Si vous pensez que tout cela représente un énorme travail, vous n'êtes pas seul. En réalité, établir un système fiable de gestion des comptes est une tâche complexe. Ce n'est pas tant qu'elle soit techniquement difficile, mais plutôt qu'elle comporte de nombreuses spécificités. Cela ne se résume pas à une simple réinitialisation, il existe tout un processus d'inscription, de stockage sécurisé des mots de passe, de gestion de multiples tentatives de connexion incorrectes, etc. , mais au-delà de cela, il reste encore beaucoup à faire.
Aujourd'hui, il existe de nombreux fournisseurs tiers qui se chargent avec plaisir de toutes les difficultés et en abstraient tout cela dans un service géré. Parmi ces services, on trouve OpenID, OAuth et même Facebook. Certaines personnes (OpenID a d'ailleurs connu un grand succès sur Stack Overflow), toutefois, d'autres .
Sans aucun doute, un service comme OpenID résout de nombreux problèmes pour les développeurs, mais il est tout aussi certain qu'il en ajoute de nouveaux. Ont-ils un rôle? Oui, mais il est clair que nous n'observons pas une utilisation généralisée des services des fournisseurs d'authentification. Les banques, les compagnies aériennes et même les magasins — tous mettent en œuvre leur propre mécanisme d'authentification, et il est évident qu'il y a de très bonnes raisons à cela.
Réinitialisation malveillante
Un aspect important de chacun des exemples ci-dessus est que l'ancien mot de passe est considéré comme inutile uniquement après vérification de l'identité du propriétaire du compte.C'est crucial, car si le compte pouvait être réinitialisé à sans vérification d'identité, cela ouvrirait la porte à toutes sortes d'actions malveillantes.
Voici un exemple : quelqu'un participe à une vente aux enchères en ligne, et vers la fin du processus d'enchères, il bloque ses concurrents en initiant le processus de réinitialisation, les éliminant ainsi des enchères. Il est évident que si une fonction de réinitialisation mal conçue peut être exploitée de manière inappropriée, cela peut entraîner des conséquences sérieuses. Il convient de noter que le blocage des comptes par de fausses tentatives de connexion constitue une situation similaire, mais c'est un sujet pour un autre post.
Comme je l'ai mentionné précédemment, donner aux utilisateurs anonymes la possibilité de réinitialiser le mot de passe de n'importe quel compte simplement en connaissant son adresse e-mail crée une situation parfaite pour une attaque par déni de service. Ce n'est peut-être pas celui , dont nous avons l'habitude de parler, mais il n'existe pas de moyen plus rapide de bloquer l'accès à un compte que par le biais d'une fonction de réinitialisation de mot de passe mal conçue.
Le maillon le plus faible
D'un point de vue de protection d'un compte, tout ce qui est écrit ci-dessus est merveilleux, cependant vous devez toujours garder à l'esprit l'écosystème entourant le compte que vous protégez. Permettez-moi de donner un exemple :
ASafaWeb est hébergé sur un service incroyable fourni par AppHarbor. Le processus de réinitialisation du compte d'hébergement se déroule comme suit :
Étape 1 :
Étape 2 :
Étape 3 :
Étape 4 :
Après avoir lu toutes les informations précédentes, il est déjà facile de comprendre quels aspects nous mettrions en œuvre différemment dans un monde idéal. Cependant, je tiens à dire que si je publie un site similaire à ASafaWeb sur le service AppHarbor, puis que j'invente d'excellents mots de passe secrets et des réponses, que j'ajoute un deuxième facteur d'authentification et que je fais tout le reste correctement, cela n'annule pas le fait que le maillon le plus faible de tout le processus sera capable de tout casser. Si quelqu'un réussit à s'authentifier sur AppHarbor en utilisant mes informations, il pourra changer le mot de passe de n'importe quel compte ASafaWeb à sa guise !
L'essentiel est que la résilience de la mise en œuvre de la sécurité doit être considérée dans son ensemble : il faut modéliser les menaces de chaque point d'entrée du système, même s'il s'agit d'un processus superficiel comme la connexion à AppHarbor. Cela devrait me donner une bonne idée de la quantité d'efforts que je dois consacrer au processus de réinitialisation de mot de passe d'ASafaWeb.
Rassemblons tout
Ce post contient une grande quantité d'informations, donc je veux le concentrer dans un schéma visuel simple :
N'oubliez pas que vous devez effectuer une journalisation aussi détaillée que possible de chacun de ces points. Voilà, c'est simple !
Résultats
Mon post semble complet, cependant il existe de nombreux matériaux supplémentaires que je pourrais l'inclure, mais plutôt pour des raisons de concision : le rôle de l'adresse e-mail de secours, la situation dans laquelle vous perdez l'accès à l'e-mail associé au compte (par exemple, vous avez quitté votre emploi), etc. Comme je l'ai dit précédemment, la fonction de réinitialisation n'est pas si complexe, mais il existe de nombreux points de vue à ce sujet.
Même si la réinitialisation n'est pas si difficile, elle est souvent mal mise en œuvre. Plus haut, nous avons vu quelques exemples où l'implémentation peut a conduit à des problèmes, et il existe beaucoup plus de cas où une réinitialisation incorrecte vraiment a causé des problèmes. Récemment, il a été découvert que C'est un résultat négatif sérieux !
Alors, soyez prudents avec vos fonctions de réinitialisation, à différents niveaux, et lorsque vous concevez la fonction, ne retirez pas votre chapeau noir, car il y a de fortes chances que quelqu'un d'autre le mette !
En tant que publicité
VDSina offre des services peu coûteux avec un paiement journalier, chaque serveur est connecté à un canal Internet de 500 Mégabits et est protégé gratuitement contre les attaques DDoS !
Source : habr.com
