Est-il sûr d'envoyer des noms d'utilisateur / mots de passe clairs sur une connexion https pour authentifier les utilisateurs?

@AJHenderson +1, demander au client d'envoyer le hachage serait certainement mauvais, car le but du protocole d'authentification est de s'assurer que le visiteur connaît le bon * mot de passe *, et non le bon mot de passe * hash *. Si une partie malveillante pouvait obtenir le hachage (base de données de mots de passe volés, homme au milieu, peu importe) et que le système comptait sur le visiteur envoyant le hachage au lieu du mot de passe, toute notion de sécurité réelle serait exclue.

Il est parfois avantageux de hacher au niveau du client, puis de hacher un peu plus sur le serveur. Cela peut aider à garantir que le mot de passe est masqué dans tous les journaux en texte clair au niveau du client, du serveur et du réseau.

@Craig Laisser le client calculer le hachage salé coûteux est parfaitement bien, tant que vous appliquez un hachage non salé bon marché sur le serveur avant de le stocker (ou un autre type de fonction à sens unique, comme l'exponentiation modulaire).

@AndyBoura - si vous concevez le système de telle sorte que vous puissiez prendre en charge le hachage côté client, vous contrôlez le comportement du réseau et du serveur pour les parties qui auraient accès au texte clair. Certes, vous n'êtes pas blessé par le hachage sur le client (autre que le temps perdu), à condition que cela n'affecte pas de manière significative la quantité de hachage que vous faites sur le serveur.

@CodesInChaos - Je dirais seulement que c'est un peu moins mauvais. Même en utilisant un hachage complexe pour faire une entrée «plus longue», ce n'est qu'une extension de clé et un attaquant va être capable de produire très facilement beaucoup de hachages bon marché. En pratique, peu importe si la sortie de hachage côté client est longue et qu'aucune vulnérabilité dans l'un ou l'autre des hachages ne limite l'expansion à partir de valeurs simples. Il est également important de noter que dans un tel cas, vous devrez saler à la fois les hachages côté client et côté serveur. Je suis encore un peu dubitatif quant au coût par rapport aux avantages.

@AJHenderson Le hachage côté client présente plusieurs avantages: 1) Limite de temps plus longue car le client n'a pas besoin de gérer plusieurs connexions en même temps. 2) Evite DoS car le serveur n'a pas besoin de calculer un hachage coûteux. 3) Le serveur n'apprend pas le mot de passe. | Le principal inconvénient est que les clients ont souvent un processeur plus lent que le serveur. | Je ne vois pas pourquoi le hachage côté serveur devrait utiliser un sel alors que le hachage côté client en utilise déjà un.

@CodesInChaos - Parce que rien du côté client n'est fiable. Un attaquant peut ignorer l'intégralité du processus lent en contournant entièrement le client. Vous devez vous assurer que vous ne pouvez pas créer une table arc-en-ciel de valeurs de hachage rapides et bon marché. Ce n'est pas faisable si vous salez chacun d'eux et à condition que le hachage intermédiaire soit suffisamment long. Sinon, vous créez simplement une table arc-en-ciel de valeurs de hachage qui peuvent être générées à une vitesse très, TRÈS rapide si elles sont bon marché.

@AJHenderson De toute évidence, la valeur intermédiaire doit être suffisamment grande pour éviter l'énumération, au moins 128 bits de préférence 160-256 pour tenir compte des attaques multi-cibles. Puisque l'utilisation d'un hachage approprié comme SHA-256 est si facile, je ne vois aucune raison d'ajouter des complications inutiles comme un sel.

@CodesInChaos - oui, si vous utilisez un hachage intermédiaire suffisamment grand et que vous êtes sûr qu'il se comporte bien (distribution vraiment aléatoire), cela devrait être correct tant que le hachage initial est salé et prend suffisamment de temps pour forcer l'utilisation d'une énumération complète du espace de hachage intermédiaire (ou au moins presque plein.)

Au risque de déclarer l'évidence, assurez-vous que vous transmettez via POST, et non via GET :-) Les GET seront en clair.

De plus, pendant que nous parlons de problèmes tels que POST vs GET, assurez-vous de mettre en œuvre la confidentialité de transfert afin que vos sessions sécurisées ne puissent pas être déchiffrées plus tard par quelqu'un qui obtient la clé privée de votre serveur.

