Cours MIT "Sécurité des systèmes informatiques". Conférence 17: Authentification des utilisateurs, partie 1

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3
Conférence 14: «SSL et HTTPS» Partie 1 / Partie 2 / Partie 3
Conférence 15: «Logiciel médical» Partie 1 / Partie 2 / Partie 3
Conférence 16: «Side Channel Attacks» Partie 1 / Partie 2 / Partie 3
Conférence 17: «Authentification des utilisateurs», partie 1 / partie 2 / partie 3

Commençons donc. Avec le retour de vous, j'espère que les vacances pour tous ont été un succès. Aujourd'hui, nous allons parler de l'authentification des utilisateurs. Ainsi, le sujet de la conférence est de savoir comment les utilisateurs peuvent prouver leur identité au programme? En particulier, l'article, qui est destiné à la leçon d'aujourd'hui, aborde les fondements mêmes de l'existence d'une communauté de sécurité. Y a-t-il quelque chose de mieux pour l'authentification que les mots de passe?



Au plus haut niveau, il semble que les mots de passe soient une idée terrible, car ils ont une entropie très faible et il est facile pour les attaquants de les résoudre. Les questions secrètes que nous utilisons pour récupérer des mots de passe oubliés ont encore moins d'entropie que les mots de passe eux-mêmes, et cela semble également être un problème.

Et pire encore, les utilisateurs utilisent généralement le même mot de passe sur de nombreux sites différents. Cela signifie qu'une vulnérabilité dans un mot de passe facilement deviné met en péril le travail de l'utilisateur sur de nombreux sites.

J'ai aimé la citation suivante d'un article de la conférence d'aujourd'hui: «la domination continue des mots de passe parmi toutes les autres méthodes d'authentification des utilisateurs est un obstacle majeur à la recherche sur la sécurité.» Ainsi, la communauté des chercheurs en sécurité souhaite avoir une alternative meilleure que les mots de passe. Cependant, il n'est pas clair s'il existe vraiment un schéma d'authentification qui peut remplacer complètement les mots de passe, tout en étant plus pratique, plus large et plus sécurisé.

Aujourd'hui, nous examinerons trois questions. Tout d'abord, nous allons voir comment fonctionnent les mots de passe existants. Après cela, nous parlerons des propriétés de mot de passe globales souhaitées pour tout schéma d'authentification. Enfin, nous examinons ce que l'article de conférence sur les métriques ou les fonctionnalités d'authentification examine et comment certains autres schémas d'authentification sont comparés en termes d'efficacité avec les mots de passe.



Qu'est-ce qu'un mot de passe? Le mot de passe est un secret partagé pour l'utilisateur et le serveur. Ainsi, une implémentation primitive d'un schéma de mots de passe devrait simplement avoir une table côté serveur qui mappe les noms d'utilisateur à leurs mots de passe.

C'est le moyen le plus simple d'imaginer la mise en œuvre de l'un des schémas d'authentification - l'utilisateur saisit son nom et son mot de passe, le serveur les recherche dans ce tableau, compare le mot de passe avec le nom, et si tout correspond, l'utilisateur est authentifié. De toute évidence, le problème est que si un attaquant fait irruption dans le serveur, il peut simplement regarder ce tableau et reprendre tous les mots de passe. C'est donc clairement une mauvaise chose.

La solution à ce problème est peut-être de stocker la table sur le serveur, qui ressemble à ceci: le nom d'utilisateur ne correspond pas au mot de passe lui-même, mais à son hachage. Dans ce cas, l'utilisateur saisit le mot de passe en texte brut, le serveur vérifie son code de hachage et le compare avec la valeur du tableau. L'avantage de ce schéma est que ces fonctions de hachage sont conçues de telle manière que le hachage est difficile à convertir en mot de passe. Si cette table est perdue, il y a une fuite de données, ou l'attaquant a piraté le serveur et en a pris possession, il verra alors des chaînes de caractères alphanumériques aléatoires au lieu de mots de passe de texte, et il lui sera difficile de restaurer leur image d'origine.

Au moins en théorie, l'utilisation de hachages est une très bonne chose. Mais maintenant, dans la pratique, les attaquants n'auront plus à utiliser une attaque par force brute pour déterminer l'image inverse de la valeur de hachage.



