Cher habrozhitel! Chers experts! Je présente pour votre évaluation un nouveau concept d'identification des utilisateurs sur les sites Web qui, je l'espère, deviendra avec votre aide un standard Internet ouvert, améliorant un peu ce monde Internet. Il s'agit d'une version provisoire du protocole d'authentification sans mot de passe, conçue comme un article gratuit. Et si l'idée sous-jacente reçoit une évaluation positive de votre part, cher lecteur, je continuerai à la publier sur reddit.com et rfc-editor.org. Et j'espère que je pourrai intéresser les développeurs des principaux navigateurs à sa mise en œuvre. Par conséquent, j'attends de vous des critiques constructives.

Attention: beaucoup de texte.


La question est donc. Est-il possible d'identifier sans ambiguïté les visiteurs du site sans divulguer leurs données personnelles et le suivi entre les différents sites? Est-il possible, en résolvant un tel problème, d'abandonner complètement la forme d'autorisation la plus primitive par login / mot de passe et d'utiliser cookie / localStorage?

D'une part, les sites doivent reconnaître un client afin, par exemple, de «restaurer» leurs paramètres, panier de produits, publicités, articles, etc. D'autre part, les visiteurs souhaitent rester aussi anonymes que possible, sans révéler leurs données personnelles, et empêcher les sites tiers de les suivre. Et ces derniers peuvent le faire en échangeant entre eux les données collectées.

Cela ressemble à une tâche pour s'assurer que les loups sont pleins et que les moutons sont en sécurité. Est-ce réel?

Dans une certaine mesure, je pense - vraiment.

Table des matières

1 concept d'authentification sans mot de passe
1.1 Clés et jetons au lieu de connexions et mots de passe
1.2 Structure des jetons
1.3 En-têtes de protocole HTTP
1.4 Comment les clients identifient-ils les sites?
1.4.2 Comment savoir si un site prend en charge ce protocole?
1.5 Comment les clients autorisent-ils les sites?
1.6 Comment mettre en place une identification client fiable?
1.7 Autorisation sur le site vue par l'utilisateur
1.8 Comment une clé de site change-t-elle?
1.9 Comment l’autorisation interdomaines est-elle mise en œuvre?
1.10 Comment implémenter l'authentification inter-domaines?
1.11 Mobilité du compte

2 Description technique du protocole
2.0 Algorithme de génération de clés de domaine
2.1 l'algorithme de calcul du jeton source
2.2 Algorithme de protection des jetons pendant le transfert
2.3 Procédure d'échange de sel entre le navigateur et le serveur
2.4 Règles pour la formation du champ Contexte
2.5 Règles de définition des champs expéditeur et destinataire
2.6 Détails sur les tables de définition de contexte
2.7 Scénarios de protocole
2.8 Traitement des jetons sur le serveur
2.9 Authentification interdomaine

3 Recommandations de sécurité
3.1 Protection des informations clés contre les accès non autorisés
3.2 À propos des mots de passe en tant que clés de domaine
3.3 Risques de perdre / compromettre des clés et de les minimiser

4 Attaques contre le régime d'autorisation
4.1 Suivi des utilisateurs
4.2 Attaque XSS
4.3 Attaque CSRF
4.4 Suivi à l'aide de l'authentification unique
4.5 Compromis clé pour l'authentification unique
4.6 Compromission de jetons pendant le transfert
4.7 Piratage d'un site Web et compromission de jetons

Conclusion

1 concept d'authentification sans mot de passe

1.1 Clés et jetons au lieu de connexions et mots de passe

Pour chaque domaine, y compris les enfants, le navigateur client génère aléatoirement une clé unique de 256 bits $$ . Cette clé n'est jamais transmise. Reste constant dans la session de l'utilisateur. Chaque nouvelle session crée une nouvelle clé.
Basé sur une clé $$ le navigateur génère un jeton 256 bits ^* à l'aide d'un algorithme spécial $$ pour identifier l'utilisateur avec un domaine spécifique. Jeton d'identification $$ l'utilisateur (ci-après simplement appelé le jeton) remplace les cookies de session comme PHPSESSIONID et JSESSIONID.
Clé $$ peut être " corrigé " par l'utilisateur. La fixation de la clé permettra à l'utilisateur de rester autorisé sur le site pour une durée illimitée dans différentes sessions de navigateur et de retourner l'autorisation précédemment existante. Il s'agit d' un analogue de la fonction «se souvenir de moi» .
Lorsque la validation est annulée, le navigateur «oubliera» cette clé et recommencera à générer une clé aléatoire pour ce domaine pour chaque nouvelle session (à partir de la session actuelle), ce qui est analogue à la «sortie» de l'utilisateur du site. La sortie est instantanée, ne nécessitant pas de rechargement de page.
L'utilisateur peut créer une clé permanente pour le domaine . La clé permanente, ainsi que la clé fixe, permettra à l'utilisateur de retourner l'autorisation précédente. En fait, cette clé devient un remplacement pour la connexion login-mot de passe.
L'utilisateur a la possibilité de contrôler quand le navigateur du domaine utilisera une clé constante et quand - aléatoire. Il s'agit d' un analogue de la fonction de connexion / déconnexion . Le concept est présenté dans les captures d'écran ci-dessous .
Les méthodes de génération de clés de domaine persistantes assurent la mobilité des comptes d'utilisateurs entre différents appareils. Le protocole définit les éléments suivants:

• génération d'une clé de domaine basée sur une clé principale d'utilisateur
• formation individuelle d'une clé de domaine sur la base d'un capteur biologique de nombre aléatoire
• importation de clés existantes à partir d'un fichier de clés à partir d'un autre appareil

1.2 Structure des jetons

Le jeton est une structure de 256 bits, représentée sous la forme d'une chaîne hexadécimale:

La partie d'identification du jeton (les 128 bits les plus élevés) est similaire à la connexion. Par cette séquence de bits, le serveur peut identifier de manière unique l'utilisateur.
La partie d'authentification du jeton (les 128 bits inférieurs) est similaire au mot de passe. Cette séquence de bits aide le serveur à valider le jeton.
Les règles de validation des jetons sont décrites ci-dessous .

1.3 En-têtes de protocole HTTP

En-têtes utilisés par le client:

CSI-Token : <Token> est utilisé pour envoyer un jeton au serveur
CSI-Token : <Token1>; Changed-To <Token2> est utilisé pour changer le jeton actuel:

• lors de l'autorisation sur une clé permanente,
• lors de l'enregistrement d'une clé permanente,
• lors du changement de la clé permanente.

CSI-Token : <Token> Permanent est utilisé lors de la fixation de la clé aléatoire actuelle par l'utilisateur.
CSI-Token : <Token> La déconnexion est utilisée pour mettre fin prématurément à la session en cours.

En-têtes utilisés par le serveur:
Support CSI: oui indique au client que le serveur prend en charge le protocole d'autorisation CSI.
CSI-Token-Action: le succès est utilisé pour informer le navigateur de l'acceptation d'un nouveau jeton d'utilisateur (clé de changement).
CSI-Token-Action: abandonner annule la procédure de changement des jetons (retour au jeton précédent).
CSI-Token-Action: l'enregistrement indique au navigateur que le nouveau jeton d'utilisateur est toujours en cours d'enregistrement.
CSI-Token-Action: erreur de vérification de jeton côté serveur non valide .

Enfin
CSI-Salt est envoyé à la fois par le navigateur et le serveur lors de l'échange du «sel» utilisé pour protéger le jeton (partie authentification). Voir ci-dessous pour plus de détails.

1.4 Comment les clients identifient-ils les sites?

Un site peut utiliser un jeton pour identifier un visiteur du site. Dans le même temps, le schéma de génération de jetons et leur capacité de 256 bits garantissent des jetons uniques pour chaque paire: domaine utilisateur. Un autre domaine verra un autre jeton utilisateur. Même s'il est exécuté dans le contexte du site cible (via IFRAME, IMG, LINK, SCRIPT). De plus, un algorithme spécial de génération de jetons protège les utilisateurs contre les attaques XSS et SRF et rend impossible le suivi d'un utilisateur à son insu. Mais en même temps, la technologie SSO reste possible avec sa permission et son identification inter-domaines.
Le token est transmis dans l'en-tête HTTP CSI-Token avec chaque requête vers n'importe quelle ressource de domaine (page, document, image, script, style, police, fichier, requête ajax, ...):

