Accès sécurisé: chiffrement à clé publique en PHP et Javascript

Je suis en train de faire un "normal" nom d'utilisateur/mot de passe formulaire de connexion sécurisée, sans avoir besoin de HTTPS. Mon idée est la suivante:

  • Serveur génère une paire de clés pour une sorte d'algorithme de chiffrement assymétrique. Il stocke cette paire de clés dans une table temporaire de toutes sortes (ou peut-être le local des données de session).
  • Serveur envoie le formulaire au client et inclut la clé publique.
  • Utilisateur remplit le formulaire.
  • Avant d'être envoyé au serveur, Javascript crypte le mot de passe à l'aide de la clé publique.
  • Formulaire est envoyé.
  • Serveur déchiffre le mot de passe avec sa clé privée (qu'il obtient à partir de la table temporaire, à l'aide de la clé publique pour le trouver).

Ce que j'ai besoin de savoir pour cela est:

  • Méthode de chiffrement qui est le meilleur à utiliser? RSA?
  • Comment décrypter le mot de passe en PHP?
  • Et probablement la plus difficile, comment puis-je faire Javascript crypter le mot de passe?
  • Toujours utiliser SSL/TLS avec des certificats valides. Si vous avez des raisons autres que la sécurité du réseau de chiffrer la connexion (tels que la prévention de côté de serveur de mot de passe debug/arrêt/normal/etc. exploitation forestière, qui peuvent ensuite être récupérés par un attaquant), vous pouvez utiliser ceci: stackoverflow.com/questions/12457234/...
