Quelle est la meilleure façon d’envoyer des données d’authentification de formulaire Web via HTTP ?

Question

Une entreprise que je connais est en discussion pour renforcer sa politique de sécurité des mots de passe sur tous ses produits d'applications Web.

À l'heure actuelle, ils envoient une authentification par nom d'utilisateur/mot de passe dans des formulaires POST via HTTP et reçoivent donc du texte brut.

La solution la plus simple au problème consiste simplement à exiger HTTPS pour la connexion à toutes nos applications, n'est-ce pas ?

Eh bien, il y a une discussion interne sur la possibilité de procéder à une sorte de cryptage des mots de passe côté client (mot de passe + sel, etc.).

Existe-t-il une solution acceptée uniquement HTTP ?

Les avis sont comme...eh bien, tout le monde a une opinion, je recherche donc des documents de sécurité crédibles pouvant étayer votre recommandation.Ne vous contentez pas de chercher sur Google et de m'envoyer vers un article de blog...Je l'ai déjà fait et plus encore.

J'ai trouvé les recommandations de l'OWASP :http://www.owasp.org/index.php/Top_10_2007-A7#Protection

Ainsi que ceux de Microsoft :http://msdn.microsoft.com/en-us/library/aa302420.aspx

MODIFIER: Donner votre recommandation pour l’utilisation de SSL ne suffit pas.J'ai besoin d'une sorte de documentation à l'appui.JE SAIS que déployer notre propre cryptage côté client est mauvais.Je dois être capable de vendre cela de manière crédible aux collègues et à la direction.

HTTP Digest a également été mentionné.Cela semble bien, mais Digest est UNIQUEMENT destiné à l'authentification HTTP, et non aux données envoyées via POST.

Answer 1

1 réponse de Mehrdad. Aller de l'avant avec la cryptographie développée à domicile est risqué.

En parlant d'expérience ici, après avoir vu les vulnérabilités dans les solutions de cryptage côté client cultivés sur place. La plupart des vulnérabilités sont dues à la même raison - le transfert de données a été protégé par le chiffrement avec une clé secrète, mais la clé elle-même a été échangé de manière non sécurisée

.

TLS / SSL permet de résoudre le problème de non seulement sécuriser l'échange de clés, mais aussi de transfert de données sécurisé.

TLS / SSL protège vos informations sensibles en utilisant la cryptographie à clé Asymétrique pour échanger la clé symétrique utilisée pour chiffrer les informations et-vient, une fois la session TLS / SSL a été mis en place. La clé symétrique est générée lors de l'exécution, et est un secret partagé entre le client et le serveur; il est cette clé qui est utilisée pour chiffrer tout autre trafic une fois la session est prêt pour le transfert de données.

clés publiques et privées du serveur ne sont utilisés que pour échanger ce secret partagé. La seule façon connue de compromettre la clé partagée est de compromission de la clé privée du serveur (de sorte que la clé secrète peut être déchiffré). En réalité, il faut une négligence ou de malveillance de la part de l'administrateur du serveur.

.

Si vous lancez votre propre solution de chiffrement, vous devez échanger la clé symétrique, de manière sécurisée La meilleure façon de le faire est d'utiliser TLS / SSL; la façon plus difficile est de mettre en œuvre votre propre solution de cryptographie d'échange de clés Asymétrique.

Answer 2

très recommande contre aller avec votre propre solution (dans des environnements sensibles de sécurité). Allez avec SSL. Il est une technologie éprouvée et il est facile à mettre en œuvre.

ROLLING vos propres solutions de sécurité peuvent être très dangereux et même si elle est mise en œuvre correctement (0,000001% de chances), il être coûteux.

Answer 3

Si les données elles-mêmes ne sont pas trop sensibles, mais que les mots de passe le sont, je suggère d'utiliser Authentification HTTP Digest (ce qui est une bête assez différente de l'authentification de base HTTP).C'est assez sécurisé via HTTP direct, et pas du tout difficile à mettre en œuvre sur le serveur.Rien n'est envoyé par fil qui pourrait révéler le mot de passe, juste des informations qui permettent au client de démontrer au serveur qu'il dispose du mot de passe correct.

Si vous souhaitez une explication décente sur la façon d'implémenter l'authentification HTTP Digest dans votre application, Paul James a un excellent article à ce sujet.

Le seul vrai problème avec l’authentification HTTP réside dans les navigateurs eux-mêmes :l'interface utilisateur est horrible, mais cela peut être surmonté avec du Javascript.

Vous pouvez stocker les mots de passe en toute sécurité en stockant le hachage A1.

MISE À JOUR: Comme mentionné dans d'autres réponses, même si le serveur peut éviter les attaques MITM en n'acceptant pas l'authentification de base, le client est toujours vulnérable car il le fera.

MISE À JOUR: Vous ne pouvez pas sécuriser les données via POST à ​​moins que vous (a) effectuiez un cryptage en JavaScript sur le client ou (b) que vous fassiez tout via SSL.