Les attaquants peuvent vraiment profiter du fait qu'en pratique les mots de passe ont une distribution inégale. Et par la distribution inégale, je veux dire ... disons que nous savons que tous les mots de passe contiennent jusqu'à 20 caractères. Dans la pratique, les utilisateurs n'utilisent pas toute cette plage, préférant les mots de passe tels que 123, todd ou quelque chose de similaire. Cependant, des études empiriques ont montré comment ces mots de passe fonctionnent, et il a été constaté qu'environ 20% des utilisateurs utilisent les 5000 mots de passe les plus populaires. En d'autres termes, cela signifie que si un attaquant possède une base de données de ces 5000 mots de passe, il peut facilement les hacher, puis, lors de la visualisation de la table des mots de passe volés, faire simplement correspondre les hachages. Donc, empiriquement, un pirate pourra récupérer environ 20% des mots de passe qui se trouvent dans la table du serveur.

Les experts de Yahoo ont constaté que les mots de passe contiennent de 10 à 20 bits d'entropie, 10 à 20 bits de caractère aléatoire. En fait, ce n'est pas tellement. Compte tenu de la complexité de la création d'une fonction de hachage, les machines modernes calculent des millions de tels hachages chaque seconde. Ainsi, une fonction de hachage doit être facilement calculable dans la conception afin que les ordinateurs puissent facilement hacher les mots de passe. Cependant, la combinaison de ce fait avec un caractère aléatoire des mots de passe insuffisant signifie que, en principe, ce schéma n'est pas aussi sûr qu'il y paraît.

Il y a une chose avec laquelle vous pouvez essayer de compliquer la vie d'un pirate - c'est une fonction complexe de la formation des clés. Dans ce cas, je veux dire que le hachage de mot de passe est utilisé comme données source, sur la base desquelles le serveur génère une clé qui est stockée sur le serveur.



Ce qui est bien avec ces fonctions de génération de clés, c'est qu'elles ont une complexité personnalisable, c'est-à-dire que vous pouvez tourner un certain bouton et rendre cette fonction plus lente ou plus rapide en fonction de combien vous voulez économiser sur les performances du processus.

Supposons que vous souhaitiez générer une clé. Un exemple est la norme de génération de clés PBKDF2 ou, éventuellement, BCrypt, vous pouvez en savoir plus sur Internet. Imaginons qu'une de ces fonctions de génération de clés ait nécessité une seconde entière, et non quelques millisecondes, à calculer. En fait, cela rendra le travail de l'attaquant beaucoup plus difficile, car la tentative de génération de valeurs pour les 5000 mots de passe «supérieurs» prendra beaucoup plus de temps.

Au niveau interne, ces fonctions de génération de clés fonctionnent souvent en appelant à plusieurs reprises un hachage, en y accédant plusieurs fois, donc tout est assez simple. Mais l'utilisation du long processus de génération de clés résout-elle le problème de sécurité auquel nous sommes confrontés? La réponse est non, car l'un des problèmes est que l'adversaire peut construire quelque chose appelé des tables arc-en-ciel, ou «tables arc-en-ciel». Une table arc-en-ciel est simplement une carte de la façon dont un mot de passe correspond à une valeur de hachage. Ainsi, même si le système utilise l'une de ces fonctions de génération de clés coûteuses, un attaquant peut calculer une de ces tables une fois. Cela peut être un peu compliqué, car le traitement de chaque fonction de génération de clés est assez lent, mais un attaquant peut créer cette table une fois puis l'utiliser pour casser tous les systèmes ultérieurs basés sur les mêmes algorithmes de fonctions de génération de clés. C'est ainsi que fonctionnent ces tables arc-en-ciel.

Je répète encore une fois - afin de maximiser les avantages économiques de la création de la table Rainbow, un attaquant peut profiter de la distribution inégale des mots de passe, dont j'ai parlé plus tôt. Ainsi, un attaquant ne peut construire une telle table que pour un petit ensemble de tous les mots de passe possibles.

Étudiant: probablement «saler», c'est beaucoup plus difficile?

Professeur: oui, oui, exactement. Nous irons au "salage" dans quelques secondes. En général, si vous n'utilisez pas de salage, les tables arc-en-ciel permettent à un attaquant, avec un certain effort en mode hors ligne, de calculer ce tableau, puis de bénéficier de la possibilité de calculer des mots de passe de base en fonction du travail effectué.

La prochaine chose à laquelle vous pourriez penser pour améliorer la situation est le salage. Comment ça marche? Le principe de base consiste à introduire un caractère aléatoire supplémentaire dans la méthode de génération de mot de passe. Vous prenez cette fonction de hachage, y mettez le «sel», puis le mot de passe, et tout cela est stocké dans une table sur le serveur.



