Question:
Pourquoi les boîtes de mot de passe sont-elles toujours masquées alors que les autres données sensibles ne le sont pas?
GGMG-he-him
2016-11-05 09:56:18 UTC
view on stackexchange narkive permalink

Pour autant que je sache, les champs de mot de passe et les codes PIN sont toujours masqués d'une manière ou d'une autre afin d'éviter que les gens ne regardent par-dessus votre épaule lorsque vous les saisissez. Cependant, d'autres informations importantes que je saisis dans un formulaire Web (numéro de carte de crédit, numéro de sécurité sociale, etc.) que je voudrais également protéger contre les rubbernecking ne sont pratiquement jamais masquées.

À titre d'exemple concret, la saisie de votre mot de passe de connexion dans Steam ou Amazon est correctement masquée, mais la saisie de votre numéro de carte de crédit lors d'un achat est révélée en texte clair. Intuitivement, vous avez l'impression de vouloir effacer tout ce qui pourrait être volé, y compris les informations de carte de crédit.

Y a-t-il une raison particulière pour laquelle seuls les mots de passe et aucune autre donnée sensible sont généralement masqués?

Je suppose que c'est principalement la tradition et les attentes des utilisateurs, les sites Web ne suppriment les mots de passe que parce que les utilisateurs s'attendent à ce que les mots de passe soient vides puisque c'est toujours comme ça, mais c'est une question sacrément intéressante
Les informations de carte de crédit ne sont pas censées être secrètes, sinon comment vous feriez un achat sans communiquer les détails de votre carte.Le mot de passe, d'une autre part, est destiné à ne pas être divulgué, c'est la seule information qui vous permet de vous authentifier auprès de votre service en ligne.
@trallgorm: entièrement d'accord.Remarque: L'effacement des mots de passe a reçu une presse négative de différents côtés (personnes d'interface et infosec) depuis un certain temps, si je me souviens bien, c'est principalement parce qu'il rend la saisie de mots de passe longs et donc plus sécurisés plus difficile.Certains sites proposent désormais un bouton pour débloquer le mot de passe pour cette raison.
Certains sites font des champs vides autres que les mots de passe.Le code de sécurité de votre carte de crédit (CVV2) étant le plus courant.C'est l'exception plutôt que la règle.
La plupart des gens utilisent des mots de passe de merde que quelqu'un pourrait facilement voir et se souvenir, mais la plupart des gens ne peuvent pas mémoriser un numéro à 16 chiffres en peu de temps à vue seulement.
Juste un aparté sur ce truc de "surf à l'épaule".Si je mets mon téléphone en enregistrement vidéo et qu'il vous enregistre en vous connectant à votre ordinateur, je peux déterminer image par image vos frappes avec un très haut degré de précision.Les champs de mot de passe vides n'empêchent donc que les menaces * très occasionnelles *.
C'est une question dénuée de sens.La seule réponse possible peut être `` parce que c'est la façon dont ils l'ont conçu '' dans chaque cas individuel, et il n'est pas impossible que vous puissiez trouver un cas où le champ du mot de passe * n'est pas * effacé, il y a donc probablement une fausse prémisseproblème.
associé http://security.stackexchange.com/questions/127063/is-pin-affective-security-for-credit-cards-considering-its-not-always-needed
@Jase voulez-vous dire * votre * ordinateur dans un lieu public?Parce que si le propriétaire d'un ordinateur public voulait ces données, il installerait simplement un leylogger, et peu importe les symboles affichés.
@paj28 CVV fonctionne parce qu'il est très court, et bien que l'utilisateur soit susceptible de le lire sur la carte, il est généralement suffisamment petit pour que vous remarquiez que quelqu'un le lit.Mais cela ajoute probablement très peu de sécurité
La saisie d'un mot de passe devant quelqu'un d'autre est une situation courante.La saisie d'un numéro de carte de crédit ou d'un numéro d'assurance sociale ne l'est pas.Pourquoi la réponse doit-elle être complexe?
Sept réponses:
Out of Band
2016-11-05 15:08:37 UTC
view on stackexchange narkive permalink

Je ne pense pas qu'il s'agisse d'informations secrètes ou sensibles, par exemple "les informations secrètes sont masquées et les informations sensibles ne le sont pas". (la distinction est problématique; de ​​nombreux secrets doivent également être partagés).

Je pense que les informations cc et ssn ne sont pas effacées pour plusieurs raisons. Ce ne sont pas des faits concrets, mais en voici quelques-uns:

  1. Faire ce que tout le monde fait, sans surprendre l'utilisateur. Les mots de passe sont venus bien avant les formulaires Web et étaient déjà masqués. Ainsi, lorsqu'ils étaient utilisés dans les formulaires de connexion, ils étaient également masqués. Lorsque les affaires et l'administration en ligne sont apparues, l'état de la technique (formulaires papier) exigeait la saisie non masquée d'informations sensibles (évidemment), les formulaires Web ont donc fait le même choix.

  2. Ce serait très facile de faire une erreur et de saisir un mauvais numéro si vous ne voyez pas ce que vous avez tapé. Dans le cas d'un mot de passe erroné, ce n'est que légèrement ennuyeux et vous obtenez un retour instantané; dans le cas d'autres données sensibles erronées, cela pourrait avoir d'autres conséquences qui ne sont pas immédiatement claires (comme une demande à un bureau gouvernemental étant refusée en raison d'un mauvais SSN ou d'un paiement non effectué - bien que dans les cas cc et ssn , ceci est généralement couvert en vérifiant si la somme de contrôle est correcte et en fournissant un retour immédiat si ce n'était pas le cas)

  3. Beaucoup de gens ne connaissent pas leur numéro de cc de mémoire et copient il descend de la carte de crédit réelle. Donc, le numéro est là pour être vu par un spectateur de toute façon; effacer le champ de saisie n'aiderait pas beaucoup à protéger le numéro du côté client et ne mériterait donc pas les difficultés supplémentaires causées par 2.

  4. Impact - Un numéro cc volé n'a pas nécessairement le même impact qu'un mot de passe volé, surtout si vous considérez que les informations volées en regardant par-dessus votre épaule seraient très probablement volées par des personnes qui vous connaissent (collègues de travail, membres de la famille, camarades de classe, etc.) et veulent votre mot de passe pour une raison très spécifique qui aurait des conséquences personnelles. OTOH, même s'ils étaient intéressés par votre numéro de cc, vous n'auriez pas à subir de dommages financiers car la société cc le couvrirait probablement. Pour la même raison, cela ne vous dérange pas de laisser un serveur ou un vendeur voir votre carte de crédit, même s'il pourrait la copier et la vendre à quelqu'un d'autre ...

Le numéro 4 peut cependant ne pas s'appliquer à d'autres types d'informations sensibles.

Exactement.Masquer des champs comme ceux-ci serait un cauchemar d'utilisabilité.
Les numéros de carte de crédit (en fait les cartes de paiement, qui incluent également la plupart des cartes de débit et de cadeau) ont une somme de contrôle `` Luhn '', et dans la plupart des transactions, ils sont envoyés en quelques minutes à l'émetteur, avec le nom et le CVV2 et / ou l'adresse (AVS) et vérifiés.(États-Unis) Le SSN n'a pas de redondance et, dans certaines situations courantes, comme un dépôt bancaire ou une demande de prestations, il peut ne pas être vérifié pendant des jours ou des semaines - ou pas du tout en raison des restrictions sur les personnes pouvant utiliser les services de vérification.La SSA et l'IRS ont besoin de systèmes entiers pour corriger les SSN «inexacts» - bien que cela inclut à la fois des erreurs et des fraudes intentionnelles.
@PeriataBreatta Ne mettez pas l'UX au-dessus de la sécurité comme il l'a été dans le passé
@cat Inversement, rendre l'UX plus difficile qu'il ne doit l'être au nom de la sécurité n'est pas non plus une très bonne idée, car cela conduit les utilisateurs à contourner activement la sécurité pour atteindre les fonctionnalités qu'ils souhaitent.Il doit y avoir un équilibre.
Bruce Schneier a une vision intéressante de ce que j'aime vraiment: [Arrêtez d'essayer de réparer l'utilisateur] (https://www.schneier.com/blog/archives/2016/10/security_design.html)
@cat N'est-il pas vrai que "la sécurité au détriment de la convivialité se fait au détriment de la sécurité?"
Au moins dans mon pays, un numéro de carte de crédit n'est pas une information sensible (il est même imprimé sur chaque reçu lorsque vous utilisez la carte dans le monde réel).L'utilisation du numéro dans une transaction en ligne n'est généralement pas suffisante - vous devez confirmer un code temporaire reçu par smartphone.Donc pas besoin de le cacher
"de nombreux secrets doivent être partagés aussi" si tel est le cas, alors ce ne sont pas des secrets.Les mots de passe, les CVV, les codes PIN des cartes de débit sont des secrets, vous n'aurez jamais à les partager car ils autorisent une transaction, seul le propriétaire devrait y avoir accès.
Vous et moi pouvons partager un secret que nous ne disons à personne d'autre (je suis en fait Batman, et seul vous, mon fidèle acolyte, le saviez jusqu'à maintenant).Certains documents sont classés «top secret», mais cela ne signifie pas qu'une seule personne y a accès.Les mots de passe et les codes PIN des comptes utilisateur se trouvent être des secrets qui n'ont pas besoin d'être partagés avec qui que ce soit, comme vous le faites remarquer correctement (même si je n'aurais aucun problème à faire confiance à ma femme avec mon code PIN de carte de débit, puisque nous partageonsle même compte bancaire de toute façon ...).
C'est la bonne réponse.Bien que mon numéro de carte de crédit soit une information sensible, ce n'est pas une information secrète.Un mot de passe est quelque chose que je sais.Même le site Web ne connaît pas mon mot de passe.Alors qu'il connaît ma carte de crédit.La banque connaît mon numéro de carte de crédit.Ce n'est donc pas du tout un secret.
user1301428
2016-11-05 13:43:45 UTC
view on stackexchange narkive permalink