Le jeton est recalculé à chaque requête HTTP (S) : page, image, requête ajax.
Afin d'optimiser les calculs, la mise en cache des jetons par le navigateur est autorisée, mais uniquement pour la durée de la session et uniquement si les conditions de satisfaction de la demande restent inchangées.
Comme indiqué ci-dessus, le jeton peut remplacer les cookies de session tels que PHPSESSIONID et JSESSIONID. La seule différence est que si le site générait précédemment un identifiant permettant au visiteur de suivre un utilisateur spécifique entre ses différentes demandes (après tout, des milliers de demandes d'utilisateurs différents arrivent sur le site en même temps), le client lui-même remplit désormais cette fonction.
Une telle identification est tout à fait suffisante pour vous permettre de faire des achats dans la boutique en ligne, de faire de la publicité sur des sites appropriés, d'écrire sur des forums, sur des réseaux sociaux, sur Wikipedia ou sur des articles Habré.
Oui, l'utilisateur reste anonyme pour le site. Mais il peut s'agir d'un «familier» anonyme du site. Et le serveur peut enregistrer le jeton d'un tel utilisateur de son côté, ainsi que ses données (compte personnel avec achats, préférences, karma, brioches, likes et autres bonus). Mais seulement pour garder sous condition l'achèvement de tout processus commercial: achat, soumission de l'annonce, etc. Les conditions sont déterminées par le site lui-même.
Comme vous pouvez le voir, le protocole est aussi simple que possible pour les sites qui n'ont pas besoin de vous inscrire avant de vous donner la possibilité de prendre des mesures. Mais ceux qui en ont besoin auront un peu plus de mal. Mais plus à ce sujet ci-dessous.

1.4.2 Comment savoir si un site prend en charge ce protocole?

Le site doit transmettre le CSI-Support: oui http-header dans la section Response Headers de sa réponse:

En voyant un tel titre, le navigateur informera discrètement l'utilisateur qu'il peut se sauver sur le site. Par exemple, le symbole clé dans la barre d'adresse:

Un clic sur une clé, par exemple, créera une clé pour le domaine www.youtube.com :

La formation d'une nouvelle clé ne conduit pas à son utilisation automatique.

La clé permanente ne commence à être utilisée que lorsqu'elle est activée par l'utilisateur.

1.5 Comment les clients autorisent-ils les sites?

Il est important de comprendre que le jeton ne rend pas encore l'utilisateur autorisé sur un site particulier - seulement reconnaissable. Mais, comme cela a déjà été dit, vous n'êtes pour l'instant qu'une «personne anonyme» reconnaissable.
Si le site doit vous associer personnellement votre token, hélas, l'inscription sur un tel site ne peut être évitée. Mais dans le protocole proposé, cela est rendu un peu plus facile.

Il est important que les développeurs le comprennent: la plupart des sites n'ont pas besoin de questionnaire. Évitez de forcer les visiteurs à s'inscrire. Dans la plupart des situations typiques, vous pouvez exécuter un processus métier sans collecter de visiteurs PD.

Remplir des formulaires d'inscription fastidieux «avec ou sans» est désagréable. Mais avec le nouveau protocole, il n'est plus nécessaire de trouver un autre identifiant et mot de passe. Seul le bouton Confirmer et me sauver:

Bien sûr, vous devrez d'abord créer une clé permanente pour le site. Mais il s'agit de quelques clics de souris.
Et, bien sûr, il vous sera demandé de confirmer votre téléphone ou votre adresse postale. Mais cela dépend déjà du site.
Après une autorisation réussie, le serveur, via un en-tête HTTP spécial, CSI-Token-Action informera le navigateur qu'il a accepté la nouvelle clé. Plus de détails au chapitre II .

1.6 Comment mettre en place une identification client fiable?

Dans les situations plus graves (compte personnel du fournisseur, hébergement, banque), une authentification à deux facteurs doit et peut être effectuée, et la preuve de la possession du jeton peut être effectuée par le biais d'une pré-inscription et d'une confirmation d'identité par d'autres moyens: par e-mail, SMS ou même en fixant le jeton de l'utilisateur sur papier. (Oui, oui. Les certificats sont enregistrés sur papier, pourquoi pas des jetons).

1.7 Autorisation sur le site vue par l'utilisateur

Le navigateur informe l'utilisateur que le site prend en charge l'autorisation CSI via l'icône de verrouillage dans la barre d'adresse. Si vous effectuez certaines actions sur le site, vous pouvez demander au site de se souvenir de vous. A partir de ce moment, le serveur reconnaîtra l'utilisateur même entre différentes sessions:


Au lieu de fixer la clé, l'utilisateur peut créer une clé permanente pour le site et s'y inscrire. Illustration animée:


Et lorsque l'utilisateur dispose d'une clé permanente pour le site et que cette clé y est enregistrée, le processus de connexion est grandement simplifié:


La plus grande puissance du protocole se manifeste lorsque l'utilisateur crée une clé pour le site en fonction de la clé principale. Dans ce cas, le problème de votre identification sur des sites sur d'autres appareils est facilement résolu . L'animation suivante le démontre. Il est supposé que vous avez déjà distribué votre clé principale une fois entre vos appareils / navigateurs:


Pour les sites avec une autorisation à deux facteurs, la «reconnaissance» peut ressembler à ceci:


La sortie est encore plus facile. Cliquez sur "Déconnexion" dans le navigateur et c'est tout:

Le navigateur envoie une demande au site (sur n'importe quelle page) avec la méthode HEAD, dans laquelle il envoie l'en-tête CSI-Token <>; Déconnexion.

Le serveur, voyant un tel en-tête, se déconnecte. S'il s'agissait d'une clé fixe, le site supprime toutes les informations sur l'utilisateur (plus qu'une telle clé n'apparaîtra jamais). S'il s'agissait d'une clé permanente, interrompt simplement la session.
Toute autre activité du site transforme l'utilisateur en un anonymat inconnu du site: rechargement de la page, tentative de demande ajax, téléchargement d'un fichier, etc. - Le navigateur enverra un jeton généré déjà sur la base d'une clé aléatoire.

Vous pouvez gérer les clés dans le gestionnaire de clés: modifier la clé permanente, exporter la clé permanente dans un fichier, importer à partir d'un fichier à partir d'un autre appareil. Configurez la «sortie automatique» après avoir fermé un onglet ou un navigateur. Définissez la durée d'une clé fixe.

1.8 Comment une clé de site change-t-elle?

Le remplacement de la clé permanente du site revient techniquement à passer d'une clé aléatoire à une clé permanente. Ceci est décrit plus en détail au chapitre II .
En cas de modification de la clé permanente du site, le navigateur notifie au site la modification correspondante du jeton, en envoyant un en - tête CSI-Token avec la clé Changed-To à chaque demande suivante :

Le site doit traiter correctement une telle demande. Et, si un jeton utilisateur donné est stocké dans sa base de données, il doit effectuer un remplacement approprié. Dans le même temps, le site devrait répondre au navigateur au sujet du changement réussi du jeton de son côté. Il le fait dans l'en-tête Response Headers avec le paramètre: CSI-Token-Action: succès , indiquant le jeton appliqué.
Le site a le droit de rejeter une tentative de modification du jeton (par exemple, s'il n'y en avait pas dans sa base de données ou s'il ne les enregistre pas du tout) avec le paramètre CSI-Token-Action: abandonné.
Jusqu'à ce que le navigateur reçoive l'en-tête CSI-Token-Action, il ajoutera la clé Changed-To à chaque demande de jeton CSI du site.
Il s'agit d' un analogue du «changement de mot de passe» de l'utilisateur.

1.9 Comment l’autorisation interdomaines est-elle mise en œuvre?

L'autorisation classique entre domaines utilisant la technologie SSO présente de nombreux avantages pour l'utilisateur. Vous n'avez pas besoin de vous souvenir d'un tas de mots de passe provenant d'un tas de sites. Il n'est pas nécessaire de s'inscrire et de remplir les formulaires mornes. Certains serveurs d'autorisation demandent quels droits accorder au site qui a demandé l'authentification unique.
Mais il y a aussi des inconvénients. Vous dépendez du fournisseur SSO. Si le serveur SSO ne fonctionne pas, vous n'obtiendrez pas le site cible. Si vous perdez votre mot de passe ou votre compte est volé - vous perdez l'accès à tous les sites à la fois.
Pour les développeurs web, les choses sont un peu plus compliquées. Depuis le début, vous devez enregistrer votre site sur le serveur d'autorisation, obtenir les clés, apprendre à travailler avec le protocole ( SAML , OAuth , etc.) et les bibliothèques correspondantes, assurez-vous que la clé n'expire pas, que le serveur d'autorisation ne bloque pas votre site pour vos raisons et etc. Il s'agit d'une redevance pour le fait que vous n'avez pas besoin de conserver des comptes d'utilisateurs, de faire des formulaires d'inscription, de vous connecter, etc. La vérité augmente le coût de la maintenance (sous forme de réparation de pannes soudaines). Encore une fois, si le serveur est soudainement indisponible pour le site, alors hélas.
Ce schéma d'autorisation rend SSO un peu plus sûr et l'autorisation pour tous les participants est plus facile. La sécurité sera discutée ci-dessous dans la section "Compromis clé pour l'authentification unique".

Jetez un œil au site S, qui prend en charge l'authentification unique de Google. Supposons que vous ayez un compte Google. Pour vous connecter, vous cliquez sur le lien "Se connecter avec Google", qui ouvrira l'onglet d'autorisation Google. Le navigateur vous indiquera que vous avez une clé pour Google. Et Google vous dira quels droits S. demande.
Si vous êtes d'accord, cliquez sur "Connexion" dans le gestionnaire de clés. La page se rechargera. Google recevra déjà son jeton valide, vous reconnaîtra et vous autorisera. Et avec une demande inter-serveur, il informera le Site S de vos informations de compte conformément aux champs demandés.
La page rechargée contiendra un bouton «Suivant» qui vous ramènera au site cible.


Le site S peut décider de sauvegarder ou non des données vous concernant dans sa base de données. Cette question dépasse le cadre du régime d'autorisation proposé. Mais en outre, lorsque nous examinerons les risques de perdre la clé pour SSO, le site est recommandé de conserver le jeton et l'identifiant utilisateur de SSO de son côté, et l'utilisateur est recommandé de créer une clé permanente pour S.

Vulnérabilité: Après une telle autorisation, les sites S1, S2, S3, ... (où vous vous êtes connecté via Google) pourront vous reconnaître (par l'identifiant qui vous a été attribué par Google) et, par conséquent, suivre votre activité.

Option de protection: ne fonctionne pas simultanément sur les sites si vous vous êtes inscrit via le SSO du même fournisseur. Si possible, déconnectez-vous du serveur d'autorisation immédiatement après la fin de l'autorisation («sortie automatique» pour le domaine).

1.10 Comment implémenter l'authentification inter-domaines?

Tout cela, bien sûr, est bon. Alors que le travail est effectué sur un seul navigateur - tout va bien. Mais qu'en est-il des réalités modernes lorsqu'une personne a deux téléphones portables, un ordinateur de travail et plusieurs navigateurs dessus, un ordinateur personnel et un autre ordinateur portable? Plus une tablette commune pour la femme / les enfants.
Nous devrons en quelque sorte résoudre le problème du transfert des clés de domaine entre les navigateurs et les appareils. Et aussi résoudre le problème de leur synchronisation correcte.
L'un des mécanismes pour résoudre ce problème consiste à calculer diverses clés de domaine sur la base d'une clé principale commune sans possibilité de récupération inverse de la clé principale à partir d'une clé de domaine connue.
Après avoir créé une clé personnelle K pour le domaine D en utilisant une clé principale M sur un appareil, un utilisateur peut créer la même clé K pour le domaine D et sur n'importe quel autre en utilisant la même clé principale M et un seul algorithme. Plus précisément, cela se fera non pas par l'utilisateur, mais par son navigateur. Avec cette approche, il suffit à l'utilisateur de répartir sa clé principale entre tous les navigateurs utilisés par lui et il "transfère toutes ses clés" de domaines à la fois. Effectue en même temps des sauvegardes de cette manière.
Confort d'utilisation maximal. Mais aussi le risque maximum en cas de compromission de la clé principale. Par conséquent, ces derniers doivent être protégés en conséquence. Les risques de perte ou de compromission de la clé principale et les moyens de minimiser ces risques sont décrits dans le chapitre «3 Recommandations de sécurité» .
L'utilisation d'une seule clé principale pour générer toutes les clés pour tous les domaines n'est pas toujours une option pratique. Premièrement, que faire si la clé de domaine est soudainement compromise et doit être modifiée? Deuxièmement, que faire si vous devez partager une clé de domaine avec une autre personne? Par exemple, entre les membres de la famille. Ou s'agit-il d'un compte d'accès au courrier public d'entreprise. Comment alors "récupérer" votre clé (car en fait elle a été compromise)?
Par conséquent, la génération de clés de domaine individuelles à l'aide d'un capteur biologique de nombres aléatoires doit être prise en charge par les navigateurs. Mais nous revenons ensuite à la question de notre mobilité et des problèmes de synchronisation, des fonctions d'exportation et d'importation de clés dans le navigateur et de création de copies de sauvegarde.

Transfert via un appareil physique aliénable

Les cartes à puce et les jetons USB peuvent être tout à fait appropriés comme stockage sécurisé des informations clés (car ils ont été créés pour cela). L'authentification à deux facteurs protège les clés contre tout accès non autorisé avec un accès direct à l'appareil.
Certes, les cartes à puce nécessitent des lecteurs spéciaux (sans parler des pilotes), ce qui limite leur utilisation uniquement aux postes de travail équipés de tels lecteurs.
Avec des jetons USB un peu plus faciles. Seuls les pilotes sont requis. Mais vous ne pouvez pas coller un tel jeton dans le téléphone. Et bien que pour les téléphones portables il existe des jetons réalisés sous forme de cartes SD, pour ne pas dire que cette solution ajoute à la mobilité. Essayez de tirer une carte d'un téléphone mobile, mais insérez-la dans un autre. Et ce n'est pas que ce soit impossible. Le truc, c'est que ce n'est pas pratique.
Et si le jeton se casse? Ensuite, toutes vos clés iront au Grand Cthulhu.
Il y aura donc une tentation avec un tel schéma d'utiliser plusieurs appareils en double. Mais vous devez encore résoudre le problème de synchronisation des clés si vous avez plusieurs cartes à puce.
Et, franchement, ces appareils ne sont pas protégés contre les enregistreurs de frappe. Maintenant, si le code PIN devait être entré à partir de la carte / du jeton lui-même. Puis autre chose. Mais je n'en ai pas vu dans la nature.

Avantages: des clés aléatoires de 256 bits peuvent être utilisées; haute sécurité grâce à l'utilisation d'une authentification à deux facteurs; le plus haut niveau de protection contre la falsification directe.
Inconvénients: dépendance de l'appareil; nécessite des coûts financiers; faible mobilité; la nécessité de réserver des cartes et, par conséquent, de synchroniser les données entre elles; la vulnérabilité aux enregistreurs de frappe demeure.

Synchronisation via le service en ligne

La «technologie du cloud» est désormais mise en avant dans la mesure du possible. Il semble qu'ils, avec la blockchain, soient devenus un substitut à la «technologie de la banane». Naturellement, on souhaite utiliser une certaine plate-forme Internet pour l'échange d'informations clés. Une sorte de carte à puce "en ligne".
Quoi? Vous vous connectez en utilisant notre système de manière anonyme sur un tel site; envoyez-y vos clés cryptées avec un mot de passe; Vous passez d'un autre appareil au même site avec la même clé / mot de passe; vous obtenez les clés de là; Vous synchronisez les modifications par date de modification. Semblable au gestionnaire de mots de passe, seul celui-ci est en ligne.
C'est juste, personne ne garantit que le service en ligne ne sera pas piraté ou ne fusionnera pas vos clés, bien que cryptées, «si nécessaire». Qui mettra en place un tel service gratuitement. Voilà.
Bien sûr, le mot de passe protège les clés contre une utilisation directe. Mais votre mot de passe résiste-t-il à la force brute "hors ligne"? Voilà une autre question.

Avantages: haute mobilité des diplômes; indépendance de l'appareil et du navigateur; vous n'avez besoin que d'un seul mot de passe (bien qu'ils n'aient pas laissé le mot de passe, c'est déjà mieux).
Inconvénients: moins sûr que de stocker des clés sur un support aliénable. En fait, la sécurité des clés repose sur la force du mot de passe à sélectionner.

Vous pouvez bien sûr utiliser une clé principale pour crypter d'autres clés. Celui avec lequel les autres clés de domaine sont calculées. En option.

2 Description technique du protocole

2.0 Algorithme de génération de clés de domaine

Ce protocole définit seulement 2 méthodes pour générer des clés de domaine.

• basé sur un générateur de nombres aléatoires (de préférence biologique)
• basé sur une clé principale de 256 bits

Dans ce dernier cas, la clé de domaine est calculée comme suit:

$$

où $$ - Clé maître 256 bits, Domaine - nom de domaine pour lequel la clé est créée.
Ci-après, HMAC est un algorithme cryptographique de hachage basé sur une implémentation de 256 bits de la fonction de hachage SHA-2 .

La divulgation de compromis ou volontaire d'une clé de domaine ne compromet pas la clé principale d'origine.

La clé principale fournit un mécanisme pour la mobilité des informations d'identification de l'utilisateur.

Si la clé créée sur la base du «maître» a été compromise ou si le jeton calculé à partir d'une telle clé (à la suite d'un piratage du site) a été compromis, la clé doit être modifiée. Vous pouvez la changer en une clé aléatoire de 256 bits, ou la générer à partir du même «assistant», avec l'ajout d'une version:

$$

Ci-après, le symbole $$ sera utilisé pour l'opération de concaténation de chaînes (tableaux d'octets).

2.1 l'algorithme de calcul du jeton source

Le jeton d'authentification de l'utilisateur est calculé avec chaque demande de n'importe quelle ressource de domaine. Pour calculer le jeton de demande, les données suivantes sont prises:

• Expéditeur - le nom de domaine de l'initiateur de la demande (il peut s'agir d'une page avec une iframe ou un script du domaine de quelqu'un d'autre qui effectue la récupération),
• Destinataire - nom de domaine du destinataire (où la demande est envoyée),
• Contexte - contexte d'exécution de la demande,
• Protection - une séquence aléatoire de 32 octets (256 bits), si le contexte est vide; sinon vide

Ces données sont concaténées et hachées avec SHA-2 256 bits sur la clé K du domaine initiant la requête :

$$

Un jeton valide est obtenu lorsque le contexte n'est pas vide. Pour une identification correcte sur le site cible, la condition Sender = Recipient = Context doit être remplie.

Le champ Contexte, avec Protection, est utilisé pour se protéger contre les attaques XSS et CSRF , ainsi que contre le suivi des utilisateurs.
Des explications plus détaillées sur les règles de détermination de l'expéditeur / destinataire / contexte seront fournies ci-dessous.

2.2 Algorithme de protection des jetons pendant le transfert

Le jeton client d'origine est transmis extrêmement rarement. Uniquement lors du transfert d'un jeton non enregistré au moment de la création de la session.
Un jeton est considéré comme non enregistré s'il: est créé sur la base d'une clé aléatoire (non fixe); n'a pas été accepté par le serveur après l'envoi de la clé de remplacement ou permanente. Pour plus de détails, voir «Traitement des jetons sur le serveur» .
Le navigateur et le serveur génèrent conjointement une paire de nombres aléatoires, appelés salt (Salt), avec lequel les 128 bits inférieurs du jeton sont hachés. Les deux échangent ces numéros selon le protocole. Pour plus de détails, voir «Salt Swap Procedure Browser-Server» .
Ainsi, le serveur de site voit le jeton suivant:

$$

où $$ - haute 128 bits, $$ - les 128 bits inférieurs du jeton d'origine, $$ - concaténation de chaînes. Dans ce cas, le jeton initial $$ devrait déjà être connu du serveur.

Idéalement, CSI-Salt devrait changer chaque fois qu'un navigateur demande un serveur. Cependant, cela peut être une exigence coûteuse en termes de ressources informatiques. De plus, il peut «tuer» la possibilité d'envoyer des requêtes parallèles au serveur.
Par conséquent, afin d'optimiser les calculs, il est autorisé de conserver les valeurs CSI-Salt inchangées dans différentes demandes, mais pas plus d'une session . Cela peut être une limite de temps (changement de CSI-Salt toutes les 5 minutes), ou une réaction à l'intensité des requêtes (changement de CSI-Salt toutes les 100 requêtes), ou après chaque série de requêtes (au moment de la pause, client-serveur), ou une version mixte. Ici, la décision est laissée aux développeurs de navigateurs.
Garder CSI-Salt inchangé trop longtemps affaiblit la protection du jeton transmis, permettant à l'attaquant d'intercepter le jeton pendant que l'utilisateur légitime a terminé la déconnexion et d'exécuter une demande non autorisée au nom de la victime.

2.3 Procédure d'échange de sel entre le navigateur et le serveur

2.3.1 Jeton basé sur une clé de serveur aléatoire ou non enregistrée ^[1] .

2.3.2 Jeton basé sur la clé enregistrée par le serveur ^[1] .

---

^{[1] Un jeton est considéré comme non enregistré s'il: est créé sur la base d'une clé aléatoire; n'a pas été accepté par le serveur après l'envoi de la clé de modification ou permanente avec la réponse CSI-Token-Action: succès.
[2] Le temps pendant lequel le changement CSI-Salt est effectué est déterminé par les navigateurs eux-mêmes. Cela peut se produire après une série de demandes, après un délai d'attente, après un certain nombre de demandes. – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

Nous appellerons le nôtre le domaine dont nous chargeons la page (affichée dans la barre d'adresse du navigateur). Les domaines restants seront appelés externes . Même si ce sont des domaines enfants d'un donné.

Nous appelons la ressource externe si elle a été téléchargée à partir d'un domaine externe. Nous appellerons la ressource interne si elle a été téléchargée depuis notre domaine. La ressource peut être un script, une image, une requête ajax et tout autre fichier.

Un script est considéré comme externe s'il a été téléchargé à partir d'un domaine externe. Le script placé dans la balise <script> créée, créé par un script externe, sera également considéré comme externe. Le script situé dans la balise <script> modifiée est déclaré externe s'il a été modifié par un script externe, ou si un script externe était présent dans la chaîne d'appel lorsque son contenu a changé. Même si en même temps ce <script> était à l'origine sur la page ou a été créé par un script interne.

Nous nommerons les balises LINK, SCRIPT, IMG, IFAME et autres, qui nécessitent que le navigateur charge une ressource dès qu'elle est rencontrée par l'analyseur DOM - balises de ressource .

Nous nommerons les balises FORM, A, META et autres, qui peuvent lancer le chargement des pages sous certaines conditions (soumettre, cliquer,timeout) - lancement de balises.

Nous appellerons la balise statique si elle était à l'origine présente sur la page lors de sa première émission par le serveur. Nous appellerons la balise dynamique si elle a été créée lors de l'exécution des scripts.

La balise FORM est déclarée dynamique, même si non seulement la balise elle-même a changé, mais aussi les valeurs de tous les champs INPUT associés à ce formulaire.

Nous appellerons notre propre balise dynamique si le script qui l'a créée appartient à notre domaine, et la chaîne d'appel de l'instruction qui a généré cette balise n'avait pas de fonction appartenant à un script externe. Sinon, nous considérons une telle balise dynamique incorrecte .

Le chargement de la page est déclenché par le lancement de balises.La balise initiatrice peut être activée directement par l'utilisateur, ou activée par le script, en exécutant la commande click (pour le lien) et soumettre (pour le formulaire), ou par le script générant les événements onclick / onsubmit correspondants.

De plus, la balise initiatrice peut être activée par le navigateur. Un exemple d'une telle balise est META avec les paramètres http-equiv = "refresh" content = "0".

^{Tableau P. Valeurs de contexte dans différentes conditions d'ouverture de page}


Si la balise de ressource a été modifiée par un script (par exemple, l'attribut SRC d'IMG), puis que la ressource a été automatiquement chargée par le navigateur, nous pensons que le contenu / la ressource a été déclenché par l'analyseur, la méthode de chargement est la balise, mais le statut de cette balise devient «dynamique».

^{Tableau R. Valeurs de contexte dans différentes conditions de chargement de contenu / ressource}

---

^{[1] Balise de lancement
[2] Balise de ressource
[3] Hériter de ses propres pages, vide lors de l'ouverture de pages de domaines étrangers
[4] Hériter lors de la redirection de serveurs vers leurs pages, vide lors de la redirection vers d'autres domaines ou lors de l'ouverture d'une page à partir de sources externes (voir . clarification )}


Des marques de la forme P1..PF, R1..RC seront utilisées pour faire référence à la cellule correspondante dans le tableau lors de l'analyse de situations spécifiques.

Remarquez le référent et le domaine en surbrillance dans le premier tableau. Vous ne pouvez être autorisé sur un site que lorsque vous ouvrez vous-même le site à une adresse directe ou par un lien à partir d'un autre site, avec un rechargement ultérieur de la page de votre propre initiative.

2.5 Règles de définition des champs expéditeur et destinataire

L'expéditeur est le domaine de la page / du script / du style d'où provient la demande. La page demande des styles, des images, des scripts. Les scripts demandent du contenu via ajax. Les styles peuvent charger d'autres styles. Ce sont les initiateurs de la demande.

Le destinataire est le domaine auquel la demande va vraiment.

Pour qu'il n'y ait plus de questions, considérons des exemples spécifiques.

Qu'il y ait un site site.net. Sur la page principale du site:

• style site.net/css/common.css
• les styles common.css importent les styles fonts.google.com/fonts/Roboto.css
• Le style Roboto.css importe la police fonts.google.com/fonts/Roboto.ttf
• image menant à img.site.net/picture1.jpg
• trame chargée depuis adriver.ru/frame
• script de adm.site.net/admin.js

Laissez dans le cadre (avec adriver.ru) vous connecter:

• style de adriver.ru/style.css
• image de img.adriver.ru/img/01.png
• script de adriver.ru/libs.js
• script de api.adriver.ru/v1/ad.js

Valeurs de l'expéditeur / destinataire lors du chargement des ressources avec l'analyseur DOM

Maintenant, regardons les valeurs de Sender / Recipient lors du chargement de contenu avec des scripts lors de l'exécution des requêtes ajax.

Valeurs de l'expéditeur / destinataire lors du chargement de contenu avec des scripts

2.6 Détails sur les tables de définition de contexte

Examinons plus en détail les options d'ouverture de pages (onglets du navigateur) dont nous disposons et la valeur de contexte qui sera obtenue.

P1 - l'utilisateur de la page précédente a cliqué sur le lien ou cliquez sur le bouton soumettre du formulaire. Le gestionnaire de navigateur d'événements standard pour le lien / formulaire a redirigé l'utilisateur vers cette page. Situation normale. Transition sécurisée entre les pages d'un domaine ou différents domaines.

Lorsque vous passez à site.net à partir d'un autre domaine google.com, le contexte sera égal au domaine précédent (google.com). Et l'utilisateur sur le nouveau domaine site.net ne sera pas autorisé (même si l'onglet voisin de ce site où l'utilisateur est autorisé est ouvert).

Une transition indépendante répétée de l'utilisateur (sans l'aide de scripts) via le lien vers le même site conduira à nouveau à la situation P1 , mais le contexte sera déjà égal au domaine site.net, car par la règle Context = Referrer.

Il est fait pour protéger contreAttaque CSRF .

P5 - l'utilisateur de la page précédente a cliqué sur le lien créé / modifié par un script téléchargé depuis le domaine de la page précédente; ou l'utilisateur de la page précédente a cliqué sur le bouton d'envoi du formulaire créé / modifié par le script (en changeant la balise FORM, y compris ses champs INPUT). Le gestionnaire de navigateur d'événements standard pour le lien / formulaire a redirigé l'utilisateur vers cette page.

P9 est identique à P5 , seul le script était externe, ou il existe une fonction d'un script externe dans la chaîne d'appel (protection contre la modification des fonctions de script du script de site par un script tiers).

PD - l'utilisateur a ouvert la page à une adresse directe. Ouverture sûre.

L'utilisateur doit ouvrir la page en entrant l'URL dans la barre d'adresse. Ou ouvrez un site à partir des signets du navigateur.

L'ouverture d'un lien à partir d'un raccourci sur le bureau d'un autre programme, toute autre situation où le système d'exploitation envoie une commande au navigateur pour ouvrir le lien doit être considérée comme un cas PG (l'ouverture du lien est initiée par le navigateur). Même si l'utilisateur appuie sur F5 pour recharger la page, cela doit être considéré comme un cas PG . Ce n'est que si l'utilisateur entre dans la barre d'adresse et appuie sur Entrée que le navigateur sera considéré comme un PD .

Ceci est fait pour protéger les attaques CSRF contre d'autres programmes.

Le fait de suivre le lien d'un autre programme mènera l'utilisateur vers le site attaqué avec un jeton invalide et un contexte vide, qui seront enregistrés même si l'utilisateur appuie sur F5 (actualiser la page). Vous ne pouvez pas vous connecter tant que l'utilisateur n'a ouvert aucun lien vers les pages du site (situation P1 ).

Ainsi, si un attaquant d'un autre programme décide de faire glisser à un utilisateur autorisé un lien vers la page du site site.net qui exécute une commande, il ne pourra pas le faire facilement. Il faudra forcer l'utilisateur à cliquer sur un autre lien sur cette page, puis forcer l'utilisateur à s'y authentifier, et alors seulement ... Ensuite, l'utilisateur sera très probablement sur une autre page de site.net.

P2 - sur la page précédente pour un lien ou un formulaire placé à l'origine sur la page, un script natif de la page précédente a généré un événement click / submit. Aucune fonction de la chaîne d'appels n'appartenait à des scripts externes. Le navigateur a redirigé l'utilisateur vers cette page.

Si la nouvelle page appartient au même domaine, le contexte est hérité de la page précédente. Si la nouvelle page appartient à un domaine étranger, le contexte sera vide.

P6 est le même que P2 , seul le lien / formulaire a été créé / modifié par son propre script.

PA est le même que P2 , seul le lien / formulaire a été créé / modifié par un script externe.

PE - le script de la page précédente a provoqué l'ouverture de cette page avec la commande window.location.href ou window.open (...).

Si le script de page site.net redirige l'utilisateur vers la page du même domaine, le champ Contexte sera hérité de la page de génération. Dans ce cas, Context = site.net.

Si la page ya.ru a été ouverte et que le script nous a transférés sur maps.ya.ru, le contexte de la nouvelle page sera déjà vide. Dans les actions ultérieures de l'utilisateur, le contexte restera presque toujours vide, ce qui compliquera l'autorisation de l'utilisateur sur le site.

Le protocole implique que l'ouverture d'un site sur un autre est une opération dangereuse. Cela protège l'utilisateur contre le suivi non autorisé par ces sites et contre les attaques CSRF.

P3 - similaire à P2 , seul l'événement click / submit a été déclenché par un script externe. Le contexte devient vide (une séquence aléatoire d'octets est envoyée à la place), ce qui protège les sites tiers du suivi du site (réseaux de bannières).

P7 - similaire à P6 , seul le lien / formulaire a été créé / modifié par un script externe.

PB - similaire à PA , seul le lien / formulaire a été créé / modifié par un script externe.

PF - similaire à PE , seul le script provocateur était externe.

P4 - le navigateur a rechargé la page suite au traitement de la balise <META>. La balise était à l'origine sur la page. Redirection légale. Le contexte persistera à partir de la page d'origine. Comme c'est le cas avec PE .

P8 - le navigateur a rechargé la page suite au traitement de la balise <META>. Mais la balise a été créée / modifiée par son propre script. Ceci est valide, mais le contexte persistera à partir de la page d'origine. Comme c'est le cas avec PE . Il ne sera pas possible d'attirer le jeton légal de l'utilisateur de cette manière.

PC - similaire à P8 , seul script externe. Le site ouvert recevra un nombre aléatoire comme contexte.

PG - le navigateur ouvre des liens sur commande à partir du système d'exploitation. Il se peut que vous cliquiez sur un lien d'un autre programme, ouvriez un raccourci sur le bureau. Il peut s'agir d'une commande d'un autre programme, à votre insu. Dans ce cas, la source n'est pas approuvée et le champ Contexte restera vide lors de toute manipulation utilisateur.

Ceci est fait pour protéger les attaques CSRF contre d'autres programmes.

Si le navigateur lui-même ouvre les onglets précédemment enregistrés, le contexte de la page est défini égal à la valeur de cette page au moment de la fermeture du navigateur.

De plus, cette catégorie comprend toutes les situations où le navigateur est redirigé par le serveur vers une autre page (de son propre domaine ou de quelqu'un d'autre) suite au traitement de l'en-tête HTTP Header. Si la redirection va vers votre propre page, la valeur de contexte est héritée. Si la redirection va à quelqu'un d'autre, elle est réinitialisée.

Ceci est fait pour protéger contre le suivi des attaques des serveurs Web.

Soit dit en passant, une telle règle peut entraîner des problèmes avec la mise en œuvre actuelle de l'autorisation interdomaine. Si après autorisation, le serveur SSO redirige l'utilisateur vers le site cible, ce dernier y sera anonyme.

Pour éviter à l'utilisateur de «perdre» l'autorisation d'origine sur le site cible, il est nécessaire de transmettre des informations d'authentification entre les requêtes du serveur. L'algorithme peut être le suivant:

1. l'utilisateur crée et active une clé permanente pour le site cible;
2. Passe du site cible au serveur SSO lui-même en cliquant sur le lien approprié;
3. active la clé permanente existante à partir du serveur SSO;
4. Après avoir reçu la clé Changed-To, le serveur SSO envoie une requête inter-serveur au site cible;
5. l'utilisateur clique sur le bouton «Continuer» de la page d'autorisation, ce qui le renvoie au site cible;
6. afin de respecter la règle P1 , le site cible propose à l'utilisateur de cliquer à nouveau sur le bouton de lien pour y accéder (par exemple, vers la page d'accueil d'un participant autorisé).
7. l'utilisateur clique sur le bouton de lien, la page se recharge et l'utilisateur est déjà autorisé sur le site cible.

La description de l'algorithme semble en fait plus compliquée que sa mise en œuvre. Une implémentation de l'interface utilisateur pourrait ressembler à ceci:

Une nouvelle entrée sur le site cible ne nécessite plus l'autorisation SSO de l'utilisateur. Il suffit d'activer la clé permanente.

Examinons maintenant de plus près les options de chargement de contenu sur les pages et la valeur de contexte qui sera obtenue sur demande.

R1 - la ressource est chargée par le navigateur suite à l'analyse de la page (le navigateur a rencontré une balise de ressource). La valeur de contexte lors de la génération d'une demande de ressource est extraite de la page Contexte contenant la balise de ressource.

Par exemple, si site.net a un cadre adriver.ru dans lequel l'image de img.disk.com est chargée, puis lors de la génération d'une requête HTTP vers img.disk.com, le navigateur prend la valeur calculée pour la page comme contexte site.net.

R4 est identique à R1 . Seule la balise de ressource a été créée / modifiée par son propre script, à la suite de quoi le navigateur DOM Parser a fonctionné. Par exemple, sur la page site.net/index.html, notre propre script site.net/require.js a inséré un autre script personnalisé (<script src = ...> tag) site.net/min.js, ce qui a forcé le navigateur à générer une demande de téléchargement de fichier main.js. Le champ Contexte de cette demande sera défini sur la valeur calculée pour la page site.net.

R7 est identique à R1 . Mais comme la balise de ressource a été créée / modifiée par un script externe, lorsque la ressource est demandée, le navigateur générera un jeton basé sur un contexte vide et une séquence aléatoire de 256 bits. En conséquence, le script de l'attaquant externe evil.com/drop.js, intégré à la page du domaine site.net attaqué, essayant de répondre à une demande adressée au site.net cible au nom de la victime échouera, car le serveur recevra une demande avec un jeton aléatoire et ne pourra pas identifier l'expéditeur de la demande.

RA - l'analyseur télécharge le contenu suite à l'analyse d'un autre contenu Par exemple, la feuille de style site.net/css/common.css, téléchargée pour la page site.net/index.html, importe la feuille de style fonts.google.com/fonts/Roboto.css, ce qui oblige le navigateur à demander fonts.google .com au nom de Referrer = site.net/css/common.css. La valeur de contexte dans ce cas sera égale à Referrer. Ensuite, le fichier de styles Roboto.css importe la police Roboto.ttf, ce qui oblige le navigateur à demander fonts.google.com/fonts/Roboto.ttf au nom de Referrer = fonts.google.com/fonts/Roboto.css. La valeur de contexte sera égale à Referrer dans ce cas, mais elle est différente.

Supposons, hypothétiquement, que le fichier Roboto.css (ressource externe) n'importe pas de police / style, mais essaie de mener une attaque CSRF avec cette instruction:

@import "https://site.net/api/payment?victim_params" 

dans l'espoir de répondre à la demande sur site.net au nom d'un utilisateur autorisé. Mais le problème pour l'attaquant est que site.net s'attend à recevoir un jeton de l'utilisateur:

$$

Ensuite, comme avec une telle demande CSRF, le navigateur créera un jeton:

$$

Et une demande adressée au site viendra de la part d'un site anonyme qui ne dispose pas de droits d'accès pour effectuer ces opérations.

RB - le contenu est téléchargé par le propre script du site. Dans ce cas, Context est utilisé pour calculer le jeton de demande, qui est égal à la page contenant le script. Pour le script site.net/1.js de la page Contexte site.net, il sera égal au contexte de la page elle-même.

Notez que le contexte de la page elle-même n'est pas toujours égal au nom de domaine de la page et dépend de la façon dont elle a été ouverte à l'origine.

Supposons que le site de l'attaquant evil.com ouvre la page du site attaqué site.net, où le script site.net/util.js exécute une requête avec les paramètres transmis via l'URL de la page. L'attaquant espère, en glissant «ses paramètres» via l'URL, forcer son propre script site.net/util.js à exécuter une requête ajax pour effectuer des actions importantes au nom de la victime.

Supposons que l'utilisateur lui-même soit allé sur evil.com via un lien direct. Le contexte de evil.com sera alors evil.com. De plus evil.com ouvre le script site.net/api/payment?victim_params avec un script , dans l'espoir de mener une attaque, mais le champ Contexte de site.net sera vide (cas PE / PF). Le script site.net/utils.js, exécutant une requête ajax, forcera le navigateur à prendre Context depuis la page site.net. Et c'est vide chez nous. Mais alors site.net recevra une demande ajax avec ce jeton:

$$

alors que pour un utilisateur autorisé, il est prévu:

$$

site.net verra un jeton inconnu et ne pourra pas identifier l'utilisateur. La protection a fonctionné.

Soit dit en passant, à cause d'un tel schéma, la réalisation d'une autorisation interdomaine via des fenêtres contextuelles sera irréaliste.

Pour implémenter l'authentification unique sous le protocole, vous devez ouvrir un nouvel onglet pour la page du serveur d'autorisation. Et en même temps, l'utilisateur doit ouvrir un tel onglet. La meilleure option est d'ouvrir à l'utilisateur le lien approprié depuis le site cible.

RC - le contenu est chargé avec un script de site Web externe. Dans ce cas, Context est utilisé pour calculer le jeton de demande, qui est égal au champ Request Referrer.

Malgré le fait que RA , RB et RC protègent contre les attaques CSRF, ils conduisent néanmoins à la génération de jetons constants. Et cela vous permet d'implémenter l'authentification interdomaine et l' authentification utilisateur interdomaine (lorsque vous devez déterminer que plusieurs demandes adressées à différents serveurs provenaient de cet utilisateur). Ce qui peut être mis en œuvre pour lui donner une autorité égale sur un groupe de domaines connexes.

Si la page du site a été ouverte automatiquement à partir d'un autre site, vous ne pourrez pas vous y connecter, même si vous rechargez ce site vous-même. Parce que Source héritera d'une valeur nulle. Le navigateur doit signaler à l'utilisateur ce fait (Source = aléatoire):

Ceci est fait pour se protéger contre les sites qui forcent d'autres fenêtres contextuelles à s'ouvrir (elles-mêmes ou leurs scripts externes), et sur les sites qui s'ouvrent, ils redémarreront ou créeront de faux boutons de fermeture sur tout l'écran menant aux mêmes sites. C'est-à-dire cela empêche une tentative de suivi, dans l'espoir d'obtenir un jeton valide.

Toute tentative par le site d'imiter vos actions avec un script externe , ou une tentative par un script externe de créer directement ou indirectement une balise initiatrice et de vous la glisser, conduira à une source vide et à l'ajout d'octets aléatoires au moment du calcul du hachage de jeton.

L'astuce pour créer ou modifier la balise <script> dans la page attaquée dans le DOM n'aidera pas. Le champ Source restera vide.

Mais dans les mêmes conditions, les scripts internes conduiront à des requêtes avec Source égale à sa valeur précédente. Et si la page d'origine avait Source = Domain, tout irait bien. L'utilisateur restera autorisé pour de telles demandes.

Mais avec des scripts téléchargés à partir de ressources tierces (CDN), des problèmes peuvent survenir dans certains cas. Et c'est vrai, car L'intégrité du code CDN n'est pas garantie. Si vous ne voulez pas perdre l'autorisation de l'utilisateur, conservez les scripts sur votre site et téléchargez-les depuis votre domaine. Cela ressemble à l'interdiction d'utiliser des liens http sur les pages https.

Nous décrivons la situation dans laquelle un développeur peut tomber. À la suite des actions de l'utilisateur, votre script redirige un utilisateur autorisé vers l'une des pages du site (par exemple, cela se fait par un formulaire), ce qui nécessite que l'utilisateur reste autorisé. Votre script appelle, par exemple, $ (form) .submit () à l'aide d'un script jQuery chargé à partir du CDN. Dans ce cas, le navigateur voit que dans la pile d'appels qui a déclenché l'événement d'envoi du formulaire, il existe une fonction d'un script externe. Pour empêcher les attaques XSS / CSRF , le navigateur rend le champ Source vide et ajoute des octets aléatoires à la génération du jeton (cas P9 ). En conséquence, l'utilisateur sur la nouvelle page devient soudainement non autorisé et ne peut pas terminer l'opération. Cela peut être déroutant pour les développeurs habitués à utiliser les CDN.

2.7 Scénarios de protocole

Voici les principaux scénarios probables de l'utilisateur travaillant avec le site, affectant toutes les situations possibles et les étapes de leur mise en œuvre (connexion anonyme, «se souvenir de moi», «oublie-moi», passer à l'utilisation d'une clé permanente, autorisation et sortie, enregistrement et authentification à deux facteurs, exportation / importation de clés, remplacement de clés, etc.)

Un exemple de configuration d'accès aux jetons basé sur le fichier .htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 chat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1 Algorithme de calcul des jetons utilisateur possibles d'un site à l'aide d'une clé connue

Si nous connaissons la clé de domaine K, nous pouvons facilement calculer le jeton T "valide" possible de l'utilisateur qui viendra avec ses demandes. Pour cela, il faut que la condition soit remplie: l'initiateur des requêtes, le destinataire des requêtes et le contexte d'exécution doivent correspondre et être égaux au domaine. En d'autres termes, si nous avons le nom de domaine vsphere.local, alors:

 Sender = Recipient = Context = vsphere.local 

À partir de là, le jeton d'origine (brut) est calculé comme suit:

$$

Lors de la transmission, le jeton d'origine sera davantage protégé. Les 128 bits inférieurs du jeton seront hachés avec le sel passé dans l'en-tête de demande CSI-Salt ^* . Ainsi, le site verra le jeton suivant:

$$

Où Hi correspond aux 128 bits supérieurs, Lo correspond aux 128 bits inférieurs du jeton d'origine.
Habituellement, pour les consoles de gestion fermées sur un réseau d'entreprise, les consoles Web ne chargent pas de scripts, de cadres, etc. externes. Par conséquent, cette condition sera remplie dans la plupart des cas.

---

^{* Pour la méthode de formation du sel, voir la section «Procédure d'échange de sel entre le navigateur et le serveur».}

2.8 Traitement des jetons sur le serveur

Envoi d'un token au serveur (sans clés)

Permanent

Le navigateur verrouille la clé client. L'utilisateur souhaite que le site se souvienne du client pendant plusieurs sessions. Le stockage du jeton utilisateur dans sa base de données est la décision du serveur. Nous renvoyons CSI-Token-Action: succès ou CSI-Token-Action: abandon au client.

Envoi d'un jeton avec une clé de déconnexion

Indique que le jeton actuel ne sera plus utilisé par le navigateur. Envoyé lorsque l'utilisateur clique sur "Quitter" dans le navigateur, ou ferme l'onglet et l'option est configurée (sortie automatique lorsque l'onglet est fermé), ou refuse d'utiliser une clé fixe ("oublie-moi sur ce site").

Soit dit en passant, l'autologin ne devrait pas l'être. Pour des raisons de sécurité.

Envoi d'un jeton avec une clé de modification

Appelons l'ancien jeton T, le nouveau - T '.

IMPORTANT: en tant que nouveau jeton T ', la valeur réelle du jeton est envoyée (pour la première fois, pour les non enregistrés), tandis que l'ancien jeton est envoyé haché (les 128 bits inférieurs).

---

^{* , .}

2.9 -

Comme mentionné précédemment, les sites peuvent interagir avec d'autres sites partenaires ou leurs sous-domaines pour fournir à l'utilisateur certaines des fonctionnalités. L'exemple le plus courant est lorsque sur le site site.ru certaines des ressources sont chargées à partir des sous-domaines img.site.ru, une partie de download.site.ru et une autre partie d'autres.

Dans ce cas, le site site.ru doit pouvoir informer ses domaines partenaires dont les demandes lui parviennent exactement. En effet, si vous êtes autorisé sur site.ru, cela ne vous rend pas automatiquement autorisé sur d'autres sites, y compris les sous-domaines du site. Ils verront d'autres jetons de votre part.

Voyons comment le jeton est calculé et comment cela peut nous aider.
Laissez l'utilisateur se connecter à site.ru avec une clé permanente et y avoir un jeton:

$$

Toutes les demandes provenant de la page du site site.ru vers le domaine site.ru et causées par:

• balises de ressource de page (dynamique statique ou native)
• propres scripts

aura un jeton T ₁ (voir règles R1 , R4 , RB ). Ce sont des demandes légitimes à site.ru.

Maintenant, laissez le client télécharger le fichier restreint à partir de la page site.ru, mais le lien mène à download.site.ru. Dans ce cas, le sous-domaine recevra le jeton suivant (règles R1 , R4 ):

$$

Exactement le même jeton download.site.ru recevra si une demande ajax de la page du site site.ru est exécutée dessus (règles RB , RC ).

Un autre domaine de domaine recevra un jeton:

$$

Mais, notez que si les conditions pour répondre aux demandes ne changent pas, alors pour un ensemble donné de domaines A, B, C, le navigateur générera toujours un jeton constant. Nous pouvons donc effectuer une identification interdomaines. Par exemple, comme ça.

Depuis site.ru, nous faisons des demandes ajax pour les sous-domaines. Nous passons l'identifiant ID! = T _{1 de l'} utilisateur, qui lui est délivré par site.ru. Les sous-domaines recevront des jetons T _x pour le même utilisateur . Chacun des sous-domaines fera un tas de son jeton avec l'ID utilisateur. Les sous-domaines partageront déjà des informations sur l'ID utilisateur et ses droits avec les demandes de serveur à serveur.

Le bouquet est fait une fois. Par la suite, les sous-domaines seront guidés par leurs propres jetons, comme ils seront également permanents pour la clé permanente site.ru.

3 Recommandations de sécurité

3.1 Protection des informations clés contre les accès non autorisés

Le protocole d'autorisation proposé protège l'utilisateur contre les enregistreurs de frappe qui volent vos mots de passe, car le schéma proposé n'utilise aucun mot de passe.

Mais les moyens de protéger les clés contre les compromis doivent être examinés plus en détail.

Les clés peuvent être compromises par:

• copie des informations clés par un logiciel malveillant (accès à distance)
• accès direct au fichier avec les informations clés "hors ligne" (accès direct)
• au moment de la distribution entre les appareils

En supposant que les informations clés sont stockées sur une carte à puce (nous avons considéré cette option dans la section «Mobilité du compte» ), la tâche de protection des informations clés est transférée sur la puce. Certes, il existe une vulnérabilité aux enregistreurs de frappe qui peuvent intercepter le code PIN saisi; Eh bien, désagrément à utiliser.

En plus des cartes à puce, le cryptage symétrique peut être utilisé pour se protéger contre l'accès direct aux informations clés. Mais la question est: quelle clé prendre pour le chiffrement?

Si cette clé est générée sur la base du mot de passe de l'utilisateur, alors, d'une part, nous obtenons une vulnérabilité à la sélection du mot de passe «hors ligne», et d'autre part, en fait, de ce qu'ils ont laissé, ils en sont venus à: «encore une fois, certains mots de passe».

Une option plus correcte consiste à coudre d'une manière spéciale ^*une telle clé dans l'assemblage du navigateur (ou l'une de ses bibliothèques spécialisées). Chaque mise à jour du navigateur modifie à la fois la clé et son emplacement dans le fichier compilé. Cette approche ne donnera pas une garantie de protection à 100%, mais compliquera sérieusement la tâche de décryptage. Tout d'abord, l'attaquant devra trouver la version exacte de l'assemblage, puis la trouver, la démonter et découvrir comment la clé est assemblée.

De plus, les clés de domaine elles-mêmes doivent être directement stockées dans un fichier séparé, et non avec la configuration pour leur utilisation (c'est-à-dire uniquement les clés et rien de plus). Ensuite, leur déchiffrement par sélection de clé (à partir d'assemblages connus) sera impossible, car il est impossible de distinguer une clé correctement déchiffrée d'une séquence aléatoire d'octets. Ensuite, les tentatives de récupération d'une clé principale sans connaître la version exacte de l'assemblage du navigateur et le démontage direct de son code deviendront impossible.

Vous pouvez utiliser l'option combinée: cryptage avec la clé du navigateur + cryptage avec le mot de passe utilisateur du compte OS (si l'API OS le permet). De plus, la clé est toujours générée à la volée. La force brute hors ligne deviendra alors encore plus chère.

De plus, après avoir changé le mot de passe utilisateur dans le système d'exploitation, la clé changera également. Et si vous ne pré-décryptez pas sur l'ancienne clé, cela vous protégera contre les situations où l'administrateur de l'ordinateur change votre mot de passe afin d'accéder à votre compte et d'effectuer des actions en votre nom. Situations du type: quitter son emploi.

Vous allez d'abord faire une copie de sauvegarde des clés (exporter les clés dans un fichier). Sauf si, bien sûr, vous l'avez déjà fait lors de la distribution de clés à d'autres appareils.

---

^{* Par exemple, une clé de 32 octets est distribuée de manière aléatoire dans la section 64 Ko d'un fichier exécutable. Et seul le code source sait comment récupérer la clé précieuse de ces octets.}

3.2 À propos des mots de passe en tant que clés de domaine

Dans l'une des versions initiales du protocole, la clé de domaine pouvait être générée en fonction du mot de passe de l'utilisateur. L'algorithme était délicat, à l'exclusion des clés en double pour différents domaines pour le même mot de passe.

Cela a été positionné comme un moyen pratique d'accéder aux comptes de mobilité. Saisie d'un mot de passe et ne vous inquiétez de rien. Mais il s'est avéré ce qui suit:

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . C'est-à-dire ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . C'est-à-dire ( SHA-2).
4. , , , . .

3.3 /

Et si je perds la clé principale?

Cela peut se produire si vous modifiez votre mot de passe ou réinstallez le système d'exploitation. Quels sont les risques?

Eh bien, vous n'irez pas sur les sites où vous étiez auparavant. Perdez votre historique d'achat sur les boutiques en ligne, vos annonces sur les sites en ligne, le karma sur les forums. Peu importe.

Mais qui empêche de refaire la procédure d'enregistrement avec un nouveau token et de le confirmer via le numéro de téléphone indiqué dans la même annonce? Il s'avère que le site doit faire une forme de ré-enregistrement du token (un analogue de "récupération de mot de passe")? Où est l'absence promise de «toutes sortes de» formes?

En fait, un site qui doit non seulement identifier le visiteur, mais aussi savoir qui il est, devrafaire un formulaire d'inscription. En fait, ce formulaire peut être utilisé pour une réinscription. Vous spécifiez exactement les mêmes données qu'auparavant (email, mobile). Confirmez que vous disposez de ces données (lettre, SMS). Le système voit qu'un tel compte existe déjà, les données vous appartiennent à 100%, mais le jeton est différent - il réécrit le jeton.

Mais encore, il vaut mieux ne pas perdre la clé principale.

Comment éviter les pertes? Créez une copie de sauvegarde, protégez-la avec un mot de passe et stockez-la sur un support jetable. De plus, en fait, comme cela se fait avec les clés pour Bitcoin. En principe, vous pouvez traduire les clés principales sous forme imprimée et les enregistrer sur une feuille de papier. D'ailleurs. Et puis restaurer par entrée manuelle. Mais c'est pour des gens assez «paranoïaques» comme moi.

Mais que se passe-t-il si on me vole une clé principale?
C'est déjà grave. Bien que les recommandations décrites ici pour le stockage de la clé principale (non incluses dans le protocole) les protègent contre la falsification directe, les enregistreurs de frappe et les chevaux de Troie, néanmoins, le risque de compromettre la clé principale demeure. Malheureusement, une protection parfaite n'existe pas. La clé peut être détournée directement de la mémoire du navigateur via une vulnérabilité du moteur javascript. Par exemple. Ou perdez-vous votre téléphone portable ...

Alors, quels sont les risques de voler une clé principale?

Indispensable pour recevoir des informations sur vous et même pour agir en votre nom. Obtenir la possibilité pour un attaquant de se connecter sous vous et en mode lecture pour accéder à des informations sensibles. Calme et tranquille.Ou téléchargez simultanément toutes vos vidéos privées de vos camarades de classe. C'est désagréable pour toi. Les fans de phoques se réjouissent.

Ici, vous devez vous réinscrire rapidement avec une nouvelle clé sur des sites importants. Et, si quelque chose de terrible s'est produit, l'enregistrement de votre nouveau jeton dans la base de données du fournisseur de services de manière officielle est la seule bonne option. Vous pouvez penser à de nombreuses méthodes d'enregistrement: de la fixation du papier dans une lettre officielle, à une demande via le service d'assistance technique du site avec confirmation de votre identité de manière acceptable. Mais ce n'est que pour les sites sérieux, comme les services bancaires en ligne.

Façons de minimiser les risques. L'utilisation de clés individuelles pour les domaines (mais cela réduit la mobilité des comptes). Authentification à deux facteurs via des canaux indépendants. Le site affiche les adresses IP et les appareils sur lesquels la connexion était établie la dernière fois, afin que vous remarquiez au moins un compromis.

4 Attaques contre le régime d'autorisation

4.1 Suivi des utilisateurs

Un site de confiance peut fusionner sans vergogne des informations vous concernant avec d'autres sites. Sur Internet, il existe des sites collecteurs qui regroupent ces informations et les vendent à tout le monde. Statistiques Yandex, Google Analytics - un site rare s'en passe.

Pour que deux sites différents puissent déterminer qu'ils travaillent avec le même client, deux techniques sont utilisées:

1. ( , ).
2. ( ) .

Il y a un léger inconvénient dans le schéma 2: non pas l'utilisateur est identifié , mais le navigateur. Mais souvent, le navigateur == client.

Il semble que le jeton soit le mieux adapté pour une utilisation dans le schéma n ° 2. Après tout, si l'utilisateur a permis à deux sites (agissant en couple) de se «souvenir» d'eux-mêmes, notre jeton permanent peut agir comme une telle «empreinte digitale», non seulement le navigateur, mais l'utilisateur lui-même. Le problème pour les sites ici est qu'ils recevront des jetons différents .

Mais les sites peuvent essayer d'appliquer également le schéma n ° 1.

Le site 1 recevra le code H ₁ du navigateur et le site 2, exécuté dans le contexte du site 1, recevra le code H ₂ . Il semble maintenant que les sites peuvent former une paire (H ₁ , H₂ ) et même le transmettre à un site d'agrégateur.
Qu'un autre site 3, associé au site 2, essaie de vous suivre. Le site 3 recevra le jeton H ₃ du navigateur , et le site 2, exécuté dans le contexte du site 3, recevra le jeton H _{2 '} ! = H ₂ (voir comment les jetons sont formés). En conséquence, la combinaison des données obtenues est impossible, car ils n'ont pas de parties qui se chevauchent.

Mais cela ne signifie pas que les sites ne pourront pas utiliser un navigateur d'empreintes digitales pour surveiller . Il indique seulement que le schéma de génération de jetons lui-même est assez fiable et protège contre le suivi.

Option de protection:Déconnectez-vous des sites avec lesquels vous avez fini de travailler. Le navigateur peut le faire automatiquement lorsque vous fermez l'onglet.

4.2 Attaque XSS

XSS est un type d'attaque impliquant l'introduction de code malveillant sur la page du site Web victim.com. Par exemple, via un script d'affiliation ou un CDN piraté d'un framework populaire.

Un code malveillant peut utiliser l'autorisation de l'utilisateur sur le site pour y accéder ou pour voler des données d'authentification de l'utilisateur. Un code malveillant peut être inséré dans une page via une vulnérabilité dans un serveur Web (piratage trivial), via des réseaux affiliés (sources peu fiables), via une vulnérabilité sur l'ordinateur d'un utilisateur (crawling de chevaux de Troie).

La protection principale contre de telles attaques pour notre schéma d'autorisation est constituée de règles spéciales pour générer le champ Source lors du calcul des jetons.

Vulnérabilité: pour XSS stocké (lorsque le script est directement inséré dans le site attaqué et chargé à partir de celui-ci suite au piratage du serveur), la protection ne fonctionnera pas. Parce que le navigateur ne pourra pas identifier un tel script comme «externe». Le même problème se produit lorsqu'un attaquant effectue un proxy sur le trafic client-serveur.

4.3 Attaque CSRF

La victime visite le site evil.com, créé par un attaquant. En son nom, une requête (GET / POST / HEAD / PUT / DELETE) est exécutée vers un site où l'utilisateur est déjà autorisé (par exemple, vers un serveur de système de paiement). La demande elle-même effectue une sorte d'opération malveillante (par exemple, le transfert d'argent sur le compte de l'attaquant). Selon la supervision des développeurs, le site ne vérifie pas les champs Referer et ne demande pas d'informations de vérification supplémentaires à l'utilisateur. En conséquence, l'attaque est réussie.

Le schéma d'autorisation de site proposé supprime la plupart des scénarios d'attaque CSRF, en raison de l'algorithme de génération de jetons. Toute demande intersite entraînera la réception par le site attaqué d'un jeton non valide de l'utilisateur. Par conséquent, dans cette situation, l'utilisateur du site attaqué sera anonyme anonyme. Même une tentative d'exécution d'une demande GET inoffensive d'un site attaquant à un site attaqué (téléchargement d'une image) entraînera la réception par ce dernier d'un jeton invalide.

