Connexion sans HTTPS, comment sécuriser?
Pour une webapplication, quand ce dernier n'est pas disponible en tant que mesure de sécurité, est-il possible de faire encore de la connexion un peu sécurisé? E. g.:
- Marquer les connexions, pour faire répéter les attaques difficile?
- En quelque sorte crypter le mot de passe envoyé à partir d'un code HTML champ de mot de passe?
En particulier, je suis en utilisant CakePHP AJAX et un appel POST pour déclencher d'authentification (inclut la condition d'utilisateur et mot de passe).
Mise à jour sur le problème:
- HTTPS n'est pas disponible. Période. Si vous n'aimez pas les la situation, considèrent que c'est une question théorique.
- Il n'y a pas d'exigences précises en matière, vous avez quoi que HTTP, PHP et un navigateur (cookies, JavaScript, etc.) offre dans la vraie vie (pas de magie RSA binaires, PGP plugins).
- Question est de savoir quel est le meilleur, vous pouvez faire hors de ce situation, c'est mieux que d'envoyer les mots de passe en clair. Connaître les inconvénients de chacune de ces solutions est un plus.
- Toute amélioration, mieux que la plaine des mots de passe est la bienvenue. Nous n'avons pas l'objectif de 100% de l33tG0Dhx0r-proff solution. Difficile de fissure est mieux que compliqué de pirater ce qui est mieux qu'une simple reniflement de révéler le mot de passe.
- Comment sécuriser? Quels sont les enjeux (stade dollar de figure peuvent être guide pratique)? Comment les plus puissants sont les agresseurs potentiels? Je ne voudrais pas échanger des stocks, ou de partager mes secrets les plus sombres sur un site qui n'avait pas de SSL. 🙂
- Ce type de sécurité est évidemment pas militaire, financière, ni de niveau gouvernemental. Mais toujours mieux que du texte brut de connexion, ce qui est malheureusement commun pour les petits sites ou des lieux de travail derrière de lourds pare-feu, filtrage HTTPS, ou pour pas cher les sites d'hébergement de ne pas fournir HTTPS (pas même une auto-signé pour un différent de l'URL). La question est intéressé par tous les moyens possibles pour augmenter n'importe quel aspect de la sécurité.
- Pourquoi essayez-vous de faire un point dans le HTTPS est nécessaire. Je sais que le HTTPS ne peuvent pas être entièrement mimiced sur HTTP avec JS/cookies et autres. Il n'y a toujours pas de HTTPS disponibles (Voir description. "Si vous n'aimez pas les la situation, considèrent que c'est une question théorique.") Mais aussi, la plupart des hébergements partagés sont comme ça. Aller à n'importe quel forum de la communauté ou de l'auto blog hébergé ou la plupart des sites, avec moins de 10.000 visiteurs par jour, et vous ne verrez pas un certificat de confiance sur le port 443. Et ils sont encore assez sécurisé! Pourquoi ne pas ajouter un peu plus à leur sécurité? Btw., HTTPS est également pas la panacée.
- À l'aide de JavaScript pour dissimuler votre mot de passe est toujours une violation de (A3 Brisé d'Authentification et de Gestion de Session)owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf C'est un court-lire et c'est très instructif, et c'est mon point final à cet argument.
- J'espère que le fait que presque tout le monde sur TELLEMENT d'accord avec vous les réponses à votre question.
- Tour: les faits et les scénarios, tout comme les exigences, n'est pas démocratique
- comment votre application se défendre contre les attaques de type firesheep ou de traiter avec OWASP A9?
- Je ne sais pas. Peut-être que mon application ne permet pas de se défendre contre FooBarMagicHack9000. Mais la question est néanmoins de ne pas avoir HTTPS disponible et ce que vous faites dans ce scénario particulier pour rendre les choses plus difficile à craquer. SSL est pas la panacée non plus.
- github est maintenant entièrement https à cause de firesheep, facebook et twitter sont bientôt emboîter le pas. Firesheep est rien de nouveau, mais son saumurage attention à OWASP A9. La plus récente problème avec le protocole https est venu à la lumière avec sslstrip, mais c'est facile à défendre contre, il suffit d'activer les STS drapeau. Aussi votre réponse a un -4 parce que n'importe quoi.
- Qu'en JS mises en SSL ? juste trouvé ceci : www-cs-students.stanford.edu/~tjw/jsbn
- intéressant!
- Si vous êtes en cours d'exécution de code via une insécurité canal, cela ne peut pas être fixé, délai. Même si vous pouvez envoyer le code qui établit un canal sécurisé, il ne serait pas question, parce que l'intercepteur suffit de remplacer le code avec les siens. Il faut plutôt se demander comment obscur ce qui se passe pour retarder l'attaquant de la possession de vous.
- Je recommande fortement de changer la réponse à cette question à quelqu'un d'autre, ou de le laisser sans réponse. La réponse actuelle est terrifiant.
- Je pense que la question des besoins de clarification. Ou la answerers besoin de re-lire la question. L'OP ne veut sécuriser la connexion, et non pas l'ensemble du protocole. Peut-être il n'est pas nécessaire pour un jeton de session. Peut-être que l'OP veut seulement pour publier des données en association avec un login comme un processus en une étape, etc.
- J'ai mis à jour ma réponse à proposer une vraie solution. S'il vous plaît changer la réponse à ce poste à quelqu'un d'autre. La sécurité, c'est mon métier, et c'est une grave question qui nécessite une réponse sérieuse.
- Vous ne pouvez pas simuler HTTPS à l'aide de PHP. Il ya beaucoup d'options pour faire de votre connexion plus sûre, mais si HTTPS n'est pas disponible, vous êtes hors de la chance.
- La réponse courte: Vous avez besoin de HTTPS pour avoir une authentification sécurisée. C'est gratuit, pourquoi ne pas l'utiliser?
- Pourquoi croyez-vous HTTPS n'est pas une option? Des hôtes fournir TLS juste beaux de nos jours.
- Je comprends votre frustration avec les réponses qui ne correspondent pas à vos critères. Pour un non-HTTPS solution, s'il vous plaît accepter SLaks réponse à la place. Actuellement accepté de répondre encourage direct hachage de mot de passe avec MD5, ce qui est très cassé, et beaucoup moins sécurisé (contre observateurs passifs dans le style de Firesheep) que SLaks suggestion de l'utilisation de RSA ou de l'AES. C'est une bien meilleure façon de tirer le meilleur de la situation. 🙂
- Pourriez-vous veuillez reconsidérer l'acceptation de l'ESL la réponse? C'est insipide et mal conseil de sécurité. Vous ne pouvez pas obtenir la sécurité par le biais de hachage MD5, et "c'est mieux que rien" est incorrect: un MitM pouvez modifier le JS pour ajouter le texte en clair pour les requêtes HTTP et de capturer des mots de passe de cette façon.
- Votre question est libellée comme suit:
For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure?
. La réponse est "Non". Si votre comme que fait ou pas, n'est pas pertinent. tour de la réponse est la seule bonne réponse à votre question, comme l'a demandé.
Vous devez vous connecter pour publier un commentaire.
HTTPS est absolument vital dans le maintien d'une connexion sécurisée entre un site web et un navigateur. Réseaux publics wi-fi placer les utilisateurs au risque, et lorsqu'il est utilisé correctement, HTTPS est le seul outil qui peut protéger l'utilisateur des comptes de cette vulnérabilité.
Si votre hébergeur ne supporte pas de HTTPS, un service comme Cloudflare Universelle SSL peut être utilisé pour s'assurer que tous les navigateurs se connecter à votre site en utilisant le protocole HTTPS, même si votre serveur ne prend pas en charge SSL/TLS. La connexion entre Cloudflare et votre site web sera toujours non protégés, mais ce service Cloudflare est destiné à protéger les utilisateurs contre les menaces trouvées sur les réseaux publics wi-fi. Du point de vue d'un testeur de pénétration, ne fournissant pas de HTTPS est hautement suspect, si vous n'êtes pas fournir une sécurité de base exigence de générer du trafic, alors que d'autres exigences en matière de sécurité vous manque? Les certificats HTTPS peut être obtenu gratuitement à l'aide de Let's Encrypt ou Start SSL, il n'y a pas de raison légitime de ne pas soutenir le protocole HTTPS.
HTTPS essentiel, car il fait beaucoup plus que simplement "chiffrer les mots de passe". Un autre rôle important, c'est qu'il devrait éviter à l'utilisateur de donner en se connectant à un serveur malveillant qui est en usurpant l'identité d'un serveur réel. À l'aide d'un système pour protéger le mot de passe seul est encore une violation de OWASP A9 - Insuffisance de la Protection de la Couche Transport parce que vous auriez encore être la transmission d'informations d'identification de session en texte brut qui est l'attaquant besoins (Firesheep).
JavaScript basé sur la cryptographie ne peut pas être utilisé pour construire une couche de transport sécurisée.
"Marquer les connexions": Si un attaquant est reniflant
le trafic, ils ont la plaine de texte nom d'utilisateur/mot de passe, puis
ils peuvent se connecter avec ces nouvelles informations. (Replay attack)
"En quelque sorte de crypter la transmission de mot de passe": Après que la personne s'est connecté
un attaquant peut sniffer le trafic pour obtenir la validité de la id de session
(cookie) et puis juste utiliser ce lieu de connexion. Si l'
toute la séance a été protégée avec le protocole SSL/TLS alors ce n'est pas un problème.
Il y a d'autres plus complexes attaques qui touchent à la fois de ce système et de notre actuel infrastructure SSL. Le SSLStrip attaque va dans le plus grand détail. Je recommande fortement regarder Moxie Marlinspike du Blackhat 2009 parler, qui conduisent à la HTTP-Strict-Transport-Security standard.
Puisque vous ne pouvez pas faire SSL sur le serveur web, et vous n'êtes pas un expert en matière de sécurité, de regarder, de l'existence d'un service d'authentification sécurisé que vous pouvez utiliser, et de les laisser gérer à la fois le SSL et la complexité de la manipulation des informations d'identification pour vous.
En particulier, je vous suggère d'avoir recours à un tiers de service d'authentification, tels que OpenID. Ils ont des bibliothèques pour PHP dont une pour CakePHP.
Edit: (au sujet des risques)
Tout en utilisant un 3e partie de service d'authentification sécurisé (qui utilise le protocole HTTPS lui-même) peut atténuer le problème en faisant de l'authentification elle-même sans l'aide de HTTPS (sur votre serveur), il n'a pas d'éliminer complètement la possibilité d'attaques.
Le plus commun des deux attaques pourraient être replay attaques, et session détournement où l'attaquant est en mesure de ré-utilise un véritable connexion jeton de session plus tard, ou l'utilisation d'un jeton de session valide pour leur propre but malveillant.
La relecture d'attaque peuvent être atténués par le fait que le jeton de session date d'expiration, et de préférence en utilisant un pour l'instant pour empêcher la session de relecture et de réduit les risques de détournement de session. Avec un nonce, une légitime session génère une erreur si ont été détournés, parce que le nonce a expiré (été utilisé), de sorte que leur propre session n'est plus valide.
Si vous ne pouvez pas utiliser le protocole HTTPS pour chiffrer le jeton de session, tout en étant transmis vers et à partir de votre serveur, vous ne pouvez pas tout à éviter les attaques actives telles que session détournement ou man-in-the-middle attaque. Cette peut être acceptable dans certains cas, tels que les sites web avec une petite base d'utilisateurs pour les non-utilisation commerciale.
La réponse courte est que sans SSL extrémité à l'autre de chiffrement, il est impossible de le faire en toute sécurité...
L'une des principales raisons pour cela est que vous ne pouvez pas faire sécuriser crypto dans un navigateur. Voir cette référence - Javascript Cryptographie Considéré comme Nocif.
En outre, il n'ya aucun moyen que vous pouvez être sûr que la source des informations d'identification sont en effet à qui vous vous adressez. Ce qui signifie que il n'y a absolument aucun moyen sans SSL pour être sûr qu'il n'y a pas un Man-In-The-Middle Attack passe.
Donc non, vous ne pouvez pas le faire.
En outre, n'essayez même pas. Obtenir SSL. Vous pouvez obtenir gratuitement des certificats. Les hôtes seront généralement vous donner une IP dédiée pour quelques $$$ par mois. Et si vous vous souciez vraiment de la sécurité, vous seriez à l'aide d'au moins une machine virtuelle avec une adresse IP dédiée tout de même.
Même tenter ce serait La Sécurité Par L'Obscurité au mieux, rien de pire. SSL est un problème résolu. Pourquoi ne pas utiliser cette solution. La sécurité n'est pas quelque chose à deviner. Utiliser les techniques appropriées. N'essayez pas d'inventer votre propre. Il ne fonctionne pas...
Comme vous l'avez suggéré, vous pouvez être en mesure de générer un code unique à chaque fois que la page est créée. Même jeton devra être envoyé avec les données du formulaire et ne peut être réutilisé. Vous pouvez également maintenir la sécurité du mot de passe en utilisant le JavaScript pour le hachage, si vous le pouvez compter sur elle étant activé par vos utilisateurs.
Ce schéma n'est pas encore sûr, cependant. Un attaquant pourrait toujours voir tout ce qui se passe à travers le fil. Ils pourraient intercepter le jeton et envoyer une réponse à vous avant que l'utilisateur ne. Ou ils pourraient simplement attendre que quelqu'un de connexion, voler que personne les informations d'identification (comme ils sont envoyés sur le fil), et juste faire leur propre demande de connexion plus tard.
Bas de Ligne - vous devez utiliser le protocole HTTPS pour garantir que le site est sécurisé.
Vous pouvez crypter le mot de passe à l'aide de Javascript et de décrypter sur le serveur.
Je recommanderais générer une paire de clés RSA sur le serveur, envoyer la clé publique avec un temps de sel pour le navigateur, puis le chiffrement du mot de passe, combiné avec le sel, à l'aide de la clé publique en Javascript.
Vous pouvez trouver un RSA implémentation en Javascript ici
Vous devez inclure à la fois l'adresse IP et l'ensemble de la X-FORWARDED-FOR hedaer dans les cookies d'authentification pour éviter le vol de cookie derrière des proxys.
Si vous avez affaire à des données sensibles, vous pouvez générer un hasard La clé AES en Javascript, puis de l'envoyer vers le serveur avec le mot de passe crypté avec RSA.
Vous pouvez ensuite faire l'intégralité de l'utilisation de l'application chiffrée des requêtes AJAX à partir d'une seule page et ne pas utiliser une authentification par cookie à tous.
Noter qu'il n'est pas possible de se protéger contre un homme actif-dans-le-milieu-attaque sans SSL. Un actif attaquant peut remplacer complètement votre site avec son propre proxy, et il n'y a aucun moyen de se défendre contre ça. (Car il ne peut pas être connu du bon code)
Vous pouvez utiliser HTTP Digest d'authentification, qui est pris en charge par la plupart des navigateurs et ne pas envoyer le mot de passe en clair sur le réseau.
L'inconvénient est laid le journal dans la boîte affichée par le navigateur. Si vous préférez rester avec les formulaires, vous pouvez appliquer exactement le même protocole que HTTP Digest dans vos formulaires authnetication: envoyer les champs cachés contenant le royaume et le défi, et le client d'ajouter dans le code JavaScript du nonce et de calculer le digérer. De cette façon, vous allez utiliser un bien connu et éprouvé, à l'échange de protocole, plutôt que de rouler votre propre.
HTTP Digest ne nécessite que les opérations de hachage.
Ce sujet Authentification HTTP Digest? Il assure la sécurité par hachage MD5 nom d'utilisateur, mot de passe et un nonce (entre autres choses) avant de les envoyer au serveur. MD5 n'est pas vraiment sûr, mais c'est un bon moyen de sécurité simple avec HTTP.
Bien sûr, cela n'empêche pas les pirates de modifier le message... mais il sécurise votre mot de passe.
HTTPS a de nombreux cas d'utilisation, dont la plupart sont conçus pour se défendre contre Man-in-the-middle attaques. N'importe qui avec un pirate de l'état d'esprit frémiront de vous dire qu'il n'existe aucun moyen autre que l'établi de façon à accomplir quelque chose. Le fait est que juste parce que vous utilisez le protocole TLS (la norme moderne HTTPS utilise), ne signifie pas que vous utilisez bien. En outre, l'utilisation de TLS qui n'empêche pas quelqu'un d'exploiter les faiblesses connues. Comme vous pouvez peut-être trouver des moyens créatifs pour sécuriser vos données, il y a des gens qui sont à la recherche de moyens créatifs pour exploiter vos mesures de sécurité.
Alors, que faire?
Tout d'abord, si vous allez renoncer à TLS, il est utile de comprendre comment il fonctionne. Et il est tout au sujet d'une poignée de main.
Source: Wikipédia
Donc est-il possible? Oui. On m'a appris que tout est possible. Il peut être cher, mais c'est toujours possible.
Je veux divulguer complètement que je ne suis PAS un professionnel de la sécurité, juste un passionné. Je ne recommande pas d'essayer ce pour une production de qualité du projet ou quoi que ce soit d'autre que votre propre édification. Vous devriez CERTAINEMENT vérifier cette SORTE de post qui fournit une excellente explication à des barrages routiers dans la création de votre propre protocole de sécurité.
Cependant, si vous souhaitez vous déplacer sur, ici sont quelques idées qui vous viennent à l'esprit. Ce sont des réalités qui existent indépendamment de qui direct vous êtes allé avec ce projet.
HTTPS est pris en charge par tous les principaux navigateurs modernes. Même avec cette réalité, HTTPS temps de chargement sont plus lent que la plaine HTTP. L'étendue de la production, il est fortement probable que votre alternative sera une fraction comme plus sûr, tout en étant nettement plus lent. Ce sera un inconvénient de toutes les endogène de la mise en œuvre, sauf si vous êtes en utilisant des fonctionnalités du navigateur, ce qui nous ramène en arrière à l'aide du protocole TLS, ce qui est le moderne HTTPS utilise.
Si vous parvenez à crypter votre mot de passe sans TLS côté navigateur à l'aide de Javascript dans un assez imprévisible de la mode, qu'une attaque de type MiTM serait difficile de ne pas en rester là. Vous devez également être en sécurisant les données que vous envoyez et-vient. Sinon, le mot de passe crypté est vraiment hors de propos. Bien sûr, un attaquant pourrait ne pas savoir bobsmith109 du mot de passe, mais il n'en a pas besoin, parce qu'il peut renifler chaque activité sur le réseau. Il sait ce que le temps de bobsmith109 connecte, peut sans doute retrouver son IP, et tout autre élément sensible de données que vous envoyez en arrière et en avant.
Peu importe ce que les mesures de sécurité à prendre, il y a une sécurité en profondeur. Donc, une chose que vous pouvez faire droit au large de la chauve-souris est assurez-vous de crypter vos données dans la base de données tout en exigeant des mots de passe forts.
Je répète que je suis pas un professionnel de la sécurité et de la fortement décourager ce que rien d'autre que pour assouvir votre curiosité. Il est astronomiquement improbable que vous pouvez créer une alternative viable à TLS sans extraordinairement grand groupe de professionnels de la sécurité à contribuer à un projet pendant des années, voire des décennies, qui est ce que SSL/TLS peut se vanter. Cela étant dit, un bon point de départ si vous choisissez d'aller de l'avant est de regarder la poignée de main modèle ci-dessus et de voir comment vous pouvez mettre en œuvre une version de ce sans TLS.
Je m'en voudrais de ne pas partager dans mon post que la plupart de la vie réelle des obstacles à l'aide de HTTPS sont activement lutté contre. L'un des plus importants - le coût est très proche de devenir un non-problème. Gratuitement un certificat de l'autorité seront à venir 2Q 2015 est pris en charge par certains gros canons, y compris Mozilla et Akamai, pour n'en nommer que quelques-unes. Voici un article.
Vous pouvez essayer de le reproduire à un certain point, par l'aide de la clé publique de chiffrement GPG (peut-être), et d'utiliser le cache du navigateur.
Le reste de la réponse est juste de la nourriture pour la pensée.
encrypt
fonction, à trouver un algorithme de cryptage sécurisé. Cette fonction doit crypter une chaîne de caractères (forme sérialisée) avec un supplément de timestamp, pour éviter une réplication de l'attaque.Cache-Control:public, max-age=31536000
en-tête HTTP. Nous essayons d'atténuer lorsque l'attaquant tente de remplacer le script. Le fichier sera toujours servies depuis le cache du navigateur.encrypt
fonction. Servir avec le même en-tête ci-dessus.decrypt
les données, vérifier l'horodatage, si elle est encore valide. Pensez-vous, si non, il faut jeter.Auditeurs de ne pas être en mesure de faire usage de la data va-et-vient, et ils ne seront pas en mesure de modifier/d'injecter de l' existant
JS
fichiers jusqu'à ce que le cache expire /utilisateur efface le cache. Cependant, toute sophistiqué attaquant peut remplacer l'ensemble de laHTML
fichier qui serait jeter toutes les mesures de sécurité que je viens de mentionner. Si vous pouvez au moins servir de ce fichier /forme plusHTTPS
, vous pourrait sortir avec elle, les mettre sur github pages ou quoi que ce soit. Toutefois, si vous placez le fichier de quelque autre domaine, vous devez configurerCORS
pour la réception de domaine pour que cela fonctionne., Essayez un autre
Une seule fois les mots de passe envoyé à l'email.
Dans l'ensemble, quoi que vous fassiez, il est pas sûr. Rapidement, sophistiqué attaquant, rien ne s'oppose à la voie.
Obtenir SSL, si l'infrastructure ne prend pas en charge, de les changer. Si votre manager ne croit pas en SSL, le convaincre en lui/elle. Ne pas créer un faux sentiment de sécurité. Protéger vos données de l'utilisateur, en fonction de votre emplacement, vous êtes légalement tenu de protéger les données de vos utilisateurs.
Ensuite, nous allons parler de la façon de faire un site sécurisé avec SSL.
Connexion sans HTTPS, comment sécuriser?
Car il n'y a pas de canal sécurisé entre votre serveur et votre client:
Que pouvez-vous faire? Sur le papier?
Mais attendez... il dit pas de la magie binaire, ou le plugin, même pas le RSA, je ne sais pas si c'est possible d'enregistrer pour (certains potentiellement très faibles) dans maison de chiffrement.
--
Ont un coup d'oeil à "Le Protocole De Mot De Passe À Distance Sécurisé".
Plutôt que de formuler moi-même, permettez-moi de citer à partir de leur site web:
et:
Bien que l'Université de Stanford ne pas fournir des implémentations pour PHP et JavaScript eux-mêmes, ils sont liés à certains de la 3e partie des implémentations.
Un de ces liens, conduit à "Clipperz", qui est en ligne gestionnaire de mot de passe. Il est également disponible en tant que community edition sur GitHub. Là, ils accueillent leur "javascript-bibliothèque de chiffrement", qui met en œuvre le protocole et la "mot de passe manager" lui-même, qui contient des backends écrit en PHP et Python.
Je ne peux pas dire combien il serait difficile d'extraire les parties pertinentes du code, mais peut-être que vous pouvez réutiliser à leur mise en œuvre (il est sous licence AGPL).
Modifier 2014/10/24:
L'article de Wikipedia sur PRS quelques listes de plusieurs mises en œuvre. Pertinentes pour PHP/JS:
Créer une paire clé publique/privée à l'aide d'un chiffrement asymétrique.
Créer une clé symétrique sur le serveur.
Envoyer la clé publique vers le bas pour le côté client.
Créer une clé aléatoire pour le symétrique de chiffrement côté client.
Chiffrer que la clé aléatoire à l'aide de la clé publique du côté client.
Envoyer la clé cryptée sur le serveur.
Server effectue les opérations suivantes:
un. Décrypte l'aléatoire de la clé symétrique à l'aide de la clé privée.
b. Crée un jeton contenant le client généré la clé.
c. Signes le jeton.
d. Crypte le jeton à l'aide du serveur de clé symétrique.
e. Chiffre déjà en chiffré jeton avec le client de la clé générée.
f. Envoie le jeton crypté vers le bas.
Le client reçoit ce jeton et effectue les opérations suivantes:
un. Déchiffre le jeton avec la clé qu'elle a généré.
b. Les magasins de la décrypté jeton.
c. À ce stade, le jeton stocké est uniquement chiffré avec le serveur de clé symétrique.
Sur chaque du client vers le serveur:
un. Chiffrer les sortants de données à l'aide du client clé générée.
b. Envoyer le jeton + données chiffrées
Sur chaque requête, le serveur reçoit:
un. Décrypter le jeton à l'aide du serveur de clé symétrique.
b. De vérifier la signature.
c. Décrypter les données à l'aide de l'généré par un client clé stockée dans le jeton.
La meilleure solution que j'ai vu, un peu de sécuriser les connexions HTTP, est d'utiliser un Javascript de mise en œuvre de md5sum (ou hash) pour éviter de transmettre le mot de passe en clair dans le texte. Vous pouvez créer un formulaire onsubmit gestionnaire en Javascript qui remplace le champ mot de passe avec un hachage de la valeur d'origine. Cela ajoute une quantité modeste de sécurité pour une connexion non sécurisée, mais s'appuie sur le code Javascript s'exécutant dans le navigateur pour fonctionner correctement.
Je suppose que vous vous souciez de sécuriser la transmission de mot de passe pour le serveur? Ma réponse est: à ne pas transmettre des mots de passe pour le serveur 🙂
Enfaite vous ne pouvez pas transmettre quoi que ce soit à partir du navigateur (user) de serveur pour authentifier l'utilisateur, comme un attaquant qui est de l'espionnage http circulation serait également en mesure de retransmettre les données et l'authentification.
Proposition:
La solution la plus évidente serait d'utiliser un chemin, d'une transaction d'authentification provenant de serveur; comme un numéro de transaction qui ne peut être utilisée qu'une fois. Finalement, vous avez encore besoin d'un canal sécurisé une fois pour synchroniser la liste de numéros de transaction avec l'utilisateur.
Vous pouvez utiliser quelque chose google authenticator, mais vous avez besoin d'un canal sécurisé une fois pour configurer les paramètres de chaque côté. Si vous envisagez d'e-mail pour être sûr, que serait un moyen d'aller.
J'ai le même problème sur un système de mine. J'ai pris des mesures pour augmenter la sécurité sans compromettre l'expérience de l'utilisateur avec alambiqué mécanismes. Ce que j'ai remarqué c'est que la grande majorité des utilisateurs connectés à partir de la même machine, en utilisant le même navigateur (mais pas nécessairement la même adresse IP), ou à partir d'un couple de navigateurs (ex: ordinateur de bureau ou portable). J'ai décidé que je pouvais l'utiliser pour identifier un modèle.
1) Lors de l'inscription, les utilisateurs sont tenus d'avoir des mots de passe forts (pour éviter les attaques par dictionnaire), un question/réponse de sécurité et de standard de vérification des e-mails (comme preuve de personne réelle)
2) Lors de la connexion, après 5 tentatives infructueuses de connexion (pas avant), un captcha s'affiche pour prévenir les attaques par force brute.
3) Enfin, j'ai créé une table de hachage de parties de la chaîne de l'agent utilisateur après une connexion réussie, contenant les utilisateurs de l'OS, le navigateur (pas les versions) et de la langue formant une sorte de mot de passe secondaire. Si le useragent de hachage est significativement différente à la prochaine connexion, l'utilisateur est invité à répondre à la question de sécurité. Alors, si c'est une réponse satisfaisante, la nouvelle chaîne de l'agent utilisateur est haché et ajouter à leur "sécurité des machines" de la liste, de sorte qu'elles ne seront pas demandé à nouveau à partir de cette machine. Ceci est similaire à un mécanisme employé par la Vapeur du système de jeu.
Ce qui a été en usage depuis plus d'une année avec beaucoup de succès avec environ 700 utilisateurs et il a l'avantage supplémentaire de prévenir le "partage de connexion" - un problème où plusieurs utilisateurs ont été en utilisant les mêmes informations d'identification pour des raisons de commodité!
La réponse est plus court, et si vous avez vraiment question au sujet de la sécurité vous avez toujours des options que les différents niveaux de bureauocracy.
Absolut de sécurité n'existe pas. Le numéro un de la faille est toujours sur le côté client, avec chevaux de troie sna les enregistreurs de frappe. SSL n'aide pas avec qui.
1) Jeton générateurs: les banques utilisent leur, blizzard utilise ensuite. Il peut être un périphérique ou une application. Eh bien.. c'est cher.
2) SMS broches. intéressant et abordable solution. Il y a beaucoup de bons prix à partir de trnasactional sms sur le marché et tout le monde a un téléphone capable de recevoir.
3) Si vous devez utiliser HTTP, vous pouvez forcer un tiers service oauth, comme google ou facebook. C'est le meilleur que vous pouvez faire sans un générateur de jeton.
L'utilisation de mécanismes de hachage pour stocker les mots de passe et de toujours comparer le mot de passe haché puis personne ne connaît le vrai mot de passe, même vous.
Il est très simple mais c'est efficace.Cependant, rien n'est complètement sûr et il existe des moyens pour cassé le scurity couches.
Si vous ne pouvez pas utiliser HTTPS ou vous ne voulez pas utiliser le protocole HTTPS, pensez à utiliser jCryption. jCryption offre de cryptage pour les données envoyées par le biais de requêtes HTTP (POST, GET, etc.).
Vous pouvez tester la technique ici: http://www.jcryption.org/#examples
Si vous êtes à l'aide de Firebug, vous verrez que toutes les données sont cryptées.
Il a bibliothèque jQuery pour chiffrer les données sur le front-end et une bibliothèque PHP pour déchiffrer les données dans le back-end.
Essayez ceci : À chaque demande de la page de connexion, envoyer à travers un nonce et un horodatage.
Pendant l'envoi au serveur, envoyer les quatre détails :
De l'utilisateur, le nonce et l'horodatage en clair.
Puis concaténer ci-dessus, avec un séparateur (par exemple: saut de ligne) et de crypter à l'aide de l'utilisateur mot de passe de cryptage dans les enchaînés-bloc-mode de chiffrement.
Sur le serveur de fin d'utiliser le nom d'utilisateur de rechercher le mot de passe et vérifier la chaîne cryptée.
Puisque le mot de passe n'est jamais transmis à travers en clair, il est sécurisé et l'horodatage peut être utilisé pour éviter une re-soumettre des mêmes données.
Pour éviter le détournement de session par l'obtention de la clé de session par le biais d'un man-in-the-middle attack, le mot de passe ou un hachage du mot de passe peuvent être stockés en mémoire par l'application sur le poste client et être utilisé pour produire de l'unique clés de session pour la validation par le serveur.
De prendre un coup d'oeil à OAuth 1.0 est également pas une mauvaise idée.
Il est dur pour sécuriser la communication sans
trusted third party
, cependant, il y a une certaine sécurité astuces pour vous:NE PAS exposer les utilisateurs à l'information sensible réseau public.
Toutes les informations sensibles doivent être bien hachée ou de la clé publique chiffrée. Attention: Si vous choisissez de crypter des utilisateurs de l'information sensible par une clé publique, assurez-vous que l'utilisateur peut vérifier la clé publique. Par exemple, vous pouvez envoyer une sorte de clé publique d'empreintes digitales de l'utilisateur par l'intermédiaire de SMS ou même un auto-appel.
Générer un SECRET PARTAGÉ après la connexion avec succès
Après une connexion sécurisée sur la transaction, un secret partagé doit être générer. La procédure de génération pourrait se référer à
SSL Handshake
. Attention: une Fois le secret partagé est créé, il doit être transporté plus. La seule fonction est de crypter/décrypter les données entreServer
etBroswer
Il DEVRAIT y avoir un deux-étape de vérification afin d'éviter la répétition d'attaque
Que ces astuces vous aideront à