En effet, nous traitons ici de deux types d'informations: informations sensibles vs informations secrètes .

  • Les informations sensibles sont des données qui ont une certaine importance du point de vue de la sécurité / confidentialité, et qui pourraient certainement causer des problèmes si elles tombaient entre de mauvaises mains. Cependant, les données telles que votre SSN, numéro de carte de crédit, photo, etc. ne sont pas secrètes: un tiers devra y accéder, que ce soit pour traiter une commande que vous avez passée ou pour confirmer votre identité.

  • Les informations secrètes , en revanche, sont des informations auxquelles personne n'aura jamais besoin d'accéder, pour quelque raison que ce soit. Personne ne devrait avoir besoin de votre mot de passe pour faire quoi que ce soit, donc ce champ est généralement masqué.

Idéalement, vous voudriez que tout soit masqué, mais il y a des problèmes d'utilisabilité à considérer si vous fais le. À la fin de la journée, vous devrez toujours faire des compromis, et l'utilisation de ces deux catégories comme filtre n'est qu'une façon courante d'y parvenir.

@PascalSchuppli vrai, ils ne devraient pas.Cela me rappelle le débat sur le chiffrement de la base de données entière par rapport aux colonnes sensibles.Mais alors, tout pourrait devenir trop sensible: personnellement, je considère mon nom de famille plus sensible que mon numéro CC, que je peux changer rapidement de toute façon, faut-il masquer les noms et prénoms aussi?
@PascalSchuppli oh oui, je vois!Je t'ai eu
John Deters
2016-11-05 19:14:27 UTC
view on stackexchange narkive permalink