Toi peut, avec un peu de magie, utilisez l'authentification HTTP avec les formulaires.L'article auquel j'ai lié ci-dessus s'appelle « Authentification HTTP avec formulaires HTML », après tout.Mais cela ne se fera pas via POST.

Si tu vraiment besoin, utilisez POST, utilisez SSL et salez les mots de passe dans votre base de données.

Si vous voulez éviter CSRF, je vous recommande d'utiliser clés de formulaire, bien que l'idée porte de nombreux noms différents, j'ai choisi ce nom en piratant Slashcode pour mon propre usage il y a quelques années, et c'est là que je l'ai découvert pour la première fois.

Answer 4

Vous passerez plus de temps et d'argent rouler votre propre solution et ne pas être assuré qu'il est sécurisé. Industrie standard SSL est facile à mettre en œuvre et beaucoup plus sûr de la boîte que vous pouvez vous permettre de faire votre propre solution.

temps == argent

Acheter un certificat et passer votre temps de travail sur votre application au lieu d'un formulaire de connexion sécurisé.

Answer 5

le cryptage côté client est sans défense contre la plupart des attaques MITM. Attacker peut simplement supprimer votre script.

Il ne protège contre le sniffing passif. Si cela est assez bon pour vous, vous pouvez utiliser:

• Hashage mis en œuvre avec Javascript. Il est facile à mettre en œuvre défi-réponse pour la première connexion, mais ne pas oublier que pour les cookies de la session de l'attaquant est presque aussi bon que le mot de passe (il vous faudrait limiter la connexion IP unique et / ou utiliser script pour générer cookies unique pour chaque demande, que j'imagine serait la solution difficile et fragile).
• HTTP d'authentification Digest. Plus sûr, car il peut utiliser un hash, l'authentification mutuelle, etc., mais l'interface utilisateur classique est absolument répugnant.

... il suffit d'utiliser SSL.

Answer 6

HTTP que des solutions seront toujours sensibles aux attaques man-in-the-middle.

EDIT:. Une trace réseau serait un moyen facile de prouver que HTTP est pas sécurisé

Answer 7

D'accord, voici la seule réponse dont vous avez besoin: Votre banque ne supporte que login / auth via SSL. S'il y avait une meilleure façon de le faire, ils le feraient.

Answer 8

  

Eh bien, il y a une discussion interne   à faire à la place une sorte de   roll-notre-propre cryptage côté client   les mots de passe (mot de passe + sel, etc.).

La première chose que nous devons traiter est données en transit par rapport aux données au repos. De l'OP, il semble que la grande préoccupation est le nom d'utilisateur / mot de passe en clair sur Internet. Alors, vous vous inquiétez vraiment les données en transit. HTTPS via SSL est une méthode éprouvée de le faire (et il est assez facile une solution!). Maintenant, si vous voulez vraiment rouler votre propre pour les données au repos (dans un db, sur un serveur de fichiers, etc.), qui est une bête différente, mais les méthodes existantes pour le cryptage des données vont être mieux qu'un rouleau votre .

En se fondant sur le côté client pour votre sécurité est mauvaise. Période. Dans un environnement d'entreprise, oui, vous pouvez compter un peu sur une configuration standard. Mais, en fin de compte, les utilisateurs sont muets et vous pouvez rencontrer quelqu'un désactiver javascript ou quelle que soit la solution basée sur le client vous roulez, de sorte qu'ils finissent par envoyer le nom d'utilisateur / mot de passe en texte clair de toute façon (même si vos serveurs DonT » savent quoi faire avec elle parce que ce n'est pas dans le format attendu.

roulées propre ne va pas être soumis à l'examen qu'une solution existante a. Vous pourriez finir par ajouter des problèmes de sécurité supplémentaires dans le mélange à cause du code.

Answer 9

Nous venons de mettre un web / application mobile pour faire un peu de ce genre de choses. Il crée des URL aléatoires pour les connexions, en utilisant le protocole HTTPS et une méthode de cryptage hachage / AES pour le stockage de base de données. Theres une API simple JSON à l'utiliser sans notre interface utilisateur, Heres notre writeup, lui donner un look .. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it

Answer 10

vous avez mentionné faire votre propre cryptage ainsi que le sel ... Je suggère d'utiliser javascript md5 (il est également utilisé par Yahoo sur leurs pages non ssl, ou ce qu'il prétend) ...

Et vous double hachage du mot de passe ... Certains diront que le double hachant rendrait vulnérable aux attaques de collision. Je suis pas d'accord parce que les gens ont été en mesure de le faire jusqu'à ce que les collisions de signature md5 maintenant uniquement sur les fichiers, où grande quantité de données est md5'ed ...

Si c'est un grand site Web d'entreprise (et il y aurait des raisons de briser en) il n'y a aucune excuse pour ne pas utiliser SSL.