InformationsquelleAutor Bart van Heukelom | 2009-10-06
  1. 17

    À l'avance: je suis désolé d'être négatif, cependant;

    La mise en œuvre de votre propre protocole de sécurité est jamais une bonne idée, sauf si vous êtes un hautement formé d'experts de la sécurité, ou vous ne pas vraiment se soucier de la sécurité et que vous souhaitez uniquement créer une impression de sécurité (marketing) et arrêter le script kiddies.

    SSL n'est certainement pas une serrure d'empreinte digitale, comme si le dire dans vos commentaires, JCryption et votre proposition sont égales à avoir une porte où vous pouvez entrer un code à deux chiffres pour ouvrir la porte et vous avez infini de nombreuses tentatives. Il est difficile de se briser si vous n'êtes pas vraiment intéressé et juste de passage, mais si vous voulez obtenir dans la maison (et vous n'avez probablement, sinon de sécurité ne serait pas nécessaire), vous obtiendrez en.

    Un autre point est que les gens oublient souvent de mentionner ce qu'ils veulent atteindre. La sécurité est le célèbre trois composants appelés de la CIA, à savoir la confidentialité, l'intégrité et la disponibilité. Est-il important pour vous que les données que vous avez le transport est confidentielle, ou de l'intégrité est importante (c'est à dire, vous êtes sûr que les données envoyées vient de celui que vous attendez, et non l'homme au milieu)?

    Pour en faire du béton dans ce cas, la seule chose que vous devez faire ici, c'est que le passif d'un attaquant ne peut pas voir ce qui est de passage sur la ligne. Dès que votre agresseur s'active et les changements les messages sur leur route, l'ensemble de votre sécurité tombe à l'eau. Donc, mon conseil serait de simplement s'en tenir à la solution les experts sont venus avec TLS (dans ce cas, pas de ssl, puisque c'est l'ancienne version de celui-ci) et assurez-vous que votre serveur la prend en charge.

    edit:

    Btw, SSL/TLS ne peut pas fonctionner sans certificats. Le point entier dans la clé publique de chiffrement est qu'il doit y avoir au moins quelque partie de confiance.

    Sur l'autre main, si vous ne vous inquiétez pas que vos utilisateurs d'obtenir un "certificat non valide" s'affiche, vous pouvez tout simplement créer votre propre certificat et qui est vraiment facile. Dans ce cas, votre certificat n'est pas approuvé par les navigateurs, cependant, vous pouvez être sûr que votre communication est sûr (bon d'accord, il y a des exceptions dans ce cas, mais quand même ...)

    L'argument que les certificats doivent être gratuits est vraiment d'un point de vue point de vue. Je pense que les gens qui prétendent que c'est faux/idiot ne sais pas ce qu'il faut pour être une autorité de certification. Ces entreprises investissent des millions dans le but de garder la communication sécurisé, et bien sûr ils ont beau faire de l'argent de la vente de certificats, mais bon c'est leur travail et ils méritent aussi de faire de l'argent, comme toutes les autres.

    edit2: après les commentaires

    J'ai effectivement dire que vous avez une communication sécurisée. Cependant, vous manquez le point qu'avec les certificats auto-signés, vous ne savez pas à qui vous parlez en toute sécurité. Imaginez une pièce sombre qui est complètement isolé de l'écoute clandestine d'une conversation. Maintenant, imaginez la différence entre une pièce de ce type avec et sans lumière. Si la pièce a de la lumière, vous pouvez réellement voir à qui vous parlez en toute sécurité et seulement choisir de parler à des gens que vous aimez à la confiance. Imaginez faire la même dans une pièce sombre. Vous pouvez seulement espérer que le gars que vous parlez à l'intérieur de cette chambre noire, c'est juste un allié et non celui de votre adversaire. Cependant, vous ne pouvez pas savoir que, juste espère que c'est ok. Et bien que votre conversation en lui-même est sûr, personne ne peut écouter, vous n'avez pas le "plein" de sécurité.

    Si je, être un escroc, faire un " man-in-the-middle attack, je peux créer un certificat auto-signé sans que l'utilisateur ne s'en aperçoive. Donc l'avantage de l'utilisation de TLS avec les certificats auto-signés, c'est que vous avez au moins la mise en œuvre du protocole corrent (et même la mise en œuvre de ce qui est loin d'être facile). En outre, vous pouvez éviter le vilain avertissements par le conseiller à vos utilisateurs manuellement confiance à ce certificat à la fois. Cependant, cela n'est possible que si vous avez un groupe relativement restreint de visiteurs, pour un site web public, ce n'est pas vraiment une solution.

    • Vous êtes très à droite quand il s'agit de vraiment sensible des trucs comme la banque. Je suis, cependant, en effet, seulement d'essayer d'arrêter le script kiddies ici.
    • Aussi, puisque vous semblez en fait de proposer des certificats auto-signés, pourquoi devrait-il pas y avoir un système où c'est possible sans laide des avertissements. Après tout, c'est comme vous le dites: alors "vous pouvez être sûr que votre communication est sûr"
    • Aussi (désolé pour le triple commentaire) +1 car, si il m'arrive d'être en désaccord, votre post est bien écrit.
    • Je salue le fait que les navigateurs commencent à faire un grand tapage sur les certificats auto-signés. Cela signifie que nous pourrait commencer à s'éloigner de ces floue jours où les utilisateurs juste vu un bouton "Accepter" et cliqué sur elle, les mises en garde d'être damnés. Au moins si quelqu'un voit un grand rouge de la page, s'affole et annule le processus, c'est une sécurité infaillible.
    • Je suppose que tu voudrais entendre que j'ai développé depuis plus expérimentés et maintenant de comprendre pourquoi que le chiffrement ne serait pas assez sécurisé. Nous sommes maintenant en utilisant réel de TLS pour notre formulaire de login. Mais, je pense toujours que certificateless de chiffrement doivent être disponibles et utilisés par défaut (à l'exception du cas où la performance l'emporte sur la sécurité) pour tous les amateurs de sites, même si elle est faible, simplement parce que c'est mieux que rien.
    • Si vous pensez toujours que l'utilisation du Javascript approche est mieux que rien, et donc, la peine de le faire, votre réponse devrait être celle qui te dit comment faire, ne yo pensent?

    InformationsquelleAutor Henri
  2. 10

    Cela ne semble pas qu'sécurisé à partir du point de vue du client. Deux (relative) des problèmes:

    1. La façon dont le client fait confiance au serveur? Comment peut-il vérifier que la clé au serveur de présentation est celle qui appartient-il?
    2. Il est possible de faire " man-in-the-middle attaques. Un proxy malveillant pourrait en extraire et de stocker la clé publique avant que le client voit, substituant sa propre, puis déchiffrer le mot de passe lorsque le client s'authentifie, les stocker, et re-crypter et envoyer la réponse sur afin que le client ne se rend pas compte que quelque chose en place.

    Quel est le problème avec ordinaire SSL? Il y a consensus pour dire que c'est sûr, sinon les vendeurs et les organisations de drop de soutien pour toute la nuit. En revanche, la plupart des tentatives pour inventer un funky nouvelle façon de faire de la sécurité "sur le bon marché" généralement manquez pas quelque chose de fondamental.

    • Il n'y a aucun moyen de vérifier l'identité du serveur, c'est vrai. Mais est-il question? Un vrai certificat SSL est juste ne va pas arriver, et c'est mieux que rien...beaucoup mieux. SSL est comme vous pouvez soit mettre pas de serrure sur votre porte ou d'un scanner d'empreintes digitales. L'ordinaire de verrouillage avec une clé de métal n'est pas disponible.
    • Je prétends que c'est pire de rien, parce qu'elle est en vous donnant un faux sentiment de sécurité. Un vrai certificat SSL peut être eu pour 30 $ - vos données sont vraiment la peine de moins de 30$?
    InformationsquelleAutor Rob
  3. 3

    Il semble que beaucoup de ce que vous voulez faire est fourni par le plugin jquery JCryption. Elle même n'assume PHP comme le back-end, c'est un bon ajustement pour vous.

    • JCryption est excellent si vous voulez un théâtre de sécurité: securityfocus.com/archive/1/520683 Si vous voulez un vrai de sécurité de l'essayer phpseclib, un véritable PHP RSA de mise en œuvre (selon les recommandations de l'securityfocus.com la divulgation)
    InformationsquelleAutor Jacob Mattison
  4. 1

    Livejournal fait quelque chose de similaire à ce que vous voulez et où:

    1. Serveur génère une chaîne de stimulation, l'insère dans la forme. [Un]
    2. Client génère la réponse par le hachage MD5 du mot de passe, puis le hachage MD5 de la précédente valeur de hachage avec le défi préfixé [Deux].
    3. Serveur reçoit la réponse, de contrôles, de contester la validité, alors même que l'étape 2, en comparant le résultat de la réponse.
    InformationsquelleAutor Hasturkun
  5. 0

    C'est une très bonne idée, et ça a déjà été fait. Voir jCryption.

    InformationsquelleAutor slikts
  6. 0

    jCryption semble intéressant, je ne l'ai pas vu avant.

    Mais je dois demander quel est le problème avec SSL?

    Code de cryptage est notoirement difficiles à faire, et vous pouvez parier que les implémentations SSL trouvé dans les navigateurs et les serveurs http sont beaucoup plus rigoureusement testé et révisé de la jCryption choses.

    Cela dit, jCryption a l'air soigné, si vous devez absolument éviter de SSL, et vous n'êtes pas affaire avec des super-sensible de l'information.

    • Oh oui, le protocole SSL est très bien, sauf pour un idiot conception de la décision qu'ils ont prise: Vous avez besoin d'un certificat, et cela coûte de l'argent. Si ils avaient fait en sorte que vous pouvez avoir de cryptage sans la validation de l'identité de la partie, le chiffrement aurait été utilisé plus souvent que pas, et le net aurait été plus sûr tout à fait.
    • La validation de l'identité est nécessaire pour que le certificat puisse être signé. Si elle n'est pas signé, les clients n'ont aucun moyen de savoir si oui ou non ils sont présentés avec un faux certificat. L'argument qu'il "coûte de l'argent" est assez boiteux, étant donné que beaucoup de fournisseurs d'hébergement souvent bundle un parfaitement bon certificat SSL, ou l'offrir pour un petit supplément. Si vous êtes sérieux au sujet de l'exploitation dans un environnement où vous êtes tenus de respecter certaines normes de sécurité, alors vous allez avoir à accepter, il va y avoir des coûts.
    • Vous pouvez toujours créer votre propre, auto-signé, Certificat SSL. Bien sûr, les navigateurs ont commencé à réaliser que même les plus effrayants pour les utilisateurs qu'ils ont utilisé pour. Mais j'ai tendance à accepter que le coût argument est bidon. Programmeur de temps pour mettre en œuvre votre chemin autour de payer pour un certificat SSL coûte aussi de l'argent.
    • Voir mon commentaire de Rob réponse. Aussi, si SSL n'a pas besoin de signer des certificats, il serait probablement être la norme. Sécuriser les sites seraient plus nombreux que les non sécurisés ceux, de loin, et même le plus petit hobby site sont sécurisées, en fournissant le serveur/hôte valeurs par défaut sont définies comme ça.
    • Afin de clarifier Rob commentaires: Le cryptage partie est INUTILE sans la validation de l'identité de la partie. Une solution telle que l'affiche décrit est trivialement vaincu par un attaquant qui a la capacité de se déplacer entre le client et le serveur. On appelle ça un "homme du milieu" attaque et l'idée est très simple: le Serveur génère une paire de clés, envoie la clé publique. Attaquant intercepte page, remplace la clé publique avec les siens. Client crypte le mot de passe avec l'attaquant de la clé publique et envoie la réponse. Attaquant décrypte le mot de passe, le chiffre avec la clef publique du serveur et l'envoie au serveur.
    • swillden est tout à fait exact. Si l'information est digne de protection, il vaut la peine de protéger le bien. "Blindée" de chiffrement qui peut être défait par l'homme-dans-le-milieu crée un dangereux faux sentiment de sécurité.
    • Je suis le seul à essayer d'arrêter le script kiddies. C'est tout simplement pas la peine d'aller tout le chemin, et c'est au moins mieux que rien. Vous ne pouvez vraiment pas d'accord avec une telle logique simple 😉
    • En essayant de l'empêcher de quoi, exactement?
    • Le nombre de personnes qui sont à la fois intelligent et assez motivé pour intercepter vos communications, mais pas intelligent et motivé suffisant pour casser votre trivialement cassables régime, doit sûrement être extrêmement petite.
    • Vous pouvez toujours en désaccord avec la logique défectueuse, cependant. Vous semblez être assurément par l'avis que le protocole SSL intègre des certificats uniquement comme un moyen de faire de l'argent pour les compagnies privilégiées. Il n'est pas; c'est fondamental pour la conception des objectifs du protocole SSL. Bien sûr, ce que vous êtes après, peut très bien ne pas être tous ces objectifs de conception, et c'est très bien, mais vous ne devriez probablement pas tout que comme "sécurisé", parce qu'il est vulnérable à une assez commune type d'attaque, et je suis juste une question, il peut être déformé pour les autres lecteurs, comme une solution complète.

    InformationsquelleAutor timdev
  7. 0

    En stockant les mots de passe cryptés la méthode sur le serveur, le serveur peut récupérer les mots de passe et de vérifier la somme de contrôle envoyés par le client. Envoyer un mot de passe de session et de demander au client de faire un hash de mot de passe de session et l'utilisateur saisi un mot de passe, faites la même chose sur le serveur et de comparer les deux tables de hachage.

    Ce ne sera pas sécurisé, les utilisateurs d'attaques de type MITM - les administrateurs locaux, la NSA, telecom, routeur détourne, mais elle permet de conserver le mot de passe coffre-fort ouvert wlan.

    InformationsquelleAutor Antti Rytsölä