Cela devrait grandement simplifier la vie des développeurs de sites.

4.4 Suivi à l'aide de l'authentification unique

Deux sites S ₁ et S ₂ , auxquels l'utilisateur fait confiance et dont il dispose les clés, décident d'appliquer une technologie similaire à SSO pour le suivi des utilisateurs. Mais depuis vous ne pouvez pas intégrer un site dans un autre (l'un d'eux recevra un jeton non valide), vous ne pouvez pas ouvrir le site d'un partenaire avec un script (pour la même raison), puis le site S ₁ décide d'utiliser une technique délicate.

Sur l'une des pages, il place une étiquette translucide A, couvrant toute la fenêtre. Le lien mène au site S ₂ , et l'identifiant utilisateur (à partir de S ₁ ) et le jeton H _{1 sont} transmis dans l'adresse . L'utilisateur ne voit pas le lien. En cliquant sur n'importe quelle zone du site S ₁ , il déclenche l'ouverture d'un nouvel onglet sur le site S ₂.

Pour le moment, S ₂ ne recevra pas de jeton valide. L'auto-rechargement avec une balise ne l'aidera pas non plus

 <meta http-equiv="refresh" content="0"> 

ou un script.

Mais S ₂ peut créer la balise A sur toute sa page sous la forme d'un faux bouton Fermer:

