2009-06-07 9 views
50

Je travaille actuellement sur un fournisseur PHP OpenID qui fonctionnera via HTTPS (donc crypté SSL).
Est-ce mauvais pour moi de transmettre le mot de passe en texte brut? HTTPS en théorie, ne peut pas être intercepté, donc je ne vois rien de mal. Ou est-ce dangereux à un certain niveau et je ne le vois pas?Mot de passe en texte clair sur HTTPS

Répondre

74

Il est sûr. C'est comme ça que fonctionne tout le web. Tous les mots de passe dans les formulaires sont toujours envoyés en texte brut, donc c'est HTTPS pour le sécuriser.

+16

Minor nitpick: certains formulaires de connexion utilisent JavaScript pour hacher le mot de passe au lieu de l'envoyer en texte brut. – Thorarin

+3

@Thorarin si elles le hachaient vraiment, cela signifie que le serveur stocke le mot de passe en texte brut afin qu'il puisse hacher avec le même sel à vérifier. Ick! L'envoi du mot de passe dans le texte encapsulé SSL est préférable, car le serveur n'a pas besoin de stocker le mot de passe en texte brut. – DGM

+9

@DGM: le double hachage est également une option, les mots de passe en texte clair ne sont donc pas strictement nécessaires. – Thorarin

18

Si HTTP est désactivé et que seulement utilise HTTPS, alors vous ne transmettez pas vraiment le mot de passe en texte brut de toute façon.

45

Vous devez toujours vous assurer que vous l'envoyez via une requête POST, pas GET. Si vous l'envoyez via une requête GET, vous pouvez l'enregistrer en clair dans les journaux de l'historique du navigateur de l'utilisateur ou dans les journaux d'accès du serveur Web.

+3

Oui, je le savais, mais c'est toujours un bon commentaire à laisser pour les autres qui viennent ici. :) – WhyNotHugo

5

Les autres affiches sont correctes. Maintenant que vous utilisez SSL pour chiffrer la transmission du mot de passe, assurez-vous hachant avec un bon algorithme et le sel de sorte qu'il est protégé quand il est au repos aussi ...

+0

Oui, je m'en rends compte, merci, je parlais simplement de la transmission ici. – WhyNotHugo

4

client Hash côté. Pourquoi? Laissez-moi vous parler d'une petite expérience. Montez à l'ordinateur dans la cafétéria de l'entreprise. Ouvrez le navigateur vers la page de connexion du site Web de l'entreprise (https). Appuyez sur F12, cliquez sur l'onglet réseau, cochez le journal de persistance, minimisez la console mais laissez la page Web ouverte sur la page de connexion. Asseyez-vous et déjeunez. Regardez en tant qu'employé après que l'employé se connecte au site Web de l'entreprise et que ce soit un bon petit travailleur qui se déconnecte une fois terminé. Terminez le déjeuner, asseyez-vous à l'ordinateur et affichez l'onglet réseau. Vous verrez chaque nom d'utilisateur et mot de passe en texte brut dans le formulaire bodys.

Pas d'outils spéciaux, pas de connaissances particulières, pas de matériel de piratage sophistiqué, pas de keyloggers juste bon vieux F12.

Mais bon, continuez à penser que tout ce dont vous avez besoin est SSL. Les méchants vont t'aimer pour ça.

+2

Votre commentaire de la cafétéria n'a aucun sens, peu importe combien je l'ai relu. Pourquoi les gens marcheraient-ils sur un ordinateur et taperaient-ils leurs informations d'identification? Qu'est-ce que vous essayez de prouver? De plus, le hachage ne rendra pas ce * plus * insécurisant, en aucune façon. C'était une chose courante de hacher les mots de passe et de les transmettre par HTTP en texte clair quand cette question a été écrite, en 2009. – WhyNotHugo

+0

J'ai mis ces deux mots à la page parce que, oui, la réponse acceptée est lue plusieurs années plus tard. Il serait bon que @CodeDog indique s'il vous plaît une stratégie d'atténuation. Et oui, les gens vont juste marcher vers des PC aléatoires, par exemple, dans la bibliothèque locale, et entrer leurs coordonnées! – JoeAC

+0

Je crypte les mots de passe côté client avec une clé publique, puis publie uniquement le mot de passe crypté dans le formulaire. C'est une clé asymétrique donc avoir la clé publique côté client est inutile pour les attaquants. Chaque log génère une nouvelle paire de clés, donc les attaques par répétition ne fonctionneront pas non plus. La clé change même en cas d'échec des tentatives de connexion. Les paires de clés sont générées côté serveur lorsque les utilisateurs arrivent à l'écran de connexion. Seule la clé publique est fournie au code côté client. – CodeDog

Questions connexes