Question:
Pourquoi de nombreux sites Web masquent-ils l'entrée lors de la saisie d'un OTP?
Robin Salih
2019-09-26 21:09:17 UTC
view on stackexchange narkive permalink

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

D'après ce que je comprends, une fois qu'un OTP est utilisé, il n'est plus utile pour rien.

Y a-t-il une raison valable de masquer l'entrée pour ces champs?

Lorsque Facebook a commencé à accepter des mots de passe mal capitalisés, certaines personnes ont exprimé des inquiétudes quant à savoir si cela était sécurisé.Si un site cesse de cacher l'entrée dans un champ nommé "mot de passe", la même controverse s'ensuivra.
Pouvez-vous donner un exemple pour les sites?Facebook, Github, Azure, AWS, Google affichent tous les chiffres.
@eckes La solution 3D Secure de ma banque le fait.Chaque fois que j'utilise ma carte de débit, je suis redirigé vers cette page (* .arcot.com).https://imgur.com/a/RNMr555
Dans un grand formulaire comportant de nombreux champs, y compris le champ du mot de passe, un tiers peut voir le mot de passe et le soumettre avant que l'utilisateur ne le fasse.
@eckes Je l'ai vu dans quelques endroits, y compris Natwest Online banking.
Cinq réponses:
#1
+65
MechMK1
2019-09-26 21:43:56 UTC
view on stackexchange narkive permalink

Je base 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 traditionnelle de nom d'utilisateur / mot de passe. Si ce n'est pas le cas et que le mot de passe à usage unique est le seul facteur, alors la Réponse de Gilles est certainement plus applicable.


Très probablement à cause de la programmation Cargo Cult, qui signifie suivre aveuglément des schémas qui ont été observés ailleurs, sans en comprendre la véritable signification.

Un développeur peut voir le "mot de passe" "dans" Mot de passe à usage unique "et faites-le volontiers <input type =" password "> . Après tout, c'est pour ça que c'est là, non?

Y a-t-il un inconvénient?

Sur le plan de la sécurité, non. La divulgation d'un mot de passe à usage unique à un tiers (par exemple via la 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 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.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/99174/discussion-on-answer-by-mechmk1-why-do-many-websites-hide-input-when-entering-une).
Selon le schéma, les OTP ne sont pas qu'une seule fois.Par exemple, les jetons TOTP sont valides pendant 30 secondes, quel que soit le nombre de fois où vous utilisez réellement le jeton.Dans ce cas, le surf à l'épaule peut être un problème si le premier facteur (par exemple le mot de passe) a déjà été compromis.
@ChristopherSchultz Si elle est implémentée selon la [RFC] (https://tools.ietf.org/html/rfc6238#section-5.2) TOTP _is_ une fois: "Le vérificateur NE DOIT PAS accepter la deuxième tentative de l'OTP après la validation réussiea été émis pour le premier OTP ".
@AndrolGenhald Intéressant.Apparemment, j'avais manqué ce détail lors de la mise en œuvre de TOTP comme exemple à un moment donné.Cette exigence * RFC-MUST-NOT * rend difficile la mise en œuvre complète de la spécification dans les systèmes distribués.Je me demande combien d'implémentations sont réellement conformes.
@ChristopherSchultz - difficile mais pas impossible.L'une des choses que le battage médiatique de la blockchain a enseigné est qu'il est possible de développer des algorithmes de consensus robustes - quelque chose avec lequel les gens avaient du mal (traitant spécifiquement du problème du cerveau partagé)
@ChristopherSchultz certes, beaucoup de solutions ont été développées avant le battage médiatique de la blockchain - Paxos par exemple est assez ancien.Mais les algorithmes de consensus ont récemment suscité un regain d'intérêt avec la blockchain
La validation @AndrolGenhald "a été émise pour le premier" - le surfeur de l'épaule a encore le temps de le saisir avant l'utilisateur réel.C'est à dire.AVANT "la validation a été émise pour le premier".
@OlegV.Volkov Puisque nous parlons de l'entrée sur le site Web, le surfeur d'épaule ne peut évidemment pas entrer le code complet avant l'utilisateur réel (bien qu'il puisse potentiellement soumettre le formulaire avant l'utilisateur réel).Si vous parlez de surfer sur l'épaule du code affiché sur le périphérique OTP, cela n'a pas de rapport avec la question.
@slebetman Il s'agit d'un problème d'une durée de 30 secondes (pour les paramètres TOTP par défaut).La blockchain est peut-être la pire implémentation possible d'une contre-mesure pour ce vecteur d'attaque possible (pour presque tout d'ailleurs).
@ChristopherSchultz Je ne parle pas de blockchain.Je parle d'algorithmes de consensus qui sont antérieurs à la blockchain mais qui n'étaient peut-être pas assez connus jusqu'à ce que la blockchain les place au premier plan.Paxos par exemple a été publié en 1988 mais un logiciel tel qu'Elasticsearch (publié en 2010) avait toujours / a encore des problèmes de synchronisation asynchrone même s'il s'agit d'un problème résolu car ses développeurs ne savaient pas que de tels algorithmes existent mais il existe en fait toute une familled'algorithmes.Les blockchains ne seraient pas possibles sans algorithmes de consensus
#2
+31
Gilles 'SO- stop being evil'
2019-09-26 21:42:15 UTC
view on stackexchange narkive permalink