Ce lien rechargera d'abord le site, puis le fermera. Au moment du redémarrage, le navigateur enverra le token H ₂ déjà valide au site S ₂ (car la règle 2.4 P1 a été respectée: l'utilisateur a personnellement ouvert les deux liens). En conséquence, S ₂ recevra des informations sur les actions de son utilisateur sur le site S ₁ , associera le jeton H ₁ à son H ₂ et enverra à H _{2 une} requête interserveur à S ₁ . A l'avenir, les sites S ₁ et S ₂ pourront échanger toute information sur l'utilisateur par échange de serveur, comme maintenant, ils peuvent l'identifier de manière unique séparément les uns des autres

.

Les utilisateurs mobiles sont particulièrement vulnérables à cette attaque, car essayer de fermer une page inutile peut accidentellement cliquer sur un faux lien qui occupe tout l'écran mobile.

Méthode de protection: interrompez automatiquement la session lorsque l'onglet est fermé. Ensuite, le site S ₂ n'a pas pu recevoir de jeton valide tant que l'utilisateur lui-même ne s'est pas connecté. Certes, cela ne protégera pas contre les situations où l'utilisateur lui-même a ouvert les onglets et s'est connecté à S ₁ et S ₂ . Et c'est seulement alors que les sites ont mené une telle attaque.

