Il semble que la plupart des sites Web majeurs utilisent un domaine sécurisé, mais il y a quelques exceptions principales, notamment Facebook et Twitter.
Les avantages de l'utilisation d'un domaine sécurisé sont évidents, je suppose - vos identifiants de connexion ne sont jamais transmis en texte brut.
Alors, comment les principaux sites comme Facebook et Twitter m'envoient-ils? Si un domaine sécurisé n'est pas disponible pour une raison quelconque, quelles précautions supplémentaires pourraient-elles prendre?
5 Réponses :
Je ne sais pas quelles techniques sont couramment utilisées, mais toutes les informations qui ne sont pas stockées et que c.-à-d. Nom d'utilisateur et mot de passe) pourraient éventuellement être hachées (par exemple, SHA1 ou MD5) sur le client.
Cependant, cela nécessite des scripts côté client qui pourraient être désactivés ou indisponibles. Il se peut que certains sites ne considèrent pas leurs informations suffisantes pour nécessiter une transmission sécurisée (vous ne devriez pas envoyer d'informations sensibles à Facebook ou à Twitter, etc.).
Étant donné que les valeurs hachées sont envoyées dans la claire, tout ce qui serait à faire est d'envoyer les mêmes valeurs hachées sur le serveur pour vous connecter. De plus, étant donné que le script côté client est lisible, tout algorithme à hachage des valeurs serait disponible pour un pirate informatique.
@Jeffrey "tout algorithme à hachage Les valeurs seraient disponibles pour un pirate informatique." Cette partie est sans importance sachant simplement qu'une valeur est hachée avec MD5 ne le rend pas intrinsèquement plus faible. Bien qu'il y ait des tables arc-en-ciel pour casser le hachage MD5 si vous avez un mot de passe sécurisé, aucune table arc-en-ciel ne le frappera. Cependant, la première partie de pouvoir simuler l'affichage de la valeur de hachage est légitime.
hachage Votre mot de passe avant de la transmettre non crypté ne vous aide pas vraiment chez l'homme dans les situations moyennes, puisque quelqu'un qui intercepte la communication peut facilement rejouer votre mot de passe et vous connecter avec vos informations d'identification.
Je dirais que une sorte de cryptage devrait être obligatoire à des fins d'authentification. En ce qui concerne la question, oui, https serait la meilleure option. Évidemment, la chose la plus simple à vérifier est la barre de localisation en haut s'il commence par «HTTPS: //», mais cela ne compte pas. Ce qui compte, c'est où vos informations d'authentification (nom d'utilisateur / mot de passe) sont envoyées, ce qui pourrait être une autre page via des formulaires HTML standard ou une magie JavaScript. Le meilleur moyen est de vérifier la source ou d'activer les avertissements du navigateur concernant l'envoi de données non cryptées.
htth
Si la sécurité est importante: Oui, la page de connexion doit être HTTPS, de même que la page qu'elle publie. Il n'y a simplement pas d'autre moyen.
Si vous visitez une page, et ce n'est pas https, vous ne pouvez absolument pas faire confiance à rien de cette page. Étant donné que la connexion n'est pas protégée, elle peut être facilement altérée (peut-être en le faisant soumettre à une page non HTTPS, ou peut-être soumettre à un domaine totalement différent, que vous ne saurez jamais jusqu'à ce que ce soit trop tard). Alors que si vous visitez une page HTTPS, vous pouvez la faire confiance. Vous savez où la page est originaire et qu'elle n'a pas été altérée. Et bien sûr, vous devez soumettre à une page HTTPS, car vous souhaitez que les données soient cryptées (et que le navigateur devait vous avertir s'il tente de soumettre un formulaire à partir de https page à une page non https).
Désolé pour la fin de la poste, mais je ne pense pas que quiconque dépassait l'élément clé de la façon dont Facebook et Twitter le font. La partie principale est que leur identifiant de connexion non-HTTPS publie une URL absolue sur https . Regardez l'action: Dans ce cas, "Action" d'un formulaire est défini sur UTILISER HTTPS et la poignée de main SSL
Effets avant toutes les données sont envoyées afin que la connexion soit sécurisée. (Si le formulaire d'origine est ou non affiché à l'aide de HTTPS n'a pas d'importance). Toutefois, si l'action de formulaire a utilisé un chemin relative , il serait alors par défaut au protocole utilisé pour afficher le formulaire. En bout de ligne, vous devez utiliser une URL absolue si vous souhaitez établir une session SSL avant que vos informations d'identification soient envoyées.
Je vais probablement être évité mais la réponse est "totalement nécessaire", la réponse correcte devrait vraiment être non. Dans la plupart des situations, cela n'a pas vraiment d'importance. Même hotmail.com et d'autres grands sites ont un signe non crypté des processus, certains vous obligeant à cliquer sur un lien pour goto la page HTTPS.
Cela dépend vraiment de ce que vous sécurisez. Données HIPPA, informations financières Oui Totalement nécessaire. Le forum standard ou tout autre site Web n'a pas d'importance.
L'exécution d'un homme au milieu de l'attaque n'est pas non plus un événement trival, c'est vraiment plus préoccupé par les réseaux hostiles (tels que les réseaux WiFi / Schools / etc.) non pas sur Internet lui-même. Il est généralement impossible d'exécuter un homme vivant à l'attaque moyenne sur le Web lui-même sans compromettre un serveur DNS racine. Cross Site Scripting est beaucoup plus un véritable vecteur d'attaque contrairement à l'homme au milieu qui n'a vraiment pas vraiment pour but d'essayer d'exécuter des grandes banques.
A pris plus de temps que je pensais pour le premier bowvote, mais comme prévu, personne n'a réfuté mes déclarations avec elle.
Ne pouvait pas être plus d'accord. +1 pour ce qui est pratique pour le monde réel.
Intéressant de voir ce point à partir de 2010. De nos jours, lorsque les gens vérifient leur Facebook via WiFi dans des cafés avec des routeurs créés par un barista ... et malgré ce qui est recommandé, ils utilisent le même mot de passe pour toutes leurs informations financières. Je pense que c'est impératif, même les sites les plus triviaux utilisent HTTPS et sont salants / hachage leurs mots de passe.
@ Josephnields I Signifie spécifiquement que la WiFi hostile est la vraie préoccupation. Maintenant, vos déclarations sur le stockage de mot de passe appropriée, il n'y a pas de salle de guérison pour cela. Il est impératif de le faire correctement, malheureusement, je dirais que la majorité le faisait activement.