Il existe de nombreux problèmes persistants en matière de sécurité des données. C'est l'un d'entre eux.

TL; DR: Blâmez l'industrie des cartes de crédit.

La cause première est le concept erroné qu'en donnant votre identité vous accordez également votre autorisation . C'était la base horrible sur laquelle les cartes de crédit ont été construites, et c'est pourquoi la situation est aussi mauvaise qu'aujourd'hui.

Votre identité (numéro de carte de crédit, SSN, etc.) ne devrait jamais avoir besoin d'être gardée secrète, car qui vous êtes n'est pas un secret . Vous ne pouvez pas rester secret vis-à-vis d'un commerçant en ligne, car il doit vous expédier les articles que vous achetez. Vous ne pouvez pas rester secret vis-à-vis d'un commerçant possédant une carte de crédit, car il souhaite que votre banque lui donne de l'argent. Vous ne pouvez jamais réussir à garder le secret du fisc. Et vous ne voulez pas rester secret de votre fournisseur de soins de santé, qui a besoin de vos antécédents médicaux pour traiter vos problèmes.

Lorsque le crédit a été inventé, ce n'était pas un gros problème. Les gens se connaissaient et les deux parties se faisaient confiance dans la transaction. Mais le système était si incroyablement facile à abuser que la fraude était devenue incontrôlable.