4.5 Compromis clé pour l'authentification unique

Laissez un compte d'utilisateur sur un serveur d'authentification qui prend en charge l'authentification unique être compromis. Nous évaluerons les risques possibles avec notre schéma d'authentification.

Les jetons pour chaque site sont calculés individuellement en fonction des clés de domaine.

Compromettre une clé de domaine ne compromet pas automatiquement toutes les autres.

La plupart des sites sur lesquels vous vous êtes déjà connecté en utilisant SSO enregistreront probablement votre jeton avec votre profil depuis le serveur SSO dans leur base de données. Dans notre schéma, le site extraira simplement un jeton de la base de données et vous reconnaîtra. C'est-à-direLe serveur SSO n'est plus nécessaire sur ces sites - il a rempli sa fonction au stade de l'enregistrement.

En d'autres termes, vous ne perdez pas automatiquement tous vos accès à la fois. Un attaquant sera identifié sur les mêmes sites qu'une autre personne.

Une tentative de reconduction de l'authentification entre domaines n'aidera pas non plus l'attaquant: le site devrait bloquer les tentatives de création d'un nouveau compte avec l'ancien identifiant SSO et le nouveau jeton de site. Ou bien, les tentatives de réécriture du jeton utilisateur pour un ID existant dans le processus SSO doivent être bloquées. Le fait de cela devrait susciter une suspicion raisonnable du côté du site.
Un jeton utilisateur ne peut être légalement modifié que d'une seule manière (voir «Scénarios de fonctionnement du protocole» ).

