Mot de passe en texte brut sur HTTPS

90

Je travaille actuellement sur un fournisseur PHP OpenID qui fonctionnera sur HTTPS (donc crypté SSL).
Est-ce que je ne peux pas transmettre le mot de passe sous forme de 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 vois pas cela?

WhyNotHugo
la source

Réponses:

126

C'est sûr. C'est ainsi que tout le Web fonctionne. Tous les mots de passe dans les formulaires sont toujours envoyés en texte brut, c'est donc à HTTPS de le sécuriser.

Eduardo Scoz
la source
20
Petit problème: certains formulaires de connexion utilisent JavaScript pour hacher le mot de passe au lieu de l'envoyer en texte brut.
Thorarin
5
@Thorarin s'ils le hachent vraiment, cela signifie que le serveur stocke le mot de passe en texte brut afin qu'il puisse le hacher avec le même sel pour le vérifier. Ick! Il est préférable d'envoyer le mot de passe en texte enveloppé ssl, car le serveur n'a alors pas besoin de stocker le mot de passe en texte brut.
DGM
11
@DGM: le double hachage est également une option, donc les mots de passe en texte brut ne sont pas strictement nécessaires.
Thorarin
3
@Denis: le hachage côté client n'aide pas vraiment beaucoup. Cela peut rendre les choses un peu plus difficiles que le texte brut, mais quelqu'un qui veut vraiment voler un mot de passe peut le faire sans problème. Cela ne fonctionnerait en toute sécurité que si vous envoyez au moins un jeton unique sur un canal sécurisé (ssl), auquel cas vous pouvez tout aussi bien envoyer le mot de passe en SSL pour commencer.
Eduardo Scoz du
4
Je dis simplement que Yahoo a estimé que le hachage côté client était suffisamment sécurisé jusqu'à ce qu'ils puissent se permettre de passer à SSL. Mais bon, je suis tout pour https :)
Denis
73

Vous devez toujours vous assurer de l'envoyer via une requête POST, pas GET. Si vous l'envoyez via une requête GET, il peut être enregistré en texte brut dans les journaux d'historique du navigateur de l'utilisateur ou les journaux d'accès du serveur Web.

personne
la source
7
Oui, je le savais, mais c'est quand même un bon commentaire à laisser pour les autres qui viennent chercher ici. :)
WhyNotHugo
ou envoyez-le dans un en-tête
james
22

Si HTTP est désactivé, et vous n'utiliser HTTPS, alors vous n'êtes pas vraiment transmettre le mot de passe en texte clair de toute façon.

Can Berk Güder
la source
4
Toutefois , le serveur n'avoir accès à votre mot de passe en texte clair, ils peuvent stocker sous forme de texte brut, connectez - vous incorrectement en texte brut , etc. C'est - à - dire votre mot de passe ne reste pas sur le côté client, le serveur voit aussi exactement ce qu'il est.
xref
12

Hash côté client. Pourquoi? Laissez-moi vous parler d'une petite expérience. Approchez-vous de l'ordinateur dans la cafétéria de l'entreprise. Ouvrez le navigateur à la page de connexion au site Web de l'entreprise (https). Appuyez sur F12, cliquez sur l'onglet réseau, cochez le journal de persistance, réduisez la console mais laissez la page Web ouverte à 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 le bon petit travailleur se déconnecte une fois terminé. Terminez le déjeuner, asseyez-vous à l'ordinateur, affichez l'onglet réseau et voyez chaque nom d'utilisateur et mot de passe en texte brut sous forme de corps.

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

Mais bon, continuez à penser que tout ce dont vous avez besoin est SSL. Les méchants vous aimeront pour cela.

CodeDog
la source
6
Votre commentaire à la cafétéria n'a aucun sens, peu importe combien je l'ai relu. Pourquoi les gens se dirigent-ils simplement vers un ordinateur et saisissent leurs informations d'identification? Qu'est-ce que vous essayez de prouver? De plus, le hachage ne rendra en aucun cas cela plus dangereux. Il était courant de hacher les mots de passe et de les transmettre via HTTP en texte brut lorsque cette question a été écrite, en 2009.
WhyNotHugo
4
J'ai voté pour les deux parce que, oui, la réponse acceptée est lue plusieurs années plus tard. Ce serait bien que @CodeDog indique une stratégie d'atténuation. Et oui, les gens vont simplement marcher vers des PC aléatoires, par exemple, dans la bibliothèque locale, et entrer leurs coordonnées!
JoeAC
3
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 journal génère une nouvelle paire de clés afin que les attaques de relecture ne fonctionnent 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
BTW J'ai vu ce piratage utilisé dans un centre d'affaires de l'hôtel par le personnel afin de recueillir des codes d'accès pour les numéros de chambre. Ils utilisaient le mot de passe pour accéder au sans fil et utiliser les ordinateurs du centre d'affaires et il serait facturé à la chambre.
CodeDog le
J'ai effectué une telle expérience moi-même en me connectant à mon compte bancaire et je dois être d'accord avec @CodeDog - La charge utile de la demande comprend mon identifiant et mon mot de passe en clair.
Artur Michajluk
6