Les transactions par carte de crédit sont extrêmement rentables. Désespérée d'empêcher les gens d'avoir peur d'utiliser leurs cartes de crédit non sécurisées, l'industrie des cartes de paiement (PCI) a réussi à rejeter le blâme sur les commerçants, en disant "qu'ils ne gardent pas vos numéros de carte de crédit en sécurité", tout en évitant le fait que le tout le système a été construit sur une prémisse erronée de confiance. (J'attribue tout le blâme à l'industrie des cartes de crédit pour avoir perpétué ce gâchis de sécurité afin de préserver leurs profits.)

La solution est de séparer votre identité de votre autorisation. Les gens n'ont pas à craindre de divulguer leur identité si l'identité est sans valeur sans autorisation.

Mais comment accorder une autorisation lorsqu'il y a la possibilité d'un intermédiaire non fiable? Il y a une mauvaise et une bonne manière. La mauvaise façon est le mot de passe. En prouvant que vous connaissez un secret, vous pouvez autoriser l'utilisation de votre identité. Mais les mots de passe simples sont aussi problématiques que les numéros de carte de crédit simples le sont aujourd'hui. Si vous dites votre secret au commerçant qui le transmet ensuite à la banque, un homme du milieu n'importe où le long de cette chaîne peut copier votre secret et falsifier votre autorisation.

Le seul bon moyen de donner votre autorisation en toute sécurité est d'utiliser challenge-response. Cela résout tout le problème, sauf que nous, les humains, ne pouvons pas faire de défi-réponse efficace dans notre tête. Ceci a été brillamment surmonté par l'introduction des cartes à puce et des protocoles EMV. La carte fait tout le travail acharné pour accepter le défi et générer la réponse. Pour plus de sécurité, la carte peut être conçue pour ne pas générer de réponse valide sans code PIN.

Dans ce monde teinté de rose, non seulement vous n'avez plus besoin de protéger les numéros de carte de crédit, mais vous n'avez pas besoin de protéger la réponse car elle est propre à relever le défi.

Nous y arriverons peut-être un jour. Mais pour le moment, EMV n'est toujours pas parfait. Parce qu'il ne peut utiliser que les petits contacts dorés pour communiquer (ou parfois RF), et que les téléphones et les ordinateurs n'ont pas la capacité universelle de parler aux cartes à puce, il n'y a pas de bon moyen d'utiliser EMV pour autoriser une transaction sur un navigateur Web ou par téléphone. (Certaines banques européennes utilisent des lecteurs de puces de poche, mais ce sont des dispositifs peu pratiques qui obligent l'utilisateur à effectuer les étapes supplémentaires consistant à taper un tas de chiffres comme défi et à saisir sa réponse.) Donc, pour l'instant, les transactions Web sont s'appuyant toujours de manière non sécurisée sur des numéros CVV statiques, qui sont l'équivalent des mots de passe.

Et cela ne résout pas non plus les problèmes non liés au crédit. L'accès aux dossiers médicaux, aux sites Web et à tout ce qui nécessite une autorisation pose le même problème et nécessite une bonne solution. Il existe de nombreuses solutions à mi-chemin comme OAuth, mais comme la violation de Yahoo! L'a démontré, ce ne sont pas de bonnes solutions. Et quelles que soient les solutions qui sortiront, elles seront combattues dans les comités de normalisation par des entreprises qui réclament toutes une part rentable du gâteau; les gouvernements concurrents qui veulent contrôler et obtenir un accès détourné; les entreprises techniques qui veulent construire l'infrastructure, etc. identité du site, etc., nous pouvons voir la fin de la boîte de mot de passe masquée. Je lui donne au moins 50 ans avant d'y arriver, si jamais.