Risque.Si le site n'enregistre pas votre jeton et votre profil dans sa base de données, mais s'appuie entièrement sur le mécanisme SSO, un attaquant n'a qu'à effectuer une authentification interdomaine pour se connecter en utilisant votre nom.

Minimisation des risques en cas de compromis. Curieusement, mais c'est la préservation par les sites de tokens et de profils utilisateurs de leur côté. Une tentative par un attaquant de mener une authentification interdomaine peut provoquer un conflit entre l'ancien utilisateur Id et son nouveau jeton. La situation elle-même, lorsque l'utilisateur a modifié le jeton d'une manière autre que celle spécifiée dans le protocole, doit être perçue de manière suspecte ou rejetée complètement.

Risque maximum:autorisation en votre nom sur d'autres sites (où vous n'êtes pas allé). Accédez à vos données de profil. Commettre des actes illégaux en votre nom. Et pour que le propriétaire légitime ne puisse rien retourner, un attaquant peut changer son jeton sur le serveur d'autorisation de manière légale. Ce risque coïncide cependant avec les risques liés à l'utilisation des régimes d'autorisation traditionnels.

Moyens de protection. Refus d'utiliser l'authentification unique (d'autant que le schéma proposé a été conçu comme un moyen de s'éloigner des schémas d'authentification centralisée). Utilisez plusieurs SSO (ne stockez pas tous les œufs dans le même panier!).

Si SSO prend en charge l'authentification à deux facteurs avec authentification par d'autres attributs (courrier, téléphone), il est alors possible de reprendre le contrôle du compte du serveur d'autorisation.

4.6 Compromission de jetons pendant le transfert

Il est clair que le mécanisme proposé pour hacher les jetons pendant le transfert ne donne pas une garantie à 100% de leur protection. Un attaquant peut intercepter le trafic de la victime au moment du transfert d'un jeton non sécurisé (lors de l'enregistrement principal de la clé permanente), à ​​titre d'exemple. Et puis utilisez-le.