Prenons quelques notes sur les réponses précédentes.

Premièrement, ce n'est probablement pas la meilleure idée d'utiliser des algorithmes de hachage côté client. Si votre mot de passe est salé côté serveur, vous ne pourrez pas comparer les hachages (du moins pas si vous ne stockez pas le hachage client dans la base de données dans l'une des couches de hachage du mot de passe, qui est le même ou pire). Et vous ne voulez pas implémenter l'algorithme de hachage utilisé par la base de données côté client, ce serait idiot.

Deuxièmement, échanger des clés cryptographiques n'est pas non plus idéal. Le MITM pourrait théoriquement (étant donné qu'il a un certificat racine installé sur le client) changer les clés cryptographiques, et changer avec ses propres clés:

Connexion d'origine (sans tenir compte de tls) depuis un serveur théorique qui échange des clés:

Le client demande des clés publiques> le serveur détient les clés privées, génère des clés publiques au client> le serveur envoie des clés publiques au client

Maintenant, dans une piste théorique MITM:

Le client demande des clés publiques> MITM génère de fausses clés privées > Le serveur détient les clés privées, génère des clés publiques au client> MITM reçoit les clés publiques du serveur d'origine, maintenant, nous sommes libres d'envoyer nos fausses clés publiques au client, et chaque fois qu'une demande provient du client, nous déchiffrerons les données du client avec les fausses clés, changerons la charge utile (ou la lirons) et chiffrerons avec les clés publiques d'origine > MITM envoie de fausses clés publiques au client.

C'est le point d'avoir un certificat CA de confiance dans TLS, et c'est ainsi que vous recevez un message d'avertissement du navigateur si le certificat n'est pas valide.

En réponse à l'OP: à mon humble avis, vous ne pouvez pas faire cela, car tôt ou tard, quelqu'un voudra attaquer un utilisateur de votre service et tentera de briser votre protocole.

Ce que vous pouvez faire, cependant, est d'implémenter 2FA pour empêcher les gens d'essayer de se connecter avec le même mot de passe. Attention cependant aux attaques par rejeu.

Je ne suis pas doué pour la cryptographie, veuillez me corriger si je me trompe.

Lucca Ferri
la source
Gardez à l'esprit que cette discussion date de 2009. Il s'agissait à peu près des meilleures pratiques à l'époque.
WhyNotHugo
3
@WhyNotHugo Je suis au courant. J'ai décidé de laisser une réponse parce que la meilleure réponse google à cette question m'a conduit ici, alors pourquoi pas.
Lucca Ferri
4

Les autres affiches sont correctes. Maintenant que vous utilisez SSL pour crypter la transmission du mot de passe, assurez-vous de le hacher avec un bon algorithme et du sel afin qu'il soit également protégé lorsqu'il est au repos ...

grossvogel
la source
Oui, je m'en rends compte, merci, je faisais simplement référence à la transmission ici.
WhyNotHugo
0

L'exemple @CodeDog a des problèmes.

Oui, je peux croire que les utilisateurs se connecteront à une boîte de cafétéria. Si vous capturez des journaux à partir d'une cafétéria d'entreprise, vous êtes la faille de sécurité. Les boîtes de caffeterias d'entreprise doivent être configurées désactivées, par exemple, aucun terme, aucun enregistreur, aucun accès à distance, etc. Afin de vous empêcher, le pirate informatique interne.

L'exemple est un bon exemple de sécurité d'accès informatique, et pas vraiment lié à la sécurité réseau. Il est fourni comme justification du hachage côté client, mais si vous avez accès à un ordinateur, vous pouvez simplement utiliser un enregistreur de frappe et contourner cela. Le hachage côté client est à nouveau sans importance. L'exemple de @CodeDog est un hack d'accès à l'ordinateur et nécessite des techniques différentes des hacks de couche réseau.

En outre, un piratage informatique public est protégé en paralysant le système contre les menaces, comme mentionné ci-dessus. par exemple, utilisez un Chromebook pour un ordinateur public de la cafétéria. Mais cela est contourné par un piratage physique . Pendant les heures creuses, allez à la cafétéria et installez une caméra secrète pour enregistrer les pressions sur le clavier des utilisateurs. Ensuite, peu importe si l'ordinateur de la cafétéria est paralysé OU quel type de cryptage est utilisé.

couche physique -> couche informatique -> couche client -> couche réseau -> couche serveur

Pour la mise en réseau, peu importe si vous hachez côté client car la couche https / ssl cryptera le mot de passe brut. Ainsi, comme d'autres le mentionnent, le hachage du client est redondant si le TLS est sécurisé.

Ramakarl
la source
1
Pendant que vous faites valoir de bons points, vous répondez à une réponse (qui en soi n'est pas vraiment pertinente par rapport à la question posée), ce qui n'est donc pas vraiment approprié pour le modèle de questions-réponses Stackoverflow.
Martin