Qu'est-ce que le sel? Il s'agit simplement d'une longue chaîne représentant la première partie de cette fonction de hachage. Alors, pourquoi est-il préférable d'utiliser ce schéma? Notez que le «sel» est en fait stocké en texte clair côté serveur. Vous pourriez penser: Eh bien, si ce «sel» est stocké en texte clair du côté serveur et qu'un attaquant peut voler une table de noms d'utilisateurs pour les mots de passe, alors pourquoi ne peut-il pas aussi voler ce «sel»? Quelle est l'utilité d'une telle solution?

Étudiant: parce que si vous choisissez le mot de passe le plus courant, vous ne pouvez pas l'utiliser une seule fois et trouver un nouvel utilisateur.
Professeur: absolument vrai. Fondamentalement, ce que le sel fait est d'empêcher l'attaquant de créer une seule table arc-en-ciel qui pourrait être utilisée contre tous les hachages. En principe, vous pouvez considérer le «sel» comme un moyen de rendre uniques les mêmes mots de passe. En pratique, de nombreux systèmes utilisent le concept de «salage».

En fait, le «sel» permet d'ajouter autant de bits que possible à ce pseudo-mot de passe, car plus il y a de bits, mieux c'est. Il faut également tenir compte du fait que chaque fois que l'utilisateur change son mot de passe, le «sel» doit également être changé. Car l'une des raisons de cette décision est la paresse des utilisateurs qui souhaitent utiliser plusieurs fois le même mot de passe. Changer le «sel» garantira que la chose qui est stockée dans la base de données de mots de passe sera réellement différente même si un mot de passe est remplacé par exactement le même mot de passe.

Public: pourquoi est-il appelé «sel»?

Professeur: C'est une bonne question, et je ne peux pas y répondre avec certitude. Cependant, je suis sûr que cela se justifie. Pourquoi les cookies sont-ils appelés cookies? Internet sait probablement pourquoi, mais je ne sais pas.

Étudiant: peut-être parce que le «sel» ajoute un peu de «goût» au hachage?

Professeur: eh bien, je suis heureux que nous filmions cela parce que nous avons clairement une chance d'obtenir un prix du film. Je suis sûr qu'il existe une sorte de réponse sur Internet, je vais donc la chercher plus tard.
Ainsi, les approches ci-dessus sont assez simples. J'ai supposé que l'utilisateur envoie le mot de passe au serveur, mais je n'ai pas précisé comment cela se produit. Alors, comment passons-nous ces mots de passe?

Tout d'abord, vous pouvez simplement envoyer le mot de passe sur le réseau en texte clair. C'est mauvais car il peut y avoir un intrus sur le réseau qui surveille le trafic que vous envoyez. Il peut simplement attribuer un mot de passe et vous imiter.

Par conséquent, nous commençons toujours par un homme de paille, avant de vous montrer les autres hommes de paille, qui, bien sûr, sont également fatalement défectueux. Donc, la première chose à laquelle vous pourriez penser est d'envoyer le mot de passe en texte clair. Du point de vue de la sécurité, il est préférable d'envoyer un mot de passe via une connexion cryptée, nous utilisons donc la cryptographie. Il est possible que nous ayons une sorte de clé secrète utilisée pour convertir le mot de passe avant de l'envoyer sur le réseau. Donc, au plus haut niveau, il semble que le cryptage fasse toujours mieux, comme une marque garantissant la qualité du produit.

Mais le problème est que si vous ne réfléchissez pas attentivement à la façon d'utiliser le chiffrement et le hachage, vous ne pouvez pas profiter des avantages de sécurité sur lesquels vous comptez. Par exemple, s'il y a quelqu'un qui se trouve entre vous - l'utilisateur et le serveur, cet attaquant notoire, «l'homme au milieu» qui surveille réellement votre trafic, tout en faisant semblant d'être un serveur.

Si vous envoyez des données chiffrées sans authentifier l'autre côté, vous pouvez rencontrer un problème. Parce que le client sélectionne simplement une clé aléatoire et l'envoie à une destination de l'autre côté, qui peut ou non être le serveur.

En fait, vous envoyez quelque chose à une personne qui, après cela, aura l'occasion de prendre possession de tous vos secrets.

Compte tenu de cela, les gens peuvent penser qu'il est préférable d'envoyer non pas le mot de passe lui-même, mais son hachage. En fait, cela seul ne vous donne rien, car que vous envoyiez un mot de passe ou un hachage de mot de passe, ce hachage de mot de passe a la même force sémantique que le mot de passe d'origine, et cela n'aidera pas si vous n'avez pas authentifié le serveur.