Par conséquent, l'utilisation de SSL est encouragée. Mais ne prenez pas le HTTPS comme panacée. Ce protocole est également exposé, ainsi que HTTP. Seulement un peu plus dur.

Certes, un transfert aussi rare d'un jeton ouvert, ainsi que l'utilisation d'un jeton individuel pour chaque domaine, réduit le risque d'exploiter la vulnérabilité. Néanmoins.

Un autre danger est l'interception et la réutilisation du jeton dans la session en cours de l'utilisateur. Comme je l'ai dit plus tôt, idéalement, le jeton devrait être haché avec un nouveau sel à chaque demande du client. Cependant, cela supprimera la possibilité de traitement parallèle des demandes sur le serveur et rendra impossible l'envoi de demandes parallèles à partir du client. Le calcul et la vérification des hachages sont généralement une opération coûteuse qui réduit les performances.

De plus, le jeton passé dans l'en-tête ne doit jamais être disponible depuis Javascript. Similaire à Cookie avec le drapeau HttpOnly. Même lors de la réception de requêtes ajax par scripts.

Méthode de fonctionnement: intercepter la demande d'un utilisateur, extraire la valeur actuelle du jeton, envoyer une autre opération avec le même jeton (comme pour le même utilisateur). Certes, le système classique basé sur les cookies de session est également vulnérable à ce type d'attaque.

