Flux de processus de récupération de mot de passe / question de récupération

Question

Je crée une application où l'utilisateur pourra récupérer son mot de passe à partir d'un "mot de passe oublié?" lien. Une fois que l'utilisateur a cliqué sur le lien, on lui présente ses questions de récupération qu'il aurait remplies lors du processus d'enregistrement du compte. S'ils devaient répondre correctement aux questions, ils recevraient un e-mail avec un nouveau mot de passe temporaire qu'ils mettraient à jour lors de la connexion.

Mon problème est sur l'écran de question de récupération. Si l'utilisateur ne se souvient pas de ses questions de récupération, existe-t-il une meilleure pratique pour permettre à l'utilisateur de réinitialiser ses questions sans obtenir son mot de passe au préalable?

Nous pensons que cela pourrait devenir un problème de support client où l'utilisateur devrait appeler pour une réinitialisation de la question de récupération, mais je trouve cela inefficace et incommode pour l'utilisateur et l'équipe de support. Existe-t-il un processus dont tout le monde est conscient qui pourrait résoudre ce problème et permettre à l'utilisateur de réinitialiser ses questions de récupération, ce qui lui permettrait de réinitialiser son mot de passe.

Devin · Accepted Answer

J'ai écrit quelques articles sur ce sujet (en espagnol). La réponse évidente serait: tiliser l'authentification multifacteur . Je méprise vraiment cette approche. Dans ces articles, j'ai démontré avec de vrais cas d'utilisateurs qu'ils ne sont pas nécessairement plus sûrs, mais ils mènent toujours à des expériences utilisateur HORRIBLES.

Sans entrer dans les détails, permettez-moi de le dire aussi simplement que ceci: si vous souhaitez effectuer une action sur votre appareil et que vous êtes invité à effectuer des actions supplémentaires sur un autre appareil, vous ' re rupture de la plupart des heuristiques UX. Aussi simple que cela. C'est peut-être plus sûr, mais la convivialité sera un cauchemar (cas simple: que se passe-t-il si vous n'avez pas d'autre appareil à portée de main?)

D'autres approches

Le moyen le plus sûr, le plus sécurisé et le plus utilisable est de permettre aux utilisateurs d'utiliser des clés et des questions de récupération dont ils pourront réellement se souvenir. Si vous avez besoin de vos utilisateurs de noter leurs informations d'accès, la sécurité sera alors gravement compromise. Pourtant, les questions de sécurité sur la plupart des systèmes sont devenues si folles que la plupart des utilisateurs devront les noter!

Vérifiez l'image ci-dessous:

la passe stupidement facile à retenir est presque impossible à briser. Le soi-disant bon prendrait 3 jours. En supposant que l'utilisateur s'en souvienne!

La convivialité et l'angle CX

Comme vous l'avez dit à juste titre, cela pourrait devenir un véritable fardeau pour CX. Vous devrez déployer plus d'efforts et plus de personnes pour un problème qui n'aurait jamais dû exister! Mais ce n'est pas le seul problème: si en tant qu'utilisateur, je dois contacter le service client ou demander un nouveau mot de passe chaque fois que je me connecte à mon compte, c'est juste une question de temps avant d'arrêter d'utiliser le service

Ne donnez pas l'impression stupide à l'utilisateur: une leçon d'expérience utilisateur

Le point: si un client n'est pas satisfait d'un produit ou d'un site Web, vous les avez perdus. Vous ne pouvez pas les récupérer avec cette approche, car cela les rend simplement stupides. Les clients veulent acheter un produit et j'en ai fini avec lui; si cela se transforme en une longue expérience qui nécessite trop de soutien, c'est un produit dont ils ne seront jamais satisfaits.

Alors que faire?

Cela dépendra entièrement de vous et de votre configuration, mais je recommanderais les conseils suivants:

