Comment sécuriser l'envoi de données sensibles https?

SSL est sécurisé, mais rappelez-vous que tout cryptage peut être brisé si on lui donne suffisamment de temps et de ressources. Étant donné que vous ne savez pas quels paquets contiennent un mot de passe et lesquels ne le font pas, vous devrez déchiffrer tout le trafic crypté pour trouver le bon. C'est intraitable dans le cas général.

Cependant, un formulaire de connexion aura besoin d'une entrée[type = text] pour l'entrer. Il faudrait du travail pour "décompresser" ceci et transformer la requête en une requête HTTP GET en utilisant des chaînes de requête plutôt qu'un POST avec le données dans les paramètres de formulaire. Je ne peux pas imaginer pourquoi quelqu'un ferait cela. Une fois le mot de passe fourni par l'utilisateur (et l'utilisateur authentifié), utiliser le fait d'authentification plutôt que de garder le mot de passe autour. Si vous avez besoin de garder le mot de passe, pour l'usurpation d'identité, disons, gardez-le côté serveur et de préférence dans une chaîne sécurisée. Si vous essayez de faire une connexion unique (entrez mon id/mot de passe une fois pour de nombreux sites), utilisez une sorte de service D'authentification central (CAS) - OpenID, WindowsLive - ou mettre en place votre propre.

Moins un mot de passe traverse le fil, mieux c'est.

Et, il y a toujours la barre d'emplacement du navigateur à considérer qui soutiendrait que vous devez crypter et encoder toutes les données sensibles que vous mettez dans les chaînes de requête comme mentionné précédemment.

Les données sensibles dans la chaîne de requête sont une mauvaise idée, les passants occasionnels peuvent voir la chaîne de requête et il y aurait une tentation de signet qui n'est vraiment pas sécurisé.

SSL est assez sécurisé, si vous faites des services bancaires par internet et que vous lui faites confiance, alors SSL sera assez bon pour vous aussi.

D'accord avec le SSL est sécurisé * ish et le problème querystring

Rappelez-vous QU'il existe des limitations sur SSL -

Assurez - vous que le certificat est certifié root.

Certaines machines windows 2000 doivent avoir un sp appliqué pour que le ssl 128 bits fonctionne, si ce n'est pas là, alors il va à la charge 40bit ou doenst (si je me souviens bien)

Certains pare-feu logiciels comme ISA-où vous publiez le site sécurisé et le cert à l'intérieur - agissent comme un homme au milieu.

Sécurisé à ISA puis sécurisé à LAN. mais le grand facteur ici est le "alors" comme ISA se connectera alors la journalisation est un problème car le mot de passe sur la chaîne de requête et post peut être vu - ce qui signifie que n'importe qui (admin) peut voir...

Recherchez donc des algorithmes de hachage sécurisés dans votre langue pour simplement hacher le mot de passe.

Il n'y a pas de "secure enough", la sécurité n'est pas une chose statique avec une propriété bool qui est false ou true.

SSL est bon, mais cela dépend de la sécurité de la clé privée côté serveur, de la quantité de bits de la clé, de l'algorithme utilisé, de la fiabilité des certificats utilisés, etc....

Mais si vous utilisez SSL au moins toutes vos données transmises sont cryptées (sauf l'adresse IP cible car elle est utilisée pour acheminer votre paquet).

Un autre point que vous devriez considérer is-Si vous entrez votre chaîne de requête de mot de passe à la main dans votre navigateur, il peut se retrouver dans le cache de votre navigateur local (dans un fichier local complètement non crypté). Donc, mieux utiliser POST et ne pas obtenir la mécanique de transfert.

Si vous êtes vraiment intéressé par la sécurité, je recommande plus de recherches sur ce sujet, car le plus souvent, l'algorithme n'est pas le point le plus faible de la sécurité.

Oui, c'est assez sécurisé. Bien que je convienne que ce n'est généralement pas une bonne idée d'avoir des choses comme celle dans une chaîne de requête, c'est ok si ce n'est pas une chaîne de requête qui s'affichera dans la barre d'adresse. S'il apparaît dans la barre d'adresse, vous perdez pour des raisons évidentes un niveau de sécurité (personnes qui passent, etc)

L'inspecteur Ssl peut ouvrir les trafics ssl http://www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf

Vous ne devriez jamais envoyer quoi que ce soit de critique sensible en utilisant des chaînes de requête!

Ne devrait-on pas envoyer des mots de passe hachés ? - tant pis si je me trompe.

SSL est à peu près le plus de sécurité que vous pouvez obtenir.

Les certificats auto-signés sont des certificats SSL créés et signés par vous-même. Cela signifie que vous n'avez pas besoin d'une autorité de certification (CA) tierce pour signer votre certificat, mais cela signifie que les navigateurs vont, par défaut, lancer un avertissement à ce sujet, car un certificat auto-signé ne peut pas vérifier de manière fiable (votre navigateur a une liste D'Autorités de certification de confiance) que le signataire

Considérez la situation où vous créez un Certificat SSL "au nom de" une certaine société de logiciels basée à Redmond. Maintenant, si votre serveur HTTP présente ce certificat, que vous avez auto-signé, à un client, l'agent utilisateur avertira que ce certificat peut ne pas être réellement dont il dit qu'il est. Une autorité de certification vérifiera - par la paperasserie, le vrai type d'arbre mort réel - l'identité de la partie demandant la signature, par conséquent, il est fiable.

J'espère que cela aide.