web-dev-qa-db-fra.com

Site Web renvoyant un mot de passe en texte brut

Je me suis récemment connecté à un site Web. Lorsque j'ai cliqué sur la page "Mettre à jour le profil", une liste de zones de texte s'affiche pour tous les champs utilisateur, par ex. nom, e-mail, numéro de téléphone, etc.

Il y a aussi une boîte pour le mot de passe et confirmer le mot de passe (car si vous souhaitez mettre à jour ces valeurs), cependant, lorsque vous allez dans cette page, ces boîtes sont déjà remplies, ce qui m'a fait penser, pourquoi mettent-ils des espaces réservés?

En entrant dans l'élément inspect, ils ont en fait les valeurs de votre mot de passe, transformées en majuscules comme ceci:

<input type="password" name="txtPassword2" size="45" value="MYPASSAPPEARSHERE">

J'ai également récemment remarqué que la casse de votre mot de passe ou nom d'utilisateur n'est pas pertinente lors de la connexion - par exemple Je peux le mettre dans toutes les majuscules, tout en bas ou un mélange des deux et il acceptera toujours le mot de passe.

Est-ce une faille de sécurité et cela indique-t-il qu'ils stockent des mots de passe en texte brut?

Ce n'est pas un doublon de ( Que faire des sites Web qui stockent des mots de passe en texte brut ) car je demande ici des éclaircissements pour savoir si cela indique le site stocke des mots de passe en clair, plutôt que quoi faire à ce sujet.


Réponse de l'entreprise: Après avoir poussé fort, l'entreprise a avoué qu'ils stockaient en fait des mots de passe en texte brut.

63
stzvggmd

De toute évidence, s'ils peuvent afficher votre mot de passe, ils stockent votre mot de passe d'une manière ou d'une autre. Ils peuvent mettre en cache votre mot de passe côté client lorsque vous vous connectez (pour des raisons injustifiables, comme la gestion de session), mais plus probablement leur base de données de mots de passe est en texte clair. Quoi qu'il en soit, il est stocké et ne devrait pas l'être.

Et il semble qu'ils exécutent une fonction upper() sur le mot de passe, qui efface 26 caractères du jeu de caractères potentiel qui aurait autrement ajouté de l'entropie.

C'est une très, très mauvaise sécurité de leur part qui n'a pas sa place depuis 2 décennies.

117
schroeder

Le mot de passe en clair est un problème de sécurité béant.

  1. D'abord, ils ne devraient même pas le savoir. Les mots de passe doivent être stockés hachés et salés. Quiconque ne le fait pas est un [censuré par les éditeurs].
  2. Deuxièmement, l'envoi du mot de passe sur le câble lorsqu'il n'est pas strictement nécessaire est une deuxième énorme erreur de sécurité.
  3. Troisièmement, l'inclure dans la page Web à ce stade ne fait qu'ajouter l'insulte au préjudice.

Qu'ils jettent l'affaire est inoffensif par rapport à cela. C'est en fait quelque chose qui peut être un compromis raisonnable entre la sécurité et la convivialité. Il se peut également qu'ils utilisent un ancien système d'arrière-plan qui ne prend pas en charge les majuscules/minuscules. J'ai vu ça avec des mainframes. Il devrait être écrit quelque part que les mots de passe sont insensibles à la casse, mais honnêtement, par rapport aux trois premières grèves, celle-ci mérite à peine d'être mentionnée.

13
Tom

Pour être honnête, nous ne savons pas .

Ils pourraient stocker le mot de passe en clair, ils pourraient le stocker crypté. Les deux seraient assez désastreux. Ils pourraient le stocker dans la session (c'est-à-dire côté serveur) lorsque vous vous connectez, ce qui serait un peu moins désastreux mais toujours mauvais. Ils pourraient même vous le stocker dans un cookie (c'est-à-dire côté client), puis faire insérer le script montrant le profil utilisateur dans le formulaire, ce qui serait également toujours mauvais.

Quoi qu'il en soit, il n'y a aucune bonne raison, ni raison saine, ni en fait aucune raison pour laquelle j'imagine pourquoi on aurait besoin, ou même veulent garder le mot de passe inutilement et plus longtemps que nécessaire. Ou, pourquoi il faudrait être dans le formulaire.

Plus vous gardez longtemps quelque chose de secret, peu importe qu'il soit sûr ou non, plus la probabilité que "quelque chose" se produise et que les secrets ne sont plus secrets est élevée.

Donc ... quoi que ce soit, ce n'est généralement pas un bon modèle. Comme c'est vraiment grave, nous ne pouvons pas le dire.

Il en va de même pour la mise en majuscule du mot de passe. Nous ne savons pas ce qu'ils font là-bas. Ils pourraient considérer chaque mot de passe en majuscules, ce qui serait assez mauvais car cela rend une attaque par force brute environ deux fois plus efficace. Bien que, à la lumière de la possibilité de stocker des mots de passe en texte clair, c'est un peu négligeable. Les attaques par force brute en ligne sont peu probables et facilement contrecarrées, et les attaques hors ligne, eh bien ... si les mots de passe sont texte en clair ... vous savez. Peu importe, à ce stade.

Ils pourraient simplement le mettre en majuscule pour ce formulaire afin qu'un extrait de code Javascript "super intelligent" vous dise "c'est trop similaire" lors du changement de mot de passe, peu importe. Nous ne le savons pas. Mais encore une fois, quoi que ce soit, ce n'est pas bon.

6
Damon