Méthode de protection: confirmation des opérations importantes via d'autres canaux de communication, par exemple par SMS ou courrier; pré-enregistrement du token via d'autres canaux de communication (certificat papier, par exemple).

4.7 Piratage d'un site Web et compromission de jetons

Les sites de piratage se produisent constamment. Même les grands sites bien protégés se brisent. Il existe de nombreuses façons de pirater: d'une injection triviale à un «drain» d'initié. Par conséquent, la compromission de votre jeton sur n'importe quel site est un événement très probable.

Mais le protocole proposé, tout de même, rend l'événement de piratage du site le moins douloureux pour vous.

La compromission du jeton n'entraîne pas la compromission de la clé de domaine sur la base de laquelle elle a été calculée. De plus, cet événement ne conduit pas au compromis de vos autres jetons . Et si c'est le cas, l'accès à d'autres sites reste inaccessible.

Ceci est particulièrement agréable lorsque des clés sont apportées à la plupart des sites à l'aide d'une clé principale: il est impossible de la restaurer par reverse engineering.

Mais en même temps, il est impossible d'utiliser la clé de domaine dont le jeton a été compromis, pour des raisons évidentes. Je dois changer la clé.

La clé du domaine où la fuite officielle s'est produite peut être effectuée soit sur la base d'un nombre aléatoire, soit sur la base d'une clé principale, avec l'ajout d'un numéro de version:

$$

Conclusion

Plusieurs de mes amis à qui j'ai montré l'article m'ont posé essentiellement la même question: "Quelle est la principale chose ici?"


Oh, il n'y a pas de puce principale! Hélas.Mais il existe un certain nombre de détails qui rendent le protocole plus rentable que le schéma de connexion / mot de passe traditionnel.

1. Vous avez probablement remarqué ce popup ennuyeux sur de nombreux sites.

«Notre site enregistre les cookies! Mettez votre casque et soyez vigilant, car le grand frère vous regarde! Cliquez sur "Oui", car vous n'avez toujours pas le choix. "

Ceci est un autre popup pour un tas d'autres tout aussi intrusifs et très nécessaires. Et tout cela grâce au RGPD européen (un analogue de notre loi PD).

Alors voilà. Dans notre système, les cookies ne sont plus nécessaires à des fins d'identification! Du mot «complètement». L'utilisateur décide d'autoriser ou non le site à l'identifier, et quand et pendant combien de temps. Moins un popup ennuyeux, +1 au karma du protocole.

2. Le développeur n'a plus besoin de faire des formulaires d'autorisation et de récupération de mot de passe. Il n'est pas nécessaire d'implémenter des algorithmes SSO complexes et de maîtriser des bibliothèques complexes: OAuth, SAML, Kerberos, etc., suivez la procédure d'enregistrement de votre site, modifiez les clés d'autorisation, surveillez leur sécurité; et si quelque chose a mal tourné avec SSO, comprenez de toute urgence: "qu'est-ce qui a mal tourné et pourquoi." De plus, le serveur d'autorisation peut bloquer votre site pour des raisons inconnues. Allez le découvrir. Hier, tout a fonctionné, mais aujourd'hui ... Et ici, il suffit de lire le jeton dans l'en-tête et de vérifier s'il y en a un dans notre base de données. Simple = fiable .



3. L'utilisateur n'a pas besoin d'entrer et de se souvenir d'un tas de mots de passe. Utilisez les services de sites tiers ou on ne sait pas par qui et comment les programmes écrits. Vous ne pouvez pas avoir peur de l'accès à un ordinateur par des tiers, des enregistreurs de frappe et des chevaux de Troie. Il suffit de faire une copie de sauvegarde de la clé principale, de la protéger avec un mot de passe et de la stocker quelque part sur une clé USB. Comme un portefeuille Bitcoin. Qu'est-ce qui n'est pas une fonctionnalité?

4. Si le site est piraté, vous ne risquez rien. Eh bien, régénérez à nouveau la clé. Alors que le mot de passe divulgué aux crackers du site peut causer beaucoup de problèmes.

5. Le protocole a été créé en tenant compte de l'expérience des attaques de réseau connues. Son architecture comprend déjà une protection de base contre XSS, CSRF. Encore une fois, les webmasters trouveront plus facile de développer des sites. Et leurs utilisateurs - plus calmes.

6. Indépendance du protocole vis-à-vis d'un fournisseur de services spécifique et de ses caprices. Le protocole vous rend libre.

7. Enfin, le protocole proposé revendique la future norme ouverte . Et la norme, si elle est adoptée par les participants, impose des obligations de mettre en œuvre la fonctionnalité conformément au cahier des charges , et de ne pas exclure la ferme collective de ses propres décisions d'autorisation, inventant une fois de plus la forme de connexion, d'enregistrement, de récupération de mot de passe, de déconnexion. Et ne plaisante pas avec le hachage de mot de passe ou l'injection SQL.

Et surtout, comme tout standard ouvert, il peut et doit être vérifié experts indépendants.Même si l'auteur de la version originale du protocole a «foiré» les détails, la communauté en ligne peut identifier ce correctif en temps opportun. Eh bien, ou envoyez mon protocole à la ferraille. Hélas pour moi, et "pooh-carry" pour tout le monde.

- Je pense que je devrais m'arrêter là-dessus
E. Wiles

---

PS
Vous pouvez vous familiariser avec l'option d'un article complet dans un format hors ligne. Lors de la composition de documents sur Habr, je pouvais faire des fautes de frappe. Si vous avez des commentaires sérieux, il est préférable de vérifier l'original et de laisser les commentaires d'article (critiques) dans ce fichier . Envoyez-moi vos modifications sur le mail sergey201991 [] gmail. Je ne suis pas une pieuvre, mais je vais essayer de répondre. J'ajouterai plusieurs commentaires correspondants / intéressants à cet article. Avec leurs réponses. Une variante d'un article de commentaire séparé n'est pas exclue.

Oui, je sais que le protocole peut avoir des problèmes:

1. il n'y a aucun moyen de se connecter sous votre compte sur l'appareil de quelqu'un d'autre si vous n'avez pas de clé en main, mais vous en avez besoin de toute urgence; les mots de passe sont plus pratiques ici
2. ; , SSO
3. «», - : - ( )
4. -

En ce qui concerne la page 1 - je pensais sérieusement à revenir à l'idée de générer une clé de domaine basée sur un mot de passe, en faisant une protection contre la force brute en compliquant le processus de génération de la clé: disons, augmenter le nombre de tours de hachage à 1000. Mais le problème avec une possible collision de mots de passe pour différents utilisateurs sur un seul Le site me hante.

Concernant la page 2 - cela est traité par le temps. Vous devez vous habituer aux nouvelles interfaces. Au début, ce ne sera pas clair, puis ce sera simple. Donner à un homme des années 80 un smartphone moderne, il n'aurait pas non plus deviné comment le gérer.

Merci beaucoup si vous le lisez jusqu'au bout!