J'essaie de créer un formulaire de connexion de nom d'utilisateur / mot de passe normal », sans avoir besoin de HTTPS. Mon idée est la suivante:
Ce que j'ai besoin de savoir pour cela est:
7 Réponses :
On dirait que beaucoup de ce que vous voulez faire est fourni par le plug-in jquery JACRPTION . Il assume même PHP comme le backend, alors un bon ajustement pour vous.
Jycyption est génial si vous voulez un théâtre de sécurité: SecurityFocus.com/archive/1/520683 Si vous souhaitez que la sécurité réelle, essayez Phpseclib, une véritable mise en œuvre PHP RSA (conformément aux recommandations de la divulgation de SecurityFocus.com)
jcryption semble intéressant, je ne l'ai pas vu auparavant.
Mais je dois demander ce qui ne va pas avec SSL?
Le code de cryptage est notoirement difficile à faire, et vous pouvez parier que les implémentations SSL trouvées dans les navigateurs et les serveurs HTTP sont beaucoup plus rigoureusement testées et examinées que les trucs jcryption.
Cela dit, JCRYPTION semble soignée si vous avez absolument besoin d'éviter SSL et que vous ne traitez pas d'informations super sensibles.
Oh oui, SSL est génial, à l'exception d'une décision de conception idiote, vous avez besoin d'un certificat et que cela coûte de l'argent. S'ils l'avaient fait pour que vous puissiez avoir du cryptage sans la partie validation de l'identité, le cryptage aurait été utilisé plus souvent que non, et le net aurait été plus en sécurité.
La validation de l'identité est nécessaire pour que le certificat puisse être signé. Si ce n'est pas signé, les clients n'ont aucun moyen de savoir si elles sont présentées avec un certificat faux. L'argument selon lequel il "coûte de l'argent" est assez boiteux, étant donné que de nombreux fournisseurs d'hébergement regroupent souvent un certificat de SSL parfaitement bon ou le fourniront à des frais supplémentaires. Si vous êtes sérieux au sujet de votre fonctionnement dans un environnement où vous êtes censé adhérer à certaines normes de sécurité, vous devrez accepter des coûts.
Vous pouvez toujours générer votre propre certificat SSL auto-signé. Bien sûr, les navigateurs ont commencé à rendre cela encore plus effrayant pour les utilisateurs qu'ils ne l'étaient. Mais j'ai tendance à convenir que l'argument des coûts est faux. Temps de programmateur pour mettre en œuvre votre moyen de payer pour un certificat SSL coûte de l'argent.
Voir mon commentaire à la réponse de Rob. De plus, si SSL n'avait pas besoin de certificats signés, il serait probablement standard. Les sites sécurisés n'auraient plus de numérités non sécurisées de loin et même le plus petit site de loisirs serait sécurisé, la fourniture des défauts de serveurs Websser / Hôte est défini comme celui-ci.
Pour clarifier les commentaires de Rob: la partie de cryptage est inutile sans la partie validation de l'identité. Une solution telle que l'affiche décrit est trivialement vaincue par tout attaquant qui a la capacité d'obtenir entre le client et le serveur. C'est ce qu'on appelle un "homme au milieu" attaque et l'idée est très simple: le serveur génère une paire de clé, envoie une clé publique. L'attaquant intercepte la page, remplace la clé publique avec le sien. Le client crypte le mot de passe avec la clé publique de l'attaquant et envoie la réponse. L'attaquant décrypte le mot de passe, le crypte avec la clé publique de Server et l'envoie au serveur.
Swillden est parfaitement correct. Si des informations méritent d'être protégées, cela mérite de bien vous protéger. Le cryptage "Iron-Clad" qui peut être vaincu par l'homme au milieu crée juste un faux sentiment de sécurité dangereux.
Je n'essaye que d'arrêter les kiddies de script. Il ne vaut tout simplement pas la peine d'aller jusqu'au bout, et c'est au moins mieux que rien. Vous ne pouvez vraiment pas être en désaccord avec une telle logique simple;)
Essayer de les arrêter de quoi, exactement?
Le nombre de personnes qui sont à la fois intelligentes et motivées suffisamment motivées pour intercepter vos communications, mais pas Smart et motivé suffisamment pour casser votre schéma cassable de manière triviale, vous devez sûrement être trop petit.
Vous pouvez toujours être en désaccord avec une logique imparfaite. Vous semblez travailler selon l'opinion que SSL incorpore des certificats uniquement comme moyen de gagner de l'argent pour des entreprises privilégiées. Ce n'est pas; C'est fondamental pour les objectifs de conception de SSL. Bien sûr, qu'est-ce que vous êtes après que vous ne puissiez pas être tous ces objectifs de conception, et cela va bien, mais vous ne devriez probablement pas tout être «sécurisé», car il est vulnérable à un type d'attaque assez commun, et je suis juste Concéré, il peut être interprété mal à d'autres lecteurs en tant que solution complète.
Cela ne semble pas être sûr du point de vue du client. Deux problèmes (liés):
Quel est le problème avec le SSL ordinaire? Il doit y avoir un consensus qu'il est sécurisé, sinon les fournisseurs et les organisations le supprimeraient pendant la nuit. En revanche, la plupart des tentatives d'inventer une nouvelle façon funky de faire de la sécurité "sur le bon marché" manquent généralement quelque chose de fondamental.
Il n'y a aucun moyen de vérifier l'identité du serveur, c'est vrai. Mais ça compte? Un vrai certificat SSL ne va tout simplement pas arriver, et c'est mieux que rien ... bien mieux. SSL est comme si vous ne pouvez pas ne pas verrouiller votre porte ou un scanner d'empreintes digitales. La serrure régulière avec une clé en métal n'est pas disponible.
Je soutiendrais que c'est pire que rien, car il vous donne un sentiment de sécurité complètement faux. Un vrai certificat SSL peut être utilisé pour 30 $ - vos données valent-elles vraiment moins de 30 $?
À l'avance: Je suis désolé d'être négatif, cependant;
La mise en œuvre de votre propre protocole de sécurité est SSL n'est définitivement pas une serrure d'empreintes digitales, comme indiqué dans vos commentaires, jcryption et votre proposition sont égales à avoir une porte dans laquelle vous pouvez entrer un code à deux chiffres pour ouvrir la porte et vous avez d'infinité de nombreuses tentatives. Il est difficile de casser si vous n'êtes pas vraiment intéressé et simplement en passant, mais si vous voulez entrer dans cette maison (et que vous le faites probablement, sinon la sécurité ne serait pas nécessaire), vous allez entrer.
Un autre point est que les gens oublient souvent de mentionner ce qu'ils veulent atteindre. La sécurité a les trois composants célèbres appelés CIA, nommément confidentialité, intégrité et disponibilité. Est-ce que vous êtes important que les données que vous transportez soient confidentielles ou que l'intégrité est importante (c'est-à-dire que vous êtes sûr que les données envoyées proviennent de celle que vous attendez et non de l'homme au milieu)?
Pour le faire concrets dans ce cas, la seule chose que vous réalisez ici est qu'un attaquant passif ne peut pas voir ce qui est en train de passer sur la ligne. Dès que votre attaquant est actif et change les messages sur leur itinéraire, toute sécurité tombe en morceaux. Donc, mes conseils seraient simplement à coller avec la solution que les experts ont été proposés (TLS dans ce cas, pas SSL, car c'est la version ancienne de celle-ci) et assurez-vous simplement que votre serveur le supporte.
BTW, SSL / TLS ne peut pas fonctionner sans certificats. L'ensemble de la crypto de la clé publique est qu'il devrait y avoir au moins quelque part une partie de confiance.
D'autre part, si vous ne vous souciez pas que vos utilisateurs obtiennent un message "certificat invalide", vous pouvez simplement créer votre propre certificat qui est vraiment facile. Dans ce cas, votre certificat ne fonctionne pas par les navigateurs, cependant, vous pouvez être sûr que au moins votre communication est sûre (d'accord, il y a des exceptions dans ce cas, mais toujours ...)
L'argument selon lequel les certificats devraient être gratuits est vraiment d'un point de vue en perspective. Je pense que les gens qui prétendent que c'est faux / idiot ne savent pas ce qu'il faut pour être une autorité de certification. Ces sociétés investissent des millions afin de maintenir la communication sécurisée et de faire de l'argent agréable à la vente de certificats de vente, mais bon leur travail et qu'ils méritent également de gagner de l'argent, tout comme d'autres.
Je dis en effet que vous avez une communication sécurisée. Cependant, vous manquez le point que, avec des certificats auto-signés, vous ne savez pas à qui vous parlez de manière sécurisée. Imaginez une pièce sombre qui est complètement isolée d'écouter une conversation. Maintenant, imaginez la différence entre une telle pièce avec et sans lumière. Si la chambre a la lumière, vous pouvez réellement voir à qui vous parlez de manière sécurisée et que choisissez parler aux personnes que vous aimez faire confiance. Maintenant, imaginez la même chose dans une pièce complètement sombre. Vous ne pouvez espérer que le gars que vous parlez à l'intérieur de cette pièce sombre est juste un allié et non votre adversaire. Cependant, vous ne pouvez pas savoir que, juste espoir que ça va. Et bien que votre conversation elle-même soit sécurisée, personne ne peut écouter, vous n'avez toujours pas de sécurité "complète".
Si je, étant un escroc, faites une attaque homme-intermédiaire, je peux créer un certificat auto-signé sans l'utilisateur en notant. L'avantage d'utiliser des TLS avec des certificats auto-signés est que vous avez au moins la mise en œuvre du correct du protocole (et même la mise en œuvre de cela est loin d'être facile). De plus, vous pouvez éviter les avertissements laids en conseillant vos utilisateurs de faire confiance manuellement au certificat une fois. Cependant, cela n'est possible que si vous avez un groupe relativement petit de visiteurs de retour, pour un site Web public, ce n'est pas vraiment une solution.
Vous avez très raison quand il concerne des choses très sensibles, comme la banque. Je suis cependant en effet essayant d'arrêter les enfants de script ici.
De plus, puisque vous semblez proposer des certificats auto-signés, pourquoi il ne devrait-il pas y avoir de système dans lequel cela est possible sans avertissements laids. Après tout, c'est comme vous le dites: alors "Vous pouvez être sûr que au moins votre communication est sûre"
Aussi (désolé pour Triple Commentaire) +1 Depuis que je suis en désaccord, votre message est bien écrit.
Je me félicite du fait que les navigateurs commencent à former une énorme problème sur des certificats auto-signés. Cela signifie que nous pourrions commencer à s'éloigner de ces jours flous lorsque les utilisateurs ont simplement vu un bouton "Accepter" et cliqués dessus, les avertissements sont damnés. Au moins si quelqu'un voit une grosse page rouge, panique et annule le processus, c'est une sécurité de sécurité.
Je suppose que vous aimeriez entendre que j'ai depuis augmenté plus expérimenté et que vous réalisez maintenant pourquoi le cryptage n'aurait que suffisamment sûr. Nous utilisons maintenant de vrais TLS pour notre formulaire de connexion. Mais, je pense toujours que le cryptage sans certification devrait être disponible et utilisé par défaut (sauf lorsque la performance l'emporte sur la sécurité) pour tous les sites hobbyistes, même si cela est faible, simplement parce que rien n'est mieux que rien.
@Bartvanheukelom Si vous pensez toujours que l'utilisation de l'approche JavaScript est meilleure que rien, et cela vaut ainsi la peine d'être fait, votre réponse acceptée devrait être une qui vous dit comment le faire, ne pensez-vous pas?
LiveJournal fait quelque chose de similaire à ce que vous voulez où:
En stockant les mots de passe de la méthode cryptée sur le serveur, le serveur peut récupérer les mots de passe et vérifier la checksum envoyée par le client. Envoyez un mot de passe de session et demandez au client de faire un cash de mot de passe de session et du mot de passe entré par l'utilisateur, faites de même sur le serveur et comparez les deux hatupes.
Cela ne protégera pas les utilisateurs des attaques MITM - Administrateurs locaux, NSA, Telecom, Routeur Hijacks, mais il conservera le mot de passe en toute sécurité dans Open WLAN.
Utilisez toujours SSL / TLS avec des certificats valides. Si vous avez des raisons autres que la sécurité du réseau pour crypter le login (comme empêchant la prévention du mot de passe côté serveur Débogage / Crash / Normal / etc. La journalisation, qui peut être récupérée ultérieurement par un attaquant) Vous pouvez utiliser ceci: Stackoverflow.com/questions / 12457234 / ...