Les actions doivent être effectuées sur le même appareil. Toujours. Pas exception.
Si un utilisateur doit vous appeler pour effectuer l'action la plus simple ( par exemple: entrer dans votre site, doh !) ... vous êtes sur le chemin de la perdre
Permet de réutiliser les mots de passe. Il y a une raison pour laquelle les utilisateurs les ont choisis en premier lieu.
Si vous utilisez des questions de récupération, les rendent très faciles à mémoriser . Je dois vraiment faire un effort pour me souvenir de mon premier nom d'école, ou du nom de mon premier animal de compagnie (était un chien, un chat?). Au lieu de cela, proposez à l'utilisateur de créer ses propres réponses: "veuillez créer une question de sécurité dont la réponse n'est connue que de vous"
Utilisez l'automatisation. Si vous identifiez l'appareil et l'emplacement, allez-y doucement, un "demander un nouveau mot de passe par mail" devrait suffire.
Les utilisateurs ne se plaignent jamais de sécurité. Les seuls à se plaindre sont les parties prenantes, principalement basées sur des légendes urbaines
Pesez le pour et le contre. En supposant que le compte d'un utilisateur est affecté ... quel est le pire qui pourrait arriver? Y a-t-il des données sensibles? Ou est-ce juste "Facebook comme" des trucs?
Une fois que vous avez fait ce qui précède, pesez comment la convivialité du système sera affectée
N'oubliez pas: la sécurité est votre responsabilité, pas la faute de vos utilisateurs!

Craine · Answer

Le problème avec les questions de sécurité

Bien qu'il puisse sembler que les questions de sécurité soient quelque chose que vous voudriez implémenter dans votre application pour fournir une couche de sécurité supplémentaire, vous n'ajoutez pas vraiment de valeur à la sécurité des comptes de vos utilisateurs. ne étude de Google a montré que dans leur très large base d'utilisateurs, les questions de sécurité étaient largement inefficaces pour fournir des couches de sécurité supplémentaires, car les réponses étaient soit:

Oublié

La mémorisation des questions diminue considérablement avec le temps. Par exemple, le taux de réussite de la question "Nourriture préférée?" est de 74% après un mois, 53% après 3 mois et à peine 47% après un an (section 4.2).
Les réponses étaient accessibles au public

Réponses accessibles au public. Rabkin a constaté que 16% des questions avaient des réponses régulièrement répertoriées publiquement dans les profils de réseaux sociaux en ligne [27]. Même si les utilisateurs gardent les données privées sur les réseaux sociaux, les attaques par inférence permettent d'approximer les informations sensibles provenant des amis d'un utilisateur [24]. D'autres questions peuvent être trouvées dans des documents accessibles au public. Par exemple, au moins 30% des noms de jeune fille des mères des résidents du Texas peuvent être déduits des registres de naissance et de mariage [15].
Les réponses étaient suffisamment courantes sur le plan statistique pour pouvoir être devinées rapidement

Les attaques statistiques contre des questions secrètes représentent un risque réel car il existe des réponses communes partagées entre de nombreux utilisateurs. Par exemple, en utilisant une seule supposition, un attaquant aurait un taux de réussite de 19,7% pour deviner les réponses des utilisateurs anglophones à la question "Nourriture préférée?" ... Avec 10 suppositions, un attaquant pourrait deviner 39% des réponses des utilisateurs de langue coréenne à "Ville de naissance?" (Section 3.1).

De plus, si vous souffrez d'une violation de données et que les réponses aux questions fuient, vous êtes dans un tas de mauvaise presse (citation de wired.com article ci-dessous):

"Désolé, mais si vous avez un compte Yahoo, vous devrez trouver une nouvelle mère et avoir grandi dans une autre rue", Matt Blaze, informaticien à l'Université de Pennsylvanie raillé sur Twitter après les données de Yahoo annonce de violation.

Une meilleure solution UX

