Pourquoi de nombreux sites Web masquent-ils des entrées lors de la saisie d'un OTP?
J'ai remarqué que sur de nombreux sites, lorsqu'ils demandent un mot de passe à usage unique (OTP) (généralement envoyé par SMS), l'entrée est masquée de la même manière qu'un champ de mot de passe.
Ma compréhension est qu'une fois qu'un OTP est utilisé, il n'est plus utile pour rien.
Y a-t-il une raison valable pour masquer l'entrée pour ces champs?
Je fonde ma réponse sur l'hypothèse qu'un mot de passe à usage unique est utilisé comme deuxième facteur, en plus d'une combinaison nom d'utilisateur/mot de passe traditionnelle. Si ce n'est pas le cas et que le mot de passe à usage unique est le seul facteur, alors Réponse de Gilles est certainement plus applicable.
Très probablement en raison de Cargo Cult Programming , ce qui signifie suivre aveuglément des modèles qui ont été observés ailleurs, sans comprendre la véritable signification derrière eux.
Un développeur peut voir le "mot de passe" dans "Mot de passe à usage unique" et le faire avec plaisir <input type="password">. Après tout, c'est pour ça que c'est là, non?
Y a-t-il un inconvénient?
Pour la sécurité, non. La divulgation d'un mot de passe à usage unique à un tiers (par exemple via navigation sur l'épaule ) n'est pas aussi problématique, car le mot de passe perd sa validité après une utilisation ou après un certain laps de temps.
Le seul inconvénient imaginable serait une expérience utilisateur moindre, car un utilisateur pourrait avoir du mal à s'assurer que ce qu'il a tapé correspond réellement au mot de passe qu'il a reçu.
La raison de masquer les mots de passe est d'empêcher la navigation sur l'épaule: une personne physiquement présente (ou une personne observant à travers une caméra) peut lire le mot de passe à l'écran. C'est également un risque pour un mot de passe à usage unique, mais dans une bien moindre mesure pour deux raisons: le mot de passe à usage unique n'est valide que pour une courte période, et il est affiché sur le périphérique OTP de toute façon. Mais c'est néanmoins un risque. Selon le type d'OTP, il peut rester valide pendant quelques minutes (s'il est basé sur le temps et que le serveur ne protège pas contre la relecture) ou jusqu'à ce que l'utilisateur légitime ait fini de le taper (s'il est basé sur une séquence ou sur le serveur protège contre la relecture). Souvent, l'écran du périphérique OTP est moins visible pour les surfeurs d'épaule que l'ordinateur où l'utilisateur entre dans le OTP.
Déclarer un champ comme mot de passe ne sert pas qu'à masquer les données: cela peut empêcher la copie dans le presse-papiers et peut empêcher l'application d'enregistrer l'OTP dans l'historique des entrées de formulaire. Aucun de ceux-ci ne présente aucun avantage en termes de sécurité, mais le fait d'omettre l'OTP de l'historique des entrées présente un avantage en termes de convivialité: cela évite de donner aux utilisateurs l'impression que l'OTP est une entrée valide plus tard.
Ce sont des raisons assez faibles. La raison principale est que les concepteurs de formulaires voient que l'entrée est un mot de passe quelconque et le déclarent donc comme mot de passe.
Spéculer sur le motif d'autres développeurs est peut-être une mauvaise utilisation du temps, mais je peux voir un avantage qui n'a pas été mentionné.
Psychologiquement, le faire ressembler à un mot de passe aide les gens à l'associer à la sécurité. Il transfère le message que nous avons poussé pendant des décennies à dire que "vous ne dites pas votre mot de passe aux gens" aux OTP et, espérons-le, aidera quelques autres utilisateurs à faire une pause et à se poser des questions lorsque Bob Hackerman leur téléphonera pour leur demander de confirmer le code à six chiffres qu'il vient d'envoyer. leur. L'utilisateur est généralement la partie la plus faible du système, ce qui semble être un endroit raisonnable pour investir.
Techniquement, il y a des inconvénients (comme le navigateur qui le stocke) et ce serait mieux avec un champ HTML dédié pour les OTP. Même si nous en avions un, il serait tout à fait raisonnable de le mettre en pointillé comme UX par défaut.
La raison de masquer l'entrée du champ peut être due à des schémas de programmation (comme indiqué @ MechMK1), car le développeur ne coderait pas un champ distinct pour chaque type d'authentification proposé, de sorte qu'il réutilise le champ avec un mot de passe de type. Ne pas le faire pourrait entraîner un ballonnement du code.
Un attaquant pourrait utiliser le mot de passe à usage unique lorsqu'il vous verrait le saisir.
Cela revient à la question du timing. S'il est un attaquant sophistiqué, il pourrait lire le mot de passe unique non caché et en même temps bloquer votre connexion réseau avant de frapper entrer. Ainsi, il peut lire le mot de passe à usage unique que vous tapez, vous empêcher d'envoyer le formulaire et utiliser le mot de passe à usage unique pour vous connecter comme vous.
Cela peut sembler très gênant, mais à notre avis, une implémentation sincère du Bureau du Procureur devrait s'en occuper. Comme l'a souligné @ MechMK1, l'OTP est - comme son nom l'indique - uniquement valide ne fois. Mais l'OTP n'est invalidé que lorsque le serveur le vérifie. Et comme mentionné, si l'attaquant peut vous empêcher d'envoyer l'OTP au serveur, l'OTP n'est pas invalidé et l'attaquant peut utiliser ce même OTP avant vous.