Comment savoir si une webapp transmet mon mot de passe en texte clair?
J'essaie de voir si une application Web transmet le mot de passe sous une forme en texte clair. Le problème est que l'application Web n'utilise PAS https! C'est pourquoi je me demande si mes mots de passe sont envoyés en texte clair.
J'ai trouvé un cookie dans mon navigateur contenant les éléments suivants:
usr=waytodoor&mdp=3C5115ECB18725EBFFF4BB11F9D17798358477D6E11E0188D54BAB80C86D38D41A16F76D8D0B253445774484FB1AE22E9FC13E257CFB9E7B7466F1BA5417EA004FCBB4E7965CA571819146A148EED15A2AEA6E47D9DF338B534264FBC99A57952212629BA79BB34BE9C8C60B73F1F681EE872C64
D'après ce que je peux dire, usr est mon nom d'utilisateur et mdp ("mot de passe" en français signifie mot de passe).
Alors, le champ mdp du cookie est-il mon mot de passe (et, si c'est le cas, comment pourrais-je le "décrypter"?), Ou juste une sorte de jeton? Le mot de passe comporte 7 caractères.
J'ai essayé de le convertir en hexadécimal ou en base 64, mais pas de chance.
EDIT: Déclaration incluse indiquant que HTTPS n'est pas utilisé.
EDIT2: Le site Web est un site Web pour les étudiants. Les mots de passe sont donnés par l'école en début d'année. Nous ne pouvons pas les changer.
Je soupçonne que certains élèves sont ARP'ing le réseau scolaire. J'essaie de me déconnecter le plus rapidement possible du site pour invalider les cookies, mais je voulais savoir s'ils pouvaient trouver le mot de passe à partir du cookie.
Il y a deux raisons de demander si votre mot de passe est crypté:
- Vous vous inquiétez de la sécurité du site.
- Vous vous inquiétez de la sécurité de votre mot de passe.
En ce qui concerne la sécurité du site, sans HTTPS, il n'y en a effectivement aucun. Vous devez considérer chaque communication avec le site comme publique et supposer qu'un attaquant peut se faire passer pour vous. Utilisez le site avec précaution.
Concernant la sécurité de votre mot de passe, sans SSL, cela n'a pas vraiment d'importance. Quelqu'un peut voler votre cookie de session et prétendre être vous sans connaître votre mot de passe. Assurez-vous donc de ne pas réutiliser le mot de passe sur d'autres sites (ou de ne réutiliser aucun mot de passe) pour éviter qu'une exposition de mot de passe sur ce site ne compromette vos comptes sur d'autres sites.
Modifier En réponse à votre préoccupation concernant surpation ARP , sans SSL, il est possible qu'ils établissent un MiTM . Une fois qu'ils ont fait cela, ils peuvent voir le cookie. Sans une inspection plus approfondie du site Web, je ne peux pas vous dire si le cookie fuit votre mot de passe. Peut-être qu'il est crypté en toute sécurité, peut-être pas. Cela dit, une fois qu'ils ont un MiTM, ils peuvent modifier le JavaScript qui est envoyé à votre navigateur. Cela leur permettrait de modifier ce qui est envoyé sur le fil, obtenant ainsi votre mot de passe. Et, bien que je ne puisse pas être certain sans un examen plus approfondi, ce cookie me ressemble à un passez la vulnérabilité de hachage . Si tel est le cas, il n'est pas nécessaire pour eux de voler votre mot de passe car la valeur du cookie est aussi bonne qu'un mot de passe. Tout cela se résume à, sans SSL, il n'y a pas de sécurité.
Vous disposez de 232 chiffres hexadécimaux ou 116 octets de données. Ce n'est pas une chaîne de texte brut dans un encodage normal. Cela pourrait être un hachage de votre mot de passe, ce pourrait être votre mot de passe crypté, ce pourrait être juste une sorte d'obscurcissement facilement réversible. Ou cela pourrait être quelque chose de complètement différent de votre mot de passe, comme un identifiant de session. Ça pourrait être n'importe quoi. Sans connaître votre mot de passe ou le code utilisé par la webapp, c'est difficile à dire.
Mais si vous vous inquiétez de la sécurité de votre mot de passe quand il est sur le fil, cela n'a vraiment pas d'importance. L'important est que vous utilisiez HTTPS. * Si vous utilisez HTTPS, tout ce qui est envoyé entre vous et le serveur sera de toute façon crypté. Si vous ne le faites pas, il n'y a aucun moyen de garantir qu'un homme au milieu ne peut pas voler votre mot de passe, quel que soit le type de cryptage que vous essayez de faire sur le client.
Habituellement, le seul chiffrement utilisé lors de l'envoi d'un mot de passe au serveur est celui fourni par HTTPS.
Cela dit, conserver le mot de passe dans un cookie (qu'il soit ou non en texte brut, crypté, haché ou simplement obscurci) est une mauvaise idée. Toute personne ayant accès à votre ordinateur pourrait voler le cookie, et si le cookie n'est pas HTTP, seule une vulnérabilité XSS pourrait également être utilisée pour le voler.
* Étant donné que c'est un bon HTTPS - que le certificat est valide, vous utilisez une version moderne de TLS, etc., etc. Les mêmes mises en garde qui s'appliquent toujours.
Lorsque vous souhaitez écouter la communication entre votre navigateur Web et un serveur, vous pouvez souvent le faire avec les outils de développement de votre navigateur Web (raccourci clavier habituel: F12). La plupart des navigateurs auront une sorte d'onglet Réseau où toutes les communications réseau entre le site Web actuel et Internet sont enregistrées en texte clair.
Lorsque vous trouvez votre mot de passe en texte clair n'importe où et que ce n'est pas une connexion https, c'est un mauvais signe (quand il est https, le navigateur vous montrera les données non cryptées, même si elles ont été cryptées lors de leur envoi sur -le-fil).
Mais même lorsque vous y trouverez un mot de passe chiffré/haché, vous ne saurez pas s'il s'agit d'une cryptographie bonne. En règle générale, vous ne pouvez le dire qu'en utilisant des techniques de cryptoanalyse jusqu'à ce que vous compreniez comment fonctionne le cryptage ou si vous inversez le code javascript sur le site Web pour savoir comment il fonctionne.
Voici comment normalement vous étudiez cela. S'il s'agit d'un hachage de votre mot de passe, vous pouvez tester votre mot de passe avec la fonction de hachage et comparer la sortie. Cette chaîne de hachage particulière (supposée) a 232 chiffres hexadécimaux, ce qui équivaut à 928 bits. Il s'agit de la taille exacte du numéro RSA-280, qui est utilisé dans le cryptage SHA-1 (avec de nombreux autres numéros RSA, vous ne pouvez donc pas être sûr sans essayer la fonction).
https://en.wikipedia.org/wiki/RSA_numbers#RSA-28
Le RSA-280 a 280 chiffres décimaux (928 bits) et n'a pas été pris en compte jusqu'à présent.
Vous pouvez ouvrir le code source de la page Web, essayer de trouver le module qui a quelque chose à voir avec SHA-1 (dans ce cas), puis trouver la fonction de hachage à l'intérieur et l'exécuter à l'aide des outils de développement du navigateur ou node.js comme cette:
console.log(hashingFunction('yourpass'))
Il suffit ensuite de voir si la sortie contient les mêmes 232 caractères. Veuillez noter que trouver la fonction de hachage peut être difficile, qu'elle peut être obscurcie, téléchargée longtemps après le chargement de la page, etc., et vous aurez évidemment besoin de connaissances JavaScript.
Il y a deux possibilités, votre mot de passe est soit encodé, soit chiffré dans cette chaîne. S'il a été chiffré, il ne peut être déchiffré qu'à l'aide de la clé définie dans l'application Web, qui est assez sécurisée et a besoin de beaucoup de temps pour essayer de la casser.