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?
Réponses:
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.
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.
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.
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.
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.
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 ...
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é.