La raison de masquer les mots de passe est d'empêcher le surf sur l'épaule: une personne physiquement présente (ou une personne observant à travers une caméra) peut être en mesure de lire le mot de passe à l'écran. C'est aussi 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 pendant une courte période, et il est quand même affiché sur le périphérique OTP. 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 saisir (s'il est basé sur une séquence ou sur le serveur protège contre la relecture). Souvent, l'écran de l'appareil OTP est moins visible pour les surfeurs d'épaule que l'ordinateur sur lequel l'utilisateur entre l'OTP.

Déclarer un champ comme mot de passe fait autre chose que masquer les données: cela peut empêcher la copie vers le presse-papiers et peut empêcher l'application d'enregistrer l'OTP dans un historique d'entrée de formulaire. Aucun de ceux-ci n'a aucun avantage en termes de sécurité, mais 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 et donc le déclarent comme mot de passe.

En supposant qu'un mot de passe à usage unique est utilisé comme deuxième facteur, je le considérerais beaucoup moins comme un risque, car quelqu'un devrait également être en possession du facteur principal.Mais c'est un bon point, j'ajouterai cela à ma réponse en conséquence.
L'utilisation de `autocomplete =" one-time-code "` omet l'OTP de l'historique sans être hostile à l'utilisateur.
Cela peut sembler un peu comme un niveau de paranoïa James Bond, mais la fiabilité du réseau est une considération pour la sécurité du surf sur l'épaule.Nous poussons les gens sur https pour empêcher les attaques MTM automatisées, mais aucune cryptographie ne garantit que le réseau ne tombe pas en panne.Un attaquant peut être capable de voir le code, de brouiller le signal (par exemple, de débrancher le routeur) et de passer deux bonnes minutes dans la confusion pour le mettre par lui-même.
Ils peuvent bien sûr ne pas avoir à le faire.Je pensais juste que cela valait la peine de le mentionner au cas où quelqu'un estime "au moment où ils peuvent le voir, il est trop tard pour faire quoi que ce soit avec"
Un serveur qui ne protège pas contre les OTP relus est à peu près cassé par définition ...
@ilkkachu Non, pas nécessairement.De nombreux systèmes «OTP» sont basés sur le temps et ont plusieurs points d'authentification, créant une fenêtre de temps pendant laquelle un OTP non seulement _peut_ être accepté plusieurs fois, mais _devrait_ être accepté plusieurs fois (car l'utilisateur se connecte à différents points d'authentification dansla même courte fenêtre de temps).
@Gilles, Je ne doute pas qu'ils existent, mais cela semble vraiment violer la propriété "ponctuelle" qui est là dans ce que OTP est l'abréviation de ... J'ai toujours pensé que l'idée était qu'une fois un mot de passe unique étaitutilisé, il doit être considéré comme ayant fui et ne doit donc pas être accepté à nouveau.Ce qui peut signifier que vous aurez besoin d'un système centralisé pour suivre l'OTP utilisé, et que vous devriez avoir un système d'authentification unique pour vous authentifier dans plusieurs systèmes en même temps, mais c'est ce que vous obtenez.Réaccepter le même OTP sonne juste comme inviter un espion à se connecter après que vous ...
@ilkkachu Pas vraiment.Le point principal des méthodes d'authentification communément appelées «OTP» aujourd'hui est d'être un facteur d'authentification de ce que vous avez: c'est une preuve d'accès physique à un appareil (généralement votre téléphone mobile ou votre SIM).Le risque contre lequel ils se protègent est que le facteur «ce que vous savez» a été divulgué.Sans aucun doute, il serait préférable que ceux basés sur le temps ne soient pas appelés «OTP», mais le nom reste populaire même s'il est inexact.
@Gilles, Je pense que c'est ce que faisait ilkkachu.Ils sont considérés comme un facteur de ce que vous avez, mais s'ils sont vulnérables au reniflement et aux rediffusions, ils ne prouvent pas ce que vous avez.
@Josiah Non, cela ne suit pas.Les mots de passe sont également vulnérables au reniflement et aux rediffusions, mais ils prouvent ce que vous savez.Les jetons OTP sont vulnérables aux vols, mais ils prouvent ce que vous avez.
@Josiah, Eh bien, pour être honnête, si vous pouvez attaquer en temps réel, vous pouvez toujours renifler un OTP, il vous suffit de l'utiliser avant qu'il n'atteigne le serveur.Vous n'avez même pas besoin de brouiller le réseau si vous êtes juste plus rapide que l'utilisateur.Bien sûr, si l'OTP est valide même après avoir frappé le serveur, cela rend les choses beaucoup plus faciles car il n'y a pas de course et l'utilisateur n'obtient pas d'erreur de connexion.
@Gilles, franchement, je ne comprends toujours pas pourquoi on implémenterait un OTP basé sur le temps et n'invaliderait pas l'OTP actuel lorsqu'il est utilisé.Si vous avez plusieurs points d'authentification, ils font tous deux partie du même système, et vous pourriez juste avoir une seule authentification pour accorder l'accès à tous (répéter le même code trois fois à trois endroits différents ne semble pas plus utile que de simplemententrer une fois).
... Ou les systèmes sont indépendants, auquel cas ils ne peuvent invalider l'OTP utilisé que pour eux-mêmes, et la connexion avec le même code fonctionne.C'est un peu comme utiliser le même mot de passe dans plusieurs systèmes, sauf que c'est l'OTP cette fois.Ensuite, nous pouvons discuter si c'est un problème ou non, mais en pensant à quelque chose comme TOTP, il y a une clé partagée qui génère les OTP, et si cela fuit de l'un des systèmes, alors cela compromet les autres aussi, comme si un mot de passe d'une manière ou d'une autrese fait fuir de la base de données de mots de passe ...
#3
+16
Josiah
2019-09-27 12:07:34 UTC
view on stackexchange narkive permalink

Spéculer sur les motivations 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, faire ressembler un mot de passe aide les gens à l'associer avec sécurité. Il transfère le message que nous avons poussé pendant des décennies que "vous ne dites pas aux gens votre mot de passe" aux OTP, et, espérons-le, aide quelques autres utilisateurs à faire une pause et à se poser des questions lorsque Bob Hackerman les appelle en leur demandant 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, donc cela 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é aux OTP. Même si nous en avions un, il serait tout à fait raisonnable de le faire figurer comme UX par défaut.

J'aime ce raisonnement.Je sais ce qu'ils sont et les problèmes de sécurité habituels.La mamie de Joe Blogg d'autre part.Tout ce qui aide les moins instruits à la sécurité à être plus en sécurité est une bonne chose.
#4
  0
Hightown Hill
2019-09-28 18:10:11 UTC
view on stackexchange narkive permalink

La raison du masquage de l'entrée du champ est peut-être due à des modèles de programmation (comme @ MechMK1 l'a indiqué), car le développeur ne coderait pas un champ séparé pour chaque type d'authentification proposé afin de réutiliser le champ avec le type de mot de passe. Ne pas le faire pourrait entraîner un gonflement du code.

#5
  0
cornelinux
2019-09-29 04:13:00 UTC
view on stackexchange narkive permalink

Un attaquant pourrait utiliser le mot de passe à usage unique quand il vous voit le saisir.

Cela revient à une question de timing. S'il s'agit d'un attaquant sophistiqué, il pourrait lire le mot de passe à usage unique non caché et en même temps bloquer votre connexion réseau avant d'appuyer sur entrée . Il peut donc lire l'OTP que vous tapez, vous empêcher d'envoyer le formulaire et utiliser l'OTP pour vous connecter en tant que vous.

Cela peut sembler très gênant, mais à notre avis, une implémentation OTP sincère devrait prendre soin de Comme l'a souligné @ MechMK1, l'OTP n'est - comme son nom l'indique - valide qu'une 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 cet OTP même avant vous.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...