Conversation mot de passe / hachage [suite dans le chat] (http://chat.stackexchange.com/rooms/16227/discussion-between-aj-henderson-and-craig).

Surtout avec une application côté client, j'utiliserais probablement encore une version hachée du mot de passe sur la ligne, car je pense qu'il est possible que, pour une raison quelconque, une connexion non chiffrée puisse être créée (par une erreur de programmation, une mise à jour d'application défectueuse , mauvais paramètres de la bibliothèque sous-jacente, donc une redirection vers un serveur http est acceptée ...) * Tout cela pour le cas du même mot de passe pour plusieurs comptes, en outre, vous êtes à l'abri d'une personne ayant accès à votre serveur pour obtenir des mots de passe en clair ...

@Falco - et une erreur de programmation pourrait également rendre le hachage non sécurisé. Vous devez valider le comportement du code lié à la sécurité, pas seulement espérer qu'il fonctionne correctement. Plus vous ajoutez de complexité à un système, plus il est difficile à valider et plus une erreur ou une vulnérabilité est susceptible d'apparaître. Vous devez juger du bénéfice que vous obtenez pour un effort supplémentaire donné. Finalement, le risque supplémentaire d'erreur dans la mise en œuvre ne vaut pas le gain minimal de résistance supplémentaire.

@AJHenderson: Vous dites "Oui, c'est la pratique courante." Avez-vous une référence pour faire cette déclaration? Je recherche les meilleures pratiques d'une source d'autorité bien connue, comme peut-être le NIST ou même un livre O'Reilly.

Cette «pratique standard» assure-t-elle également une sécurité complète si nous avons «goto fail» ou «HTTPS freak» dans le cadre de notre communication? Et si deux versions SSL sont cassées, sommes-nous sûrs que la version récente est sûre?

@h22 Je suppose que nous ne pouvons pas être sûrs à 100%, mais si ce n'est pas le cas, les mots de passe sont la moindre de nos préoccupations. En outre, nous sommes beaucoup plus sûrs de TLS que de certaines configurations de hachage ou de chiffrement côté client. Si vous dites que cela relève de la pratique «ne roulez pas vous-même».

«Le cryptage local» ne sonne pas vraiment bien mais il existe également des bibliothèques de cryptographie standard.

@h22, le cryptage maison ne s'applique pas seulement aux algorithmes ou bibliothèques, mais aussi aux protocoles. Un échange de mot de passe peut échouer de nombreuses manières. Par exemple, si vous faisiez un chiffrement côté client sans qu'un défi différent soit envoyé au client à chaque fois, le chiffrement ne ferait rien du tout car il ne ferait qu'obscurcir les moyens de générer un mot de passe qui ne serait protégé que par ssl (puisque le la valeur générée par le client serait toujours la même, ce qui en fait le "vrai" mot de passe) Il existe toutes sortes de pièges potentiels, à la fois évidents et non évidents.

Le fait demeure qu'il y a beaucoup plus de tests et d'analyses de protocoles comme ssl que tout ce que vous composez comme votre propre suite. Si vos propres trucs sont superposés à d'autres trucs, cela peut produire des attaques de canaux secondaires. Le fait qu'il ait fallu si longtemps pour que les problèmes soient découverts dans SSL devrait être un générateur de confiance. Cela signifie que même avec une tonne d'yeux, les vulnérabilités sont difficiles à trouver. De plus, cela signifie que des problèmes sont trouvés et annoncés par des chercheurs qui se penchent sur ce genre de choses.

Est-ce toujours une bonne réponse?Je ne m'attendrais pas;certains endroits installent des certificats supplémentaires et effectuent des attaques HTTPS MitM, par exemple.J'ai vu ailleurs des discussions sur ce qui devrait être un meilleur système, mais pas assez pour que je puisse juger si c'était par des gens qui comprenaient réellement la sécurité.

@DanielH si quelqu'un a accès pour installer les certificats racine, ils ont accès au journal des clés.Si vous ne faites pas confiance à un ordinateur, n'entrez pas votre mot de passe, point final.La protection contre les clients compromis nécessite un mécanisme entièrement différent, tel que des cartes à puce qui peuvent s'authentifier sans révéler le secret, mais qui nécessite du matériel supplémentaire pour le client et n'est pas pratique pour la plupart des applications.

@AJHenderson Il existe des moyens d'amener un client à avoir un certificat compromis qui ne vous permet pas d'installer un keylogger, mais je retire cette partie de mon objection de toute façon car ils vous laisseraient également changer l'écran de connexion et peu de clients vérifierontque chaque fois pour des changements.Cela ne protégerait que contre les compromis de serveur partiels mais non totaux (qui peuvent ou non être plausibles selon l'architecture et les pratiques de sécurité de l'entreprise) ou les attaques qui ont permis l'écoute passive mais pas d'interférence active avec HTTPS (peut probablement exister, mais très rare).

@AJHenderson Bien que la plupart de ce qui m'a convaincu, c'est que plusieurs entreprises en qui j'ai confiance pour avoir une sécurité supérieure à la moyenne semblent toutes envoyer le mot de passe entré d'une manière non cryptée au-delà du HTTPS.Je suis surpris;Je me serais attendu à ce qu’une méthode qui ne fasse pas cela devienne la norme pour l’amélioration peut-être minime qu’elle offre, d’autant plus que la lutte contre la réutilisation des mots de passe est une bataille perdue.

@DanielH comment installeriez-vous un certificat racine de confiance sans avoir accès administrateur à la boîte pendant au moins une courte période?Si vous avez ce niveau d'accès, vous pourriez également être néfaste de plusieurs autres manières si vous le vouliez.Et comme vous l'avez souligné à juste titre, le simple fait d'avoir la capacité MitM signifie que tout mécanisme côté client pourrait être vaincu à moins qu'il ne soit intégré à une application plutôt qu'à un site Web.

@AJHenderson Vous pouvez compromettre un certificat, soit sans être remarqué, soit en effectuant l'attaque avant sa révocation.Vous pouvez cibler les clients qui ont encore le certificat [Superfish] (https://en.wikipedia.org/wiki/Superfish), ou un équivalent de l'un des multiples autres utilitaires qui font quelque chose de similaire.Vous pouvez vendre un boîtier de médiation ou un middleware de filtrage de contenu qui aurait une raison valable pour MitMing, puis soit ne pas protéger le certificat, soit l'utiliser à des fins néfastes.Vous pouvez inciter une autorité de certification à vous délivrer un certificat pour un site que vous ne contrôlez que partiellement.Etc.

@DanielH ok, c'est un contexte complètement différent de votre commentaire initial parlant des endroits qui installent des certificats pour le proxy MitM.Les cas que vous venez de décrire sont beaucoup moins courants et la plupart ont des mesures d'atténuation en place maintenant ou sont des cas très rares ou ne s'appliquent qu'aux systèmes qui sont autrement vulnérables aux attaques contre le client lui-même.

Laissez-nous [continuer cette discussion dans le chat] (https://chat.stackexchange.com/rooms/90709/discussion-between-daniel-h-and-aj-henderson).