Donc, le point principal est que le simple fait d'ajouter du chiffrement ou simplement de hacher ne vous donne pas nécessairement des avantages de sécurité supplémentaires. Si le client ne peut pas s'identifier à qui il envoie le mot de passe, il peut alors divulguer le mot de passe par erreur à quelqu'un qui n'a pas l'intention de le divulguer.

Par conséquent, peut-être une meilleure idée que les deux précédentes est d'utiliser le soi-disant protocole défi / réponse, ou protocole défi / réponse. Voici un exemple d'un protocole d'appel / réponse très simple. Ici, nous avons un client, et ici nous avons un serveur. Le client dit au serveur: «Salut, je suis Alice», après quoi le serveur répond avec un appel C. Ensuite, le client va répondre avec un hachage de cet appel envoyé par le serveur, en le combinant avec le mot de passe.



Le serveur connaît la réponse, donc au moment où le serveur peut accepter cette séquence - la réponse du client. Le serveur connaît également le défi qu'il a envoyé et connaît probablement le mot de passe, afin que le serveur puisse calculer la valeur du hachage reçu et voir qu'il correspond réellement à celui envoyé par l'utilisateur.

Une caractéristique positive de ce protocole, si nous ignorons l'existence d'un "homme au milieu" pendant une seconde, est que le serveur sera sûr que l'utilisateur est vraiment Alice, car seule Alice connaîtra ce mot de passe. Dans le même temps, si Alice envoie cette chose non pas au serveur, mais à la personne qui prétendait être le serveur, alors il ne connaîtra pas le mot de passe. Parce qu'un attaquant peut utiliser C, mais il ne connaît toujours pas le mot de passe, et pour le découvrir, il doit à nouveau inverser cette fonction de hachage. Avez-vous des questions?

Étudiant: un client peut-il envoyer un mot de passe haché au serveur au lieu d'envoyer un mot de passe à un serveur et de recevoir un appel de serveur haché?

Professeur: c'est-à-dire que vous demandez pourquoi le client n'envoie tout simplement pas le mot de passe haché au serveur? Il y a 2 raisons à cela. Nous en discuterons un plus tard, il s'appelle la protection Antihammering et a été créé pour se défendre contre les "mauvais" clients, en demandant constamment: "est-ce un mot de passe, ou est-ce un mot de passe, peut-être est-ce un mot de passe?" Ce mécanisme d'authentification simplifie le processus pour le serveur et le client, mais vous pouvez essentiellement créer un hachage côté client, en utilisant JavaScript ou quelque chose comme ça. Mais l'idée de base est que, d'une manière ou d'une autre, vous devez garantir une complexité d'authentification maximale afin d'empêcher l'attaquant de deviner rapidement le mot de passe. D'autres questions?



Étudiant: Je voulais juste noter que même si le client fait du hachage, alors dans le cas où quelqu'un prend le contrôle de la table du serveur et l'utilise pour le hachage, il pourra accéder au réseau.

Professeur: absolument vrai. Oui, cela devient un peu dangereux selon qui peut prendre possession de cet appel C. Parce que si le client et le serveur peuvent choisir les valeurs de ce C, cela complique la capacité du client à organiser de telles attaques. L'un des problèmes liés à l'utilisation de ce protocole est que le client n'est pas en mesure de randomiser cette valeur HCC. On peut imaginer que vous pouvez rendre ce protocole plus compliqué pour l'inversion du serveur, si le client est capable de sélectionner un appel C dans la partie HCC, mais dans ce cas il y aura une juxtaposition des appels client et serveur.
S'il n'y a plus de questions, nous supposerons que nous avons terminé la discussion sur les mécanismes de transfert de mot de passe du client vers le serveur. , , brute-force, -, .

, , , HCC. , «». « ».

, , , , « ». «» , « » .

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

:oui, sont utilisés. Ces protocoles offrent des garanties de cryptage plus solides. Dans la plupart des cas, ils ne sont pas rétrocompatibles avec les systèmes actuels, donc en pratique, vous ne remarquez pas la fréquence à laquelle ils sont utilisés. Mais il existe certains protocoles qui permettent au serveur de ne pas savoir du tout quel est le mot de passe, comme ZKP, qui sont vraiment utilisés dans la pratique.

27:20 min

Cours MIT "Sécurité des systèmes informatiques". Conférence 17: Authentification des utilisateurs, partie 2


La version complète du cours est disponible ici .

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander ici .

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?