Je n'ai jamais compris la panne provoquée par les sociétés de cartes de crédit qui laissaient leurs cartes si précaires.Vous n'êtes pas responsable des achats frauduleux.C'est l'argent de la banque, pas le vôtre.Pourquoi vous souciez-vous qu'ils le protègent ou non?Maximiser leurs profits et minimiser les tracas pour les clients est le meilleur résultat pour les deux parties.
"Donc pour le moment, les transactions Web reposent toujours de manière non sécurisée sur des numéros CVV statiques" ... ou 3D Secure, qui permet à l'émetteur de la carte d'effectuer n'importe quelle étape d'authentification qu'il souhaite (mais finit généralement par entrer un mot de passe qui n'est pas envoyé àle marchand).
@Kat - si des transactions frauduleuses ont été automatiquement détectées par magie et vous sont retournées sans nécessiter d'intervention, je suis d'accord avec vous, mais en réalité, le résultat est que vous devez vérifier périodiquement vos relevés pour les transactions non autorisées, puis vous plaindre (généralement à plusieurs reprises) aubanque jusqu'à ce qu'ils acceptent un remboursement.Cela peut prendre des heures de votre temps, pour lesquelles vous ne serez pas indemnisé.
@Kat, je ne considère pas que la fraude soit acceptable, car ces coûts sortent finalement de ma poche en termes de prix plus élevés.
@PeriataBreatta, bien sûr, il y a toute une famille de problèmes que le défi / réponse seul ne résout pas (marchands frauduleux impliqués dans la capture / lecture, l'ingénierie sociale, etc.) et il existe des centaines de solutions personnalisées uniques pour des situations spécifiques.Mais ceux-ci ne font que fracturer le marché et brouiller encore plus les eaux.Une norme digne de confiance doit émerger mais rien ne s'est rapproché.Jusque-là, nous devons tous nous attaquer au problème individuellement, avec des outils de sous-par ou de mot de passe uniquement comme Yubikey, Mooltipass, PasswordSafe, OAuth, SMS, Google Authenticator, etc., etc., etc.
@PeriataBreatta Vous devriez vérifier vos relevés, quelle que soit la sécurité des cartes, car elles ne seront jamais parfaites, et même des frais bien intentionnés peuvent être erronés.Je n'ai jamais eu besoin de plus de cinq minutes pour contester une carte et la prendre en charge.Même les fonctions de sécurité les plus mineures (comme effacer le champ et me le faire taper plusieurs fois) utiliseraient plus de temps que cela.Vous devriez peut-être changer de banque?
@JohnDeters ce n'est pas différent d'un magasin qui décide de ce qu'il faut verrouiller dans une valise ou non.Si cela leur coûtait moins cher de mettre en place plus de sécurité, ils le feraient.La sécurité n'est pas gratuite non plus et coûte souvent plus cher que la fraude ou le vol.
@Kat C'est mauvais, alors de mauvaises choses pourraient vous arriver un jour, quelque part.J'ai entendu une histoire dans mon pays, où cette pratique n'est pas courante, que quelqu'un a demandé à un ami de payer quelque chose d'un autre pays pour lui, et l'ami a ensuite contesté à tort le paiement.Son compte a été immédiatement banni parce que le fournisseur de services est en colère car il a reçu une amende pour ce litige (sans que personne ne mène une enquête sur cette affaire), et ils l'ont déclaré dans leur mandat.Techniquement, il devrait mal faire les choses selon vos termes, mais c'est assez inattendu ici.
@Kat Si c'est la banque qui mange la perte, alors pas de problème, et c'est exactement comme l'exemple de la sécurité du magasin.Mais le fait est qu'ils obligent les commerçants à accepter cela, je suppose.Les commerçants ne pensent peut-être pas que cela économise plus, mais toutes les banques font des choses comme ça et elles doivent trouver un moyen de vivre.Lorsqu'il n'économise pas davantage, le coût sera reflété sur le prix de tout ce que vous achetez.
@Kat Idéalement, les commerçants pourraient facturer moins si vous utilisez une banque qui utilise une meilleure sécurité et n'accepte pas ces litiges, ou les gère mieux.Mais c'est suspect, gênant, difficile à faire de la publicité, provoquant la surprise et ayant beaucoup d'autres tracas, tout cela parce qu'ils sont comparés à la voie «normale» actuelle choisie par les banques, et non parce qu'ils sont vraiment moins chers dans un état idéal.Ils pourraient être en fait moins chers dans un état idéal, mais qui sait.Cela n'a pas d'importance pour les banques.
@Kat Même s'il n'y a pas de tels problèmes, quelqu'un devrait être libre d'interroger les banques, et théoriquement, potentiellement autorisé à créer eux-mêmes de meilleures banques à leur terme.Si cela est censé être ridicule, il ne faut pas s'attendre à ce que le marché soit suffisamment libre pour être dans un état optimal, vous devriez donc payer quelque chose de plus.
juste pour étendre la partie sur le défi-réponse: ces appareils que les banques utilisent en Europe ont obtenu un moyen de transmettre les données via un code clignotant pour éviter de saisir ces longues chaînes de numéros.
Jared Smith
2016-11-05 23:43:25 UTC
view on stackexchange narkive permalink

Bien que la réponse de User1301428 fasse un excellent travail pour expliquer la différence entre les mots de passe et d'autres types de données sensibles, il y a aussi une raison technique: les balises d'entrée HTML (et quel que soit l'équivalent sur les autres plates-formes).

Depuis Internet Explorer 2 (en 1995, et par extension la première version de tous les autres navigateurs), la modeste balise d'entrée a pris en charge type = "password" , qui sur presque tous les navigateurs masquera le texte. Tout ce qui recrée le comportement de cette balise à partir de zéro parce que les raisons vont généralement mimer ce comportement.

Mais il n'y a pas de type "carte de crédit" ou "ssn". Ainsi, alors que le développeur l'obtient gratuitement dans le cadre de la plate-forme Web (ou autre), il devrait utiliser le type de mot de passe pour lui (en violation de l'attente désormais courante d'avoir plusieurs zones de saisie pour diviser le nombre) ou l'implémenter à la main pour d'autres données. Ensuite, il y a toute la tâche de taper correctement un nombre de 9 à 16 chiffres lorsque vous ne pouvez pas voir les chiffres et ... ouais.

La seule différence entre `type = text` et` type = password` est de savoir si le champ est masqué.L'auteur HTML pourrait utiliser `type = password` sur un champ CC ou SSN s'il le souhaite.Il n'y a aucune raison technique pour laquelle ils ne pourraient pas masquer ces champs.Cette réponse est complètement fausse.
@ScottJ Une fois, Chrome m'a proposé d'enregistrer mon numéro de carte de paiement en tant que "nom d'utilisateur" et le CVV en tant que "mot de passe", car c'est l'impression qu'il a obtenue du formulaire.Très déconcertant.
@newcoder Voilà ce que sont ces choses, bien que.
@ScottJ Pourtant, `type = masked` serait beaucoup plus attrayant à utiliser pour les champs sans mot de passe que` type = password`.Ce n'est clairement pas la vraie raison pour laquelle seuls les mots de passe sont masqués, mais la réponse fait un bon point qui y a presque certainement contribué.
de nos jours, de nombreux frameworks de développement proposent des widgets personnalisés GRATUITS qui formulent des informations spécifiques telles que le numéro de téléphone, le code postal;et donc pour les informations sensibles comme le numéro de carte.L'implémentation est bien établie tant du côté client que du côté serveur.Je veux dire qu'il n'y a pas trop de travail à mettre, dans un formulaire Web, un champ de type SSN distinct.
@Luc donc la raison pour laquelle les non-mots de passe ne sont pas masqués est parce que d'autres auteurs HTML étaient aussi confus que @Jared Smith à propos de `type = password`.C'est raisonnable, mais cela n'en fait pas une bonne réponse.Si cette réponse disait "Parce que les auteurs HTML n'ont pas compris` type = password` ", alors cela pourrait être une bonne réponse.
@Jared Smith, votre modification du 9 novembre montre une confusion persistante à propos de `type = password`.Il n'y a aucune raison pour que l'auteur HTML ne puisse pas avoir plusieurs zones de saisie pour diviser le nombre, toutes en utilisant `type = password`.Cette réponse est encore complètement fausse.
Wildcard
2016-11-08 09:11:32 UTC
view on stackexchange narkive permalink

Je vois deux raisons / différences immédiates. Le premier est mentionné au passage dans l'excellente réponse acceptée, mais je n'ai pas vu le deuxième point mentionné ici.

  1. Un mot de passe erroné sera immédiatement remarqué et rejeté.

    Contrairement à un numéro de carte de crédit ou un SSN mal saisi avec des conséquences potentielles, un formulaire de connexion rempli avec un incorrect password donnera un retour immédiat, souvent sans autre conséquence que de devoir saisir à nouveau le mot de passe.

    Bien sûr, c'est ennuyeux en soi; par conséquent, certains sites Web offrent désormais une option "Afficher le mot de passe" comme une amélioration de la convivialité.

    Pourtant, par rapport au fait de découvrir plusieurs minutes ou heures plus tard que votre achat a échoué (en raison d'une en saisissant les informations de carte de crédit car le champ de la carte de crédit a été vide), ou en découvrant mois plus tard que votre déclaration de revenus a été rejetée parce que votre SSN a été mal saisi (car le champ a été vide), un identifiant l'échec est une conséquence assez apprivoise.

  2. Lors de la définition d'un mot de passe, les utilisateurs s'attendent à être invités à le saisir deux fois. / p>

    Ceci est le facteur atténuant lors de la suppression du champ du mot de passe: vous pouvez entrer le mot de passe deux fois, pour être sûr de l'avoir entré correctement. (Bien sûr, cela ne s'applique qu'à la définition du mot de passe en premier lieu, lorsqu'il n'y a rien à comparer avec la valeur saisie afin que vous ne puissiez pas avoir un "mauvais mot de passe" rejeté.)

    Imaginez si le champ de la carte de crédit était vide. Souhaitez-vous entrer les informations de votre carte de crédit deux fois, les deux fois en aveugle? (Je ne le ferais pas.) Ce serait une amélioration par rapport à la saisie des informations de carte de crédit en aveugle une seule fois une seule fois , mais ce serait un pas en avant pour entrer les informations et vérifier que vous les avez saisies correctement comme vous pouvez le faire aujourd'hui.

Micheal Johnson
2016-11-05 22:08:45 UTC
view on stackexchange narkive permalink

C'est juste une pratique courante. Il y a de nombreuses fois où je préfère de loin avoir un mot de passe visible. De même, les utilisateurs seront confus s'ils ne peuvent pas voir leur numéro de carte lorsqu'ils le saisissent. Il n'y a pas d'autre raison.

Notez que certains sites Web / navigateurs Web permettent aujourd'hui de "démasquer" un champ de mot de passe si l'utilisateur préfère voir son mot de passe et est convaincu que personne ne regarde par-dessus son épaule.

user23013
2016-11-06 14:50:08 UTC
view on stackexchange narkive permalink

Dans un système bien conçu, les mots de passe ne doivent pas être stockés en texte brut sur le serveur. La seule situation dans laquelle vous pouvez voir le mot de passe est lorsque vous le saisissez. Et vous pouvez le faire partout lorsque vous souhaitez accéder à votre compte. Autrement dit, dans toutes les situations où l'utilisateur pourrait voir ses mots de passe, on devrait supposer qu'il pourrait y avoir d'autres personnes autour.

Pour d'autres informations, les gens sont très susceptibles de les saisir ou de les lire en toute sécurité emplacements sans personne autour. Dans de nombreux cas, l'utilisateur ne saisit qu'une seule fois ces informations et utilise le site Web pendant une longue période. Et lorsque l'utilisateur clique sur cette option en utilisant ces informations, ils devraient déjà être préparés.

TL; DR: Il n'est pas pratique de se débarrasser de tout le monde autour de vous lorsque vous entrez le mot de passe.

Je ne dis pas qu'ils ne devraient pas être supprimés. Mais cela pourrait ne pas être leur plus grande préoccupation, selon les situations.

Cela ne ressemble pas à une réponse à la question mais à un commentaire sur une autre réponse?
@schroeder Euh, sur quelle réponse?Il n'est pas pratique de se débarrasser de tout le monde autour de vous lorsque vous entrez le mot de passe.C'est un peu pratique pour saisir / visualiser d'autres informations.Alors ils sont traités différemment, comme la question est posée?
Pourquoi parlez-vous du stockage des mots de passe?La plupart des éléments pertinents de cette réponse sont déjà couverts par d'autres réponses.J'ai du mal à voir comment cette réponse se rapporte à la question et en quoi elle diffère des autres réponses.Je pense que vous devrez peut-être relier quelques points.
Les sites Web @schroeder n'affiche pas les mots de passe sur leurs pages, alors qu'ils peuvent afficher d'autres informations.


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 3.0 sous laquelle il est distribué.
Loading...