Bonjour, Habr! Je m'appelle Akhmadeev Rinat, je suis Sr. Développeur PHP.
Je vous présente le résumé du rapport Rendez les mots de passe géniaux à nouveau! Comment vaincre bruteforce et laisser les pirates avec rien d'Alexey Ermishkin de Virgil Security avec HighLoad ++ 2018 .
Quand je suis allé au rapport, j'étais pessimiste. Mais depuis Puisque c'est Virgil Security, j'ai quand même décidé d'y aller. Au début, le rapport semblait vraiment du capitaine, et j'ai même commencé à perdre tout intérêt, mais ensuite, comme il s'est avéré, j'ai même découvert plusieurs nouvelles approches de protection par mot de passe qui sont différentes du hachage de sel habituel.
Le rapport examine les moyens de protéger les mots de passe des hachages vers des approches plus modernes, telles que le mot de passe Facebook, Oignon, Sphinx et Pythia. À la toute fin, les nouveaux services de chiffrement renforcé par mot de passe (PHE) sont introduits.
J'ai tellement aimé le rapport que j'ai préparé un recueil. Je recommande à chacun de se familiariser.
Alexey Ermishkin a partagé les diapositives et le rapport vidéo dans les commentaires:
Résumé
Entrée
Bonjour à tous, bonjour à tous! Je suis heureux de vous voir tous à la Conférence Highload. Je m'appelle Alexey Ermishkin, je travaille pour Virgil Security.
Nous sommes engagés dans le développement de divers produits cryptographiques pour les développeurs individuels et les entreprises. Nous nous concentrons sur des solutions de bout en bout, c'est lorsque vous n'avez pas besoin de faire confiance au service pour effectuer des actions telles que le transfert de données, l'authentification, etc. Nos SDK sont ouverts et accessibles à tous.
Les mots de passe sont depuis longtemps utilisés comme moyen d'authentification, comme moyen de se rendre quelque part. C'était bien avant l'apparition des ordinateurs. Mais avec l'avènement des ordinateurs, avec l'avènement des systèmes informatiques, les gens n'ont pas abandonné l'habitude d'utiliser des mots de passe. Cela est devenu un très gros problème pour les développeurs, car ils se sont heurtés à la difficulté de rendre les systèmes à la fois pratiques, rapides et sécurisés. Très souvent, lorsque deux de ces aspects essaient de bien faire, le troisième ne fonctionne pas très bien. Si vous rendez le système productif et sécurisé, cela peut être gênant, etc.
Alors, de quoi allons-nous parler aujourd'hui?
Je vais parler de la protection contre les attaques hors ligne. Lorsque des mots de passe entrent dans vos bases de données, l'utilisateur ne les contrôle pas. Si votre base de données est piratée, elle fuit quelque part, puis les pirates peuvent tout faire avec. Même si vous avez en quelque sorte protégé les mots de passe, ils peuvent commencer à les trier et ils n'ont besoin d'interagir avec personne pour cela, ils ont déjà tout pour cela. De plus, les utilisateurs n'arrêtent pas d'utiliser des mots de passe faibles. Les politiques de mot de passe sont bien sûr utiles, mais pas toujours pratiques, c'est-à-dire même lorsque les gens entrent, cela semble être un mot de passe fort, la politique dit toujours que vous devez ajouter une lettre ou un chiffre, alors pour eux, ce n'est pas pratique. Il est également évident que le problème est la nécessité de comparer ce que l'utilisateur a entré avec ce que vous avez dans la base de données. Comment le faire en toute sécurité? Eh bien, n'oublions pas qu'à l'intérieur de l'entreprise, il y a aussi des gens qui ne sont pas complètement sympathiques et qui voudraient aussi s'en protéger.
Hashs
En principe, pourquoi les mots de passe sont-ils un sujet si douloureux, pourquoi vaut-il la peine de travailler avec eux plus soigneusement? Le problème est que le mot de passe a une petite entropie . Qu'est-ce que l'entropie? Il s'agit de la quantité d'informations contenues dans les données, c'est-à-dire par exemple, dans le mot Highload, 8 lettres correspondent à 8 octets, mais si l'on compte l'entropie, ce ne sera pas 64 bits comme le mot entier, mais moins de 30 bits. Aujourd'hui, quand ils parlent de briser le mot de passe, ils disent qu'il est possible de casser des mots de passe avec entropie en un tel temps ni plus ni moins que de bits. C'est-à-dire même le nombre même de mots de passe n'est pas pris en compte.
Comment les gens ont-ils commencé à utiliser la sécurité par mot de passe? La première chose qui m'est venue à l'esprit était d'utiliser des hachages cryptographiques unidirectionnels.
Leur caractéristique remarquable est qu'ils ne peuvent pas être refusés. C'est-à-dire Si vous avez transféré des informations sur ce hachage, reçu une valeur en sortie, vous ne pouvez pas récupérer ces informations à partir de cette valeur. Mais, malheureusement, ils sont calculés très rapidement. Par exemple, un cluster moderne de 4 cartes graphiques NVidia peut traiter plusieurs milliards de mots de passe par seconde. C'est-à-dire si l'entropie de votre mot de passe est inférieure à 40 bits, un cluster de 4 cartes vidéo le récupérera en une minute, voire moins.
Tables arc-en-ciel
De plus, chaque hachage délicat a sa propre table arc-en-ciel . Quelle est cette table et comment sont-elles fabriquées?
C'est-à-dire ils prennent les mots de passe et les combinaisons de caractères les plus populaires qui peuvent tenir sur le disque dur, considèrent les hachages pour eux et les mettent sur un peu plus de stockage pour plusieurs téraoctets. Lorsqu'il existe une sorte de hachage, vous ne pouvez pas le calculer, mais trouvez-le très rapidement à partir de ces tableaux et comparez-le avec le mot de passe qui a été calculé précédemment. C'est-à-dire Les avantages des tables sont qu'elles fonctionnent très rapidement, mais vous avez besoin de beaucoup d'espace pour les stocker. Néanmoins, il existe des tableaux pour les hachages les plus populaires sur Internet, ils peuvent être téléchargés, voire achetés.
Note de l'auteur du synopsis: Wikipedia n'est pas d'accord avec le locuteur: "Rainbow table est une version spéciale des tables de recherche pour inverser les fonctions de hachage cryptographiques en utilisant le mécanisme d'un compromis raisonnable entre le temps de recherche dans la table et la mémoire occupée." C'est-à-dire il ne stocke pas les hachages des mots de passe les plus populaires qui tiendront sur le disque, mais simplement les hachages de certains mots de passe, le reste est calculé sur la base de ceux qui existent - il y a plusieurs mots de passe par enregistrement dans le tableau.
Du sel
Mais là encore, chaque table arc-en-ciel a son propre sel . Qu'est-ce que le sel? Il s'agit d'un ensemble aléatoire d'octets, qui est ajouté au mot de passe. Il est stocké dans une table quelque part près du hachage et protège des tables arc-en-ciel.
C'est-à-dire les personnes qui mettent la main sur une base avec des hachages salés devront toujours calculer ces hachages. Mais le problème est que ces hachages sont calculés très rapidement et le sel n'aide pas beaucoup ici.
Comment ralentir la recherche?
Une solution naturelle pourrait être de ralentir le tri du hachage d'une manière ou d'une autre. Comment cela peut-il se faire?
L'approche la plus naïve consiste à prendre une sorte de fonction de hachage, par exemple sha256, et à la calculer de manière itérative, c'est-à-dire calculer le hachage, à partir de ce hachage, le hachage à nouveau, etc. Vous pouvez le faire plusieurs milliers voire plusieurs millions de fois. Le problème est que si vous écrivez une telle implémentation vous-même, elle sera très probablement plus lente que l'implémentation de personnes professionnellement impliquées dans la recherche de mots de passe.
SCrypt , Bcrypt , Argon2
Et par conséquent, les cryptographes ont proposé plusieurs fonctions spécialement conçues pour ralentir la recherche de mot de passe - ils utilisent une grande quantité de mémoire et toutes les instructions de processeur modernes possibles. Si le mot de passe protégé par une telle fonction tombe entre les mains des attaquants, ils devront alors utiliser du matériel très puissant.
Par exemple, la fonction Argon2 la plus moderne fonctionne comme suit: dans le diagramme, vous pouvez voir qu'il y a beaucoup de blocs de mémoire différents à travers lesquels le hachage est exécuté. Il le fait de différentes manières aller-retour, la mémoire est utilisée de manière très intensive, toute la mémoire est utilisée. Il est assez difficile d'optimiser une telle fonction (vitesse de recherche).
Mais ces approches ont aussi leurs inconvénients. Ces fonctions sont ralenties spécialement, mais elles sont spécialement lentes non seulement pour les attaquants, elles le seront également spécialement pour vous. Ils chargeront votre fer. Ces fonctions sont personnalisables, c'est-à-dire vous pouvez choisir la quantité de mémoire qui sera utilisée pour calculer le hachage d'un mot de passe unique, jusqu'à plusieurs gigaoctets, combien de passages sur cette mémoire. Si vous réglez ces paramètres très sérieusement, votre propre matériel en souffrira et si beaucoup de personnes se connectent au système, il vous suffit d'allouer des ressources assez importantes pour la protection par mot de passe et les mots de passe simples, eh bien, des mots de passe très simples peuvent toujours être récupérés .
Mot de passe de Facebook Oignon
Les gens y ont réfléchi et ont posé la question: est-il possible d'obtenir les mêmes propriétés sans charger le backend, sans charger leurs propres serveurs?
Facebook a été l' un des pionniers dans ce domaine. Ces lignes que vous voyez sont les étapes historiques de Facebook, comment elles protégeaient les mots de passe, au début ce n'étaient que des mots de passe, puis elles ont pris l'ancienne fonction md5 , qui a été fissurée pendant longtemps, puis elles y ont ajouté du sel et ont pris le hash sha1 , et puis c'est arrivé chose intéressante, ils ont apporté le calcul de la fonction hmac (c'est un hachage avec une clé) au service distant.
Comment ça marche? Il y a un backend, il y a un service à distance. Il existe une sorte de clé secrète sur ce service. Une personne entre dans le backend, entre son mot de passe. Ce mot de passe est mélangé avec le sel qui se trouve dans la base de données, exécuté via un hachage et envoyé au service. Le service prend sa clé privée, calcule la fonction hmac et la renvoie entièrement. Sur le backend, il est placé dans la base.
Qu'est-ce que ça donne? Si Facebook a une base de données d'utilisateurs, cela ne vaut pas la peine d'y trier les mots de passe, car ils n'ont pas de clé secrète distante. Mais le problème avec l'approche de Facebook est que si quelque chose arrive à leur clé privée distante, ils auront de gros problèmes. Ils ne peuvent rien y faire car ils utilisent des hachages, ils utilisent hmac. Ils n'ont aucun moyen de résoudre cette situation de manière à ce que les utilisateurs ne remarquent rien et cela se retrouvera dans un coin.
Sphinx
Les cryptographes ont regardé le tout. Ils ont aimé l'idée d'utiliser des services à distance et ont décidé de réfléchir: est-il possible de faire encore mieux? Est-il possible de créer un système similaire, mais sans les inconvénients dont Facebook l'a doté?
Et ils ont décidé d'aborder ce problème comme suit: que faire si le mot de passe ou le hachage de mot de passe est représenté sous forme de nombre? Si nous avons le mot passw0rd , il se compose de 8 octets. Dans presque tous les langages de programmation, il existe des types entiers de huit octets, c'est-à-dire En principe, c'est la même chose. C'est-à-dire 8 octets, le mot passw0rd et nous pouvons le représenter comme un nombre décimal régulier. Qu'est-ce que cela nous donne? Cela nous donne une liberté d'action complètement différente. Nous pouvons ajouter des mots de passe ou des hachages, les multiplier, les transformer en d'autres nombres. Nous pouvons effectuer de véritables opérations mathématiques sérieuses avec eux.
Sphinx est l'un des premiers systèmes à utiliser cette technologie. Elle est apparue il y a quelques années. Il s'agit d'un gestionnaire de mots de passe déterministe. Il existe de nombreux programmes différents tels que keepass , où vous avez un mot de passe principal et pour chaque site, il en génère un au hasard. Mais il y a aussi des choses déterministes où vous entrez votre mot de passe principal, le site auquel vous souhaitez accéder et il y calcule quelque chose et émet un mot de passe unique pour chaque site. Mais il est clair que si ce mot de passe principal va quelque part, tous les mots de passe de vos sites seront définitivement compromis.
Comment Sphinx a-t-il abordé ce problème? Il prend le mot de passe principal, il prend le domaine auquel vous souhaitez vous connecter, exécute le tout via un hachage et le transforme en un nombre. Mais en fait, la cryptographie elliptique y est utilisée, pour plus de simplicité j'expliquerai tout cela sur des nombres ordinaires avec des mathématiques ordinaires. Il le transforme en nombre (appelons-le a ) et que fait-il ensuite?
Une chose absolument merveilleuse, chaque fois que nous pouvons générer un grand nombre aléatoire r . Si nous élevons le nombre a à la puissance de r , et quelque temps plus tard, nous élevons ce nombre à la puissance inverse du nombre r , alors nous obtenons le même nombre a , non? C'est-à-dire nous pouvons masquer quelque chose depuis le début, puis le démasquer.
Et que fait le sphinx? Encore une fois, il y a un utilisateur, il y a un service à distance. Un numéro masqué est envoyé à ce service distant. Sur le service distant, il existe une clé privée b . Que fait-il? Il multiplie le nombre envoyé a^r par sa clé secrète b et le renvoie. ( Note de l'auteur du recueil: sur la diapositive, le nombre envoyé n'est pas multiplié par la clé privée, mais est élevé au degré de la clé privée, mais l'essentiel est ). Étant donné que le nombre r différent à chaque fois, le service distant ne peut rien dire sur le mot de passe et le domaine masqués, c'est-à-dire chaque fois qu'il voit des nombres aléatoires différents. Et il multiplie simplement par sa clé privée b et renvoie.
L'utilisateur démasque ce que le serveur lui a envoyé et il obtient un numéro - son mot de passe principal avec le domaine multiplié par la clé secrète du serveur a^b . Il s'avère qu'il ne connaît pas la clé secrète du serveur, le serveur ne sait pas ce que l'utilisateur lui a envoyé, mais au final, il obtient également une sorte de numéro déterministe. Chaque fois que vous exécutez ce protocole, le déguisement sera différent, mais le résultat sera toujours le même et ce résultat peut ensuite être reconverti en une sorte de mot de passe et utilisé pour accéder à divers sites.
Une technologie vraiment merveilleuse. Tout d'abord, vous pouvez générer des mots de passe volumineux, c'est-à-dire il protège de la casse. Deuxièmement, si un pirate accède à plusieurs mots de passe, il ne pourra rien dire des autres, car ils sont générés indépendamment les uns des autres. Troisièmement, si le mot de passe de l'utilisateur disparaît quelque part, cela ne donnera rien non plus, car les pirates n'auront pas de clé secrète. Quatrièmement, cela fonctionne très rapidement, car aucun grand hachage itératif n'est nécessaire ici, c'est-à-dire littéralement 2-3 multiplications sont effectuées et tout fonctionne instantanément.
Mais ce système a ses inconvénients. Le serveur avec lequel l'utilisateur parle ne sait rien de lui. Il reçoit simplement des nombres aléatoires en entrée, les multiplie par quelque chose et les renvoie. Le client ne sait rien non plus sur le serveur, il envoie quelque chose quelque part, reçoit le résultat, cela fonctionne - bien. Mais si quelque chose arrive au service, l'utilisateur ne pourra rien en dire, il n'a pas d'informations à ce sujet. La clé secrète ne peut pas non plus être modifiée, rien ne peut être fait avec.
Pythia
Cela pourrait-il être mieux?
Les cryptographes ont examiné ce système et ont pensé, est-il possible d'améliorer le système et de le compléter avec des propriétés qui nous permettraient de dire qu'il est conforme aux principes de bout en bout? C'est-à-dire le client peut communiquer avec le serveur, mais en même temps, il peut également l'authentifier et lui faire confiance dans une certaine mesure.
Et ils ont trouvé un protocole appelé Pythia .
Il a été réalisé par le merveilleux homme Adam Everspaugh avec ses collègues. Qu'est-ce qui le rend unique? Premièrement, le service sait qui entre le mot de passe, c'est-à-dire l'ID utilisateur est transmis au serveur après le mot de passe. Il peut s'agir d'une boîte d'identification aléatoire située à côté, ou simplement d'un nom d'utilisateur. Peu importe. Mais le service le sait. Mais le serveur n'en sait pas seulement un peu, il peut prouver strictement mathématiquement que c'est bien lui.
Comment ça marche? Il y a un backend (une sorte de service web, un site) et il y a un service Pythia. Que fait le backend et que fait le service? Il existe une clé privée k sur le service, mais il transfère également sa clé publique au backend. Le backend de service envoie non seulement le numéro masqué a^r , comme dans le protocole Sphinx, mais envoie également une sorte d'identifiant d'utilisateur ( UserID ). Le service multiplie l'ID utilisateur et le mot de passe par sa clé privée et le résultat (UserID, a)^(r*k) envoie le backend. Il renvoie également une certaine Proof , qui peut être utilisée par le backend pour vérifier que le serveur n'a pas été piraté, qu'il répond comme il se doit.
Ensuite, il y a un démasquage et le nombre y qui en résulte est mis dans une base de données. Dans la base de données, nous avons non seulement un hachage, mais un nombre, un point d'une courbe elliptique.
Il y a quelques points intéressants ici:
- La possibilité pour le serveur de combiner l'ID utilisateur et le mot de passe en un seul numéro. C'est ce qu'on appelle une opération bilinéaire ou appariement bilinéaire. Il s'agit d'un calcul relativement nouveau, qui a récemment commencé à être utilisé. Elle a toutes les propriétés des nouveaux mathématiciens en ce que 30 ans ne se sont pas écoulés pour que tout le monde soit convaincu que tout est normal avec ça.
- Mais la
Proof qui envoie le service est une technologie assez ancienne. C'est ce qu'on appelle le protocole Schnorr . La génération de clé publique est la multiplication d'un point de base par une clé secrète. Le protocole Schnorr prouve que la clé secrète utilisée pour générer la clé publique a été utilisée pour multiplier le mot de passe de l'utilisateur par le même numéro. Ce protocole existe depuis longtemps, il est beaucoup utilisé où et il vous permet de le prouver. C'est ce qu'on appelle la preuve à l'épreuve du zéro - le serveur n'affiche pas sa clé publique, mais il dit que l'opération que j'ai effectuée a été effectuée par cette clé privée, ce que nous avions initialement convenu.
Quels sont les avantages de ce système?
Et elle n'en a pas beaucoup.
- Le système ne charge pas le backend. Parce que le backend fait tout, il transforme le mot de passe en nombre, le déguise, l'envoie, puis démasque également le résultat.
- Si une base de données avec de tels numéros vous est volée, le tri des mots de passe n'a également aucun sens sans clé privée.
- Le service Pythia peut bloquer les tentatives de force brute, ce qui signifie que le backend n'a pas à le faire en principe. S'il voit que sous le même ID utilisateur, ils essaient d'effectuer cette opération de transformation plusieurs fois, il peut simplement le couper et le bloquer à la limite de débit.
- Grâce à un déguisement, le service ne sait rien du mot de passe. Chaque fois qu'un nouveau numéro aléatoire lui est envoyé. Seul l'identifiant utilisateur reste constant.
- Grâce à ZKP (Zero-knowledge proof), le backend sait toujours que c'est le service même qu'il avait contacté une fois.
- Si vous avez une base de données avec des hachages et du sel par exemple, vous pouvez migrer vers une telle solution de manière transparente pour les utilisateurs. Ils peuvent même ne rien remarquer. Au lieu du mot de passe de l'utilisateur, vous prenez son hachage, le conduisez en Pythia et à l'avenir utilisez simplement ce protocole, obtenez le nombre
y , remettez-le dans votre base de données. Le hachage peut ensuite être supprimé. Chaque fois qu'un utilisateur se connecte à votre système, ce protocole sera exécuté, un certain nombre sera obtenu en conséquence, que vous comparerez avec ce qui est dans la base de données. Le système d'authentification lui-même restera inchangé, car les utilisateurs se connecteront plus tôt et se connecteront, avec les mêmes mots de passe, même les plus faibles. Dans ce cas, le système sera beaucoup plus sécurisé.
Mais ce ne sont pas tous les goodies.
L'une des principales caractéristiques est que même si le service Pythia est piraté, il est possible de générer une nouvelle clé privée. Dans notre base de données, un nombre est stocké, pas un hachage. Si nous représentons l'ancienne clé comme le nombre k et la nouvelle comme le nombre k' , alors nous pouvons calculer un nombre appelé jeton de mise à jour. Pour ce faire, nous multiplions le nouveau nombre par le nombre inverse de l'ancien. Et avec ce jeton de mise à jour, vous pouvez parcourir la base de données pour chaque utilisateur et multiplier ce nombre y par le jeton de mise à jour. Une fois cette opération effectuée, votre système continue de fonctionner avec la nouvelle clé privée du service distant. Tout se passe instantanément. Si une catastrophe survient, votre base de données avec des mots de passe vous est volée, vous libérez un jeton de mise à jour d'un simple clic et le fait que des pirates vous ont volé devient instantanément inutile. Vous parcourez simplement tous les enregistrements en arrière-plan, les mettez à jour et ils fonctionnent avec la nouvelle clé secrète pour vous. Les utilisateurs ne remarquent généralement rien. C'est-à-dire La mise à jour transparente et l'invalidation instantanée de la base de données de mots de passe sont quelques-unes des principales fonctionnalités innovantes de ce système.
Mais ce n'est pas tout.
Le nombre qui se trouve dans la base est grand y , il est fondamentalement grand et semble assez pseudo-aléatoire, c'est-à-dire c'est si facile de ne pas le ramasser. Si nous transférons les fonctionnalités que nous avons sur le backend, par exemple, sur les appareils clients, sur les téléphones, nous pouvons utiliser ce y pour générer des clés. Nous avons appelé cette chose BrainKey. Cela signifie que l'utilisateur entre le mot de passe quelque part sur le téléphone, le déguise également et l'envoie au service distant. Le service lui renvoie un certain nombre y puis vous pouvez utiliser ce y pour générer des clés asymétriques. Ainsi, l'utilisateur de son mot de passe peut obtenir une paire de clés. Ceci est utilisé dans toutes sortes de BrainWallets . C'est lorsque vous entrez le mot de passe et que le portefeuille Bitcoin est généré pour cela. Mais cette application n'est pas limitée aux crypto-monnaies, c'est une signature numérique, des sauvegardes et la récupération de compte, c'est-à-dire partout où la cryptographie asymétrique est utilisée, où des clés asymétriques sont nécessaires. Tout cela peut être utilisé, mais en même temps une paire de clés, et elles peuvent, selon les besoins, être générées autant que vous le souhaitez. Ils dépendent donc tous du mot de passe de l'utilisateur, ce qui est très pratique.
Dans un baril de miel, ce n'est pas sans une mouche dans la pommade.
Et les caractéristiques de cette technologie sont qu'elle est très nouvelle. Il utilise une courbe elliptique, qui est destinée aux opérations bilinéaires ( BLS12-381 ). Les mathématiques elles-mêmes existent depuis un certain temps, mais cette courbe particulière, qui est notamment utilisée dans notre implémentation, n'est utilisée que dans ZCash sauf nous. En conséquence, les bibliothèques qui utilisent ce nouveau calcul peuvent être comptées sur les doigts d'une main. Pour mettre cela en état de production, vous devez consacrer un certain temps et des efforts. Néanmoins, l'industrie ne reste pas immobile et tous ces inconvénients sont temporaires. En raison des deux premières propriétés, la vitesse de ces opérations bilinéaires n'est pas très cohérente avec les mathématiques modernes, elliptiques en particulier, que nous utilisons tous maintenant, lorsque nous utilisons le protocole TLS, lorsque nous utilisons certains sites. Il s'agit de plusieurs centaines d'opérations sur un service sur un cœur. En fait, cela ne nous a pas arrêtés et au printemps, nous avons implémenté ce protocole, l'avons publié en production et traduit tous nos enregistrements, les avons protégés à l'aide de ce protocole. En principe, nous sommes satisfaits des performances de nos tâches en cours, si nécessaire, nous lèverons un autre nœud avec le service Pythia et, en principe, vous pouvez déjà jouer avec tout cela.
PHE
Mais nous nous sommes demandé si nous pouvions faire encore mieux? Est-il possible d'obtenir les propriétés que Pythia fournit en utilisant les mathématiques d'hier? Pas demain, pas aujourd'hui, mais même hier, qui est utilisé depuis de nombreuses années.
Et littéralement en juillet de cette année, les scientifiques ont publié un nouveau protocole appelé Simple Password-Hardened Encryption Services, ou PHE pour faire court.
Voici Russell Lai , un scientifique européen.
Quel est l'avantage de ce service? Premièrement, il utilise la courbe P-256 standard, qui est utilisée partout, dans tous les navigateurs, produits, partout la courbe par défaut, qui existe depuis de nombreuses années. Deuxièmement, cette chose fonctionne environ 10 fois plus rapidement que Pythia et utilise des primitives standard. C'est un peu difficile, mais vous pouvez l'implémenter de vos propres mains sans utiliser de bibliothèques obscures. Vous pouvez utiliser OpenSSL ou Bouncy Castle , n'importe quoi.
Mais cela fonctionne un peu différemment. Encore une fois, il y a un backend, il y a un service PHE. Le backend a une clé publique, le service a une clé privée y . Contrairement à Pythia, le processus d'enregistrement et le processus de vérification du mot de passe sont un peu différents. Lorsqu'un nouvel utilisateur arrive sur le service et souhaite s'enregistrer, que fait le backend? Dès le début, il a demandé au service PHE, veuillez me donner quelques données que je peux utiliser pour m'inscrire, une sorte de fiche d'inscription. Le service dit OK et répond au backend avec les choses suivantes. Il génère un sel aléatoire de 32 octets ( sNonce ). Sur la base de ce sel et de sa clé privée y, il génère deux nombres, appelons-les C0 et C1 . Il génère également des preuves ( Proof ) que ces deux nombres ou 2 points ont été générés précisément à l'aide de sa clé privée y , en utilisant le protocole Schnorr (comme dans les protocoles précédents). Le backend vérifie la Proof . Il n'y a pas encore de mot de passe ici. Que fait le backend? Pour sa part, il possède également sa propre clé privée cliente x et, ayant reçu le mot de passe de l'utilisateur, il fait à peu près la même chose que le service, n'y ajoute que le mot de passe. Il prend au hasard cNonce (sel client aléatoire), un mot de passe, et génère à nouveau 2 nombres HC0 et HC1 . Pourquoi 2? Parce que le premier HC0 utilisé pour l'authentification, et le deuxième numéro HC1 mélange un certain nombre aléatoire M multiplié par la clé privée x ( MC ). Le nombre M est également de 32 octets et peut ensuite être utilisé pour crypter les données utilisateur (nous avons les services de cryptage) ( note de l'auteur de la note: la clé de cryptage dans ce cas sera MC ). Le numéro MC ne sera disponible sous forme de clé qu'après que l'utilisateur aura entré le mot de passe correct. Il s'avère qu'au stade de l'enregistrement, vous pouvez générer non seulement un enregistrement d'autorisation, mais également une clé de cryptage, unique pour chaque utilisateur, avec laquelle vous pouvez crypter son profil, certaines données et autre chose. Ensuite, le backend additionne simplement ce que le service a envoyé et ce qu'il a fait - additionne ces points et obtient T0 et T1 . Dans le premier cas, il en additionne deux ( C0 + HC0 ) et dans le second trois ( C1 + HC1 + MC ). Et il met les sels de base 2 ( sNonce , cNonce ), à l'aide desquels ces nombres ont été obtenus et 2 nombres ( T0 et T1 ), qui se sont révélés à la suite de la somme.
Par conséquent, le processus d'authentification de l'utilisateur se produit dans l'ordre inverse. L'utilisateur entre son mot de passe sur le backend. Le backend calcule HC0 et de ce qu'il a dans la base de données, soustrait HC0 de T0 et envoie le C0 résultant au service avec le sel du serveur. Le service, connaissant le sel du serveur, calcule le même point en lui-même et regarde, il coïncide avec s'il a envoyé un backend ou non, s'il correspond, alors le mot de passe est correct et vous pouvez y répondre avec le deuxième nombre C1 , qu'il soustraira avec HC1 du nombre T1 et obtenez la clé de cryptage. Ainsi, le mot de passe du service PHE ne disparaît même pas. Il ne quitte même pas le backend. Il se présente sous la forme de quelques points multipliés par la clé privée du backend. Il n'existe même pas en tant que tel, mais en même temps, le service à distance peut tirer une conclusion stricte quant à savoir si ce mot de passe est correct ou non, et prouver par là qu'il a effectué tous les calculs à l'aide de sa clé privée y .
Quelles sont les fonctionnalités de ce système?
Le mot de passe, comme je l'ai dit, ne quitte pas le backend. Mais contrairement à Pythia, vous avez besoin d'une clé privée sur le backend. Eh bien, nous avons besoin et avons besoin, économisons quelque part. PHE possède toutes les fonctions de base de Pythia:
- Vous pouvez également émettre un jeton de mise à jour si quelque chose vous arrive avec la clé privée;
- Vous pouvez également parcourir toute la base de données, mettre à jour et tout sera comme il était;
- protection contre les fouilles;
- le service ne sait rien du mot de passe;
- (Pythia , , , , PHE );
- .
...
… . . passw0rd.io . password , 18- , , zero trust, .. . , , .. Let's encrypt . , . CLI , . 2 SDK , GO .Net, .
:
- .
- .
- .
, .
?
37. ?
.
Q: , ! . , Pythia update token, ? private key . update token? Ou pas?
A: , update token- .
Q: . - update token-, Private key ?
A: , update token-, , - , , , update token. , .. .
Q: , , , .
A: .. .
Q: , , , - Pythia - , , , ?
A: .
Q: ?
A: , Pythia . C'est-à-dire , .
Q: ( ) bcrypt ?
A: , , , .
Q: , . ? , …
A: password
Q: password ? Feu! Généralement.
A: 123456 , 12345, 123456.
Q: . Pythia , PHE .
A: , .
Q: . . ? production ?
A: . ! Pythia.
Q: Pythia, , ?
A: .
Q: , ?
A: .
Q: , , !
A: SDK, .
Q: , , , , .. - , ? ? ?
A: , , , .. PHE, , 5 2 , 2 5 . , . PHE ( , ), , 10 , .
Q: .. - , - ? ?
A: . rate limiting, , .
Q: .. , ?
A: .
Q: . , .. Pythia (), , ? ?
A: , , .
Q: , update ?
A: , Pythia , , - - , , , )
A: ? ! . , , PHE, , .
Conclusions
PHE ( ) + — ( , , ) ( ). PHE , .
:
, .
Scratch Virgil Security , , !
( )?
UPD : Scratch . . , . .