Étant donné que vous vous basez déjà sur l'hypothèse qu'un utilisateur doit avoir accès à son adresse e-mail enregistrée pour réinitialiser son mot de passe (en lui envoyant un mot de passe en texte temporaire), vous feriez mieux de supprimer complètement les questions de sécurité et de passer à une réinitialisation basée sur des jetons processus. Pour l'utilisateur, le processus de réinitialisation du mot de passe devrait ressembler à ceci:

L'utilisateur oublie le mot de passe et envoie un e-mail sous forme de mot de passe oublié
L'utilisateur reçoit un e-mail avec un lien de réinitialisation de mot de passe
L'utilisateur clique sur le lien de réinitialisation du mot de passe et se voit présenter un formulaire de réinitialisation du mot de passe
L'utilisateur entre le nouveau mot de passe souhaité dans le formulaire et le soumet
L'utilisateur se connecte à l'application avec un nouveau mot de passe

Sur le backend, votre application devrait effectuer les opérations suivantes:

Lorsqu'un utilisateur soumet une demande de "mot de passe oublié":
une. L'application génère un jeton aléatoire et un horodatage d'expiration et les stocke dans la base de données
b. L'application envoie un e-mail à l'utilisateur avec le jeton aléatoire et l'identifiant de compte (e-mail ou identifiant, par exemple) dans le lien de réinitialisation en tant que paramètres d'URL
L'identifiant de compte et le jeton de réinitialisation sont placés dans des champs de formulaire masqués sur le formulaire de réinitialisation
L'utilisateur soumet un formulaire de réinitialisation: a. L'application vérifie que le jeton de réinitialisation correspond à celui stocké dans la base de données pour cet identifiant de compte spécifique b. L'application vérifie que l'heure actuelle n'est pas après l'horodatage d'expiration du jeton de réinitialisation c. L'application hache le mot de passe soumis et le stocke dans la base de données d. (facultatif, mais bonne pratique) L'application stocke un horodatage et d'autres informations d'identification sur la demande qui a soumis la réinitialisation du mot de passe

Du point de vue d'un utilisateur, il s'agit d'un système beaucoup plus utilisable. Il leur suffit de connaître l'adresse e-mail avec laquelle ils se sont inscrits et la sécurité technique du processus de réinitialisation (jetons de réinitialisation limités dans le temps, longs et générés de manière aléatoire) est résumée dans quelque chose avec lequel ils n'ont pas besoin d'interagir. Vous êtes mieux parce que vous stockez moins de données personnellement identifiables (une préoccupation avec le RGPD qui entrera en vigueur l'année prochaine), vous n'avez pas besoin que les utilisateurs contactent le service client pour essayer de s'identifier autrement.

Si la sécurité du compte et la vérification supplémentaire vous préoccupent beaucoup, vous devez prendre le temps de mettre en œuvre une deuxième vérification hors bande, comme une adresse e-mail de récupération ou un numéro de téléphone pour SMS livraison de un deuxième jeton.

Lecture supplémentaire:

Secrets, mensonges et récupération de compte: leçons de l'utilisation des questions de connaissances personnelles chez Google - Google
Il est temps de tuer les questions de sécurité - Ou d'y répondre par des mensonges - Filaire
7 raisons pour lesquelles les questions de récupération de mot de passe sont pires qu'inutiles - Dashlane

NB4 · Answer

Envoyez OTP sur le numéro de mobile enregistré ou identifiant de l'e-mail de récupération qui a été utilisé au moment du processus d'inscription. Vous pouvez demander à l'utilisateur de sélectionner l'une des options ci-dessus.

Je suis d'accord avec Devin points

Si vous utilisez des questions de récupération, rendez-les très faciles à retenir. Je dois vraiment faire un effort pour me souvenir de mon premier nom d'école, ou du nom de mon premier animal de compagnie (était un chien, un chat?). Au lieu de cela, proposez à l'utilisateur de créer ses propres réponses: "veuillez créer une question de sécurité dont la réponse n'est connue que de vous"