Authentification et Gestion des Identités. Jean-Noël Colin

Transcription

1 Authentification et Gestion des Identités Jean-Noël Colin 1

2 Agenda Introduction Authentification Gestion distribuée d'identités Kerberos, CAS, OpenId, SAML, Shibboleth, Liberty Alliance 2

4 Introduction Gestion d'identités (Rapport Gartner 2008) Administration des identités Création, modification des identités, rôles... 'User provisioning' Vérification Preuve de l'identité: authentification, SSO, Fédération...) Contrôle d'accès Autorisation et gestion des droits Surveillance Monitoring, journaux, audit... 4

5 Introduction Sujet d'actualité 25% des moyennes et grandes entreprises ont implémenté une solution 25% sont en phase d'évaluation (source: Gartner report, 2008) 5

6 Introduction Sujet complexe: augmentation constante Nombre d'applications à intégrer, nombre d'identités à gérer, nombre de ressources à protéger Pression règlementaire Risque de sécurité Coût de mise en oeuvre et de gestion 6

7 Introduction Sujet Entité pouvant être authentifiée Identité Ensemble homogène et cohérent de caractéristiques d'un sujet (attributs, préférences...) Identifiant Valeur permettant de référencer de manière univoque une entité Pseudonyme Identifiant préservant la confidentialité de l'identité du sujet Temporaire ou persistent 7

8 Introduction Quelques questions courantes D où venez-vous? Qui êtes-vous? Que puis-je savoir de vous? Puis-je vous croire? 8

10 Authentification Authentification Identification Deux raisons pour authentifier L'identité est la base des décisions de contrôle d'accès L'identité est enregistrée dans les journaux de sécurité 10

11 Authentification Principe de base prouver mon identité au moyen de quelque chose que je connais password, PIN quelque chose que j ai token, smartcard quelque chose que je suis biométrie authentification multi-facteurs carte bancaire 11

12 Authentification Sécurité des mots de passe Politique de qualité des mots de passe (longueur, format, mots de passe faibles, historique) Mot de passe initial Réinitialisation du mot de passe Expiration forcée des mots de passe Nombre de tentatives infructueuses limité Délai imposé entre des tentatives infructueuses Modification des mots de passe par défaut Mémorisé si utilisé régulièrement Ne pas changer de mot de passe avant les vacances 12

13 Authentification taille alphabet 10 (chiffres) 26 (lettres) 62 (lettres M/m + chiffres) 90 (lettres M/m + chiffres + symboles) longueur mot de passe longueur de clé équivalente (bits) Ordre de grandeur du temps d énumération du dictionnaire des mots de passe possibles par un ordinateur personnel ~0 ~0 3 1h 1 mois 1 mois 500 ans 2 ans ans Source: Jean-Noël rapport Colin, University Règles of et Namur recommandations concernant les mécanismes d authentification de niveau de robustesse standard, Version 0.13 du 3 avril 2007, Secrétariat générale de la défense nationale de France. 13

14 Authentification Protection du mot de passe Lors du stockage Lors de la transmission Eviter de 'cacher' le mot de passe Attaque de type spoofing Fausse interface d'authentification destinée à collecter les mots de passe Contre-mesures Afficher l'historique des connexions Mécanisme sûr d'activation Authentification mutuelle 14

15 Authentification Attaques sur les mots de passe Problème Possédant son digest h, retrouver un mot de passe p parmi N choix possibles Ex: mots de passe de longueur 10, composés de lettres M/m et chiffres: possibilités 8.4e17 Problème similaire Connaissant P et C, retrouver K tel que C = EK(P) De manière générale, inverser une fonction irréversible Paramètres considérés: T: nombre d opérations (hashage ou encryption) M: nombre de mots mémoire utilisés N: nombre de choix possibles (espace de clés) 15

16 Authentification Attaque brute force ou recherche exhaustive Principe: générer tous les mots de passe possibles en séquence, calculer leur hash et comparer celui-ci à h. En cas d égalité, le mot de passe recherché est trouvé En moyenne, le mot de passe sera trouvé en N/2 essais T = N, M = 1 16

17 Authentification Attaque par dictionnaire Principe: pré-calculer l empreinte de tous les mots de passe possibles et les stocker dans une table. rechercher h dans la table, ce qui permet de retrouver le mot de passe correspondant T = 1, M = N 17

18 Authentification Compromis temps-mémoire (time-memory trade-off) M. Hellman. A cryptanalytic time-memory trade-off. IEEE Transactions on Information Theory, 26(4): , jul Idée: trouver le mot de passe (ou la clé) plus rapidement que la force brute tout en utilisant moins de mémoire que le dictionnaire Principes créer m chaines de t mots de passe le i ème mot de passe de la chaine est calculé à partir du (i-1) ème On ne mémorise que le premier et le dernier élément de chaque chaine 18

19 Authentification p 0,0 H R H R R H R h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 =r p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t r = pm-2,t-1... p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 =r p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R: fonction de réduction soit h, le hash du mot de passe à craquer calculer r = R(h) 19

20 Authentification p 0,0 H R H R R H R h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R: fonction de réduction si r = R(h) ne se trouve pas dans la dernière colonne, on réessaie avec R(H(R(h))), puis avec R(H(R(H(R(h)))))... 20

21 Authentification Efficacité soit une table de m chaines de longueur t, soit m.t éléments M = m.m0 où m0 est l espace nécessaire pour stocker (pi,0,pi,t-1) cas défavorable: (t-1) opérations de hash nécessaires si tous les éléments de la table sont différents, la probabilité de trouver la clé est mt/n Hellman montre que: P table 1 N m t 1 i=1 j =0 1 it N j +1 21

22 Authentification Limitations collision et fusion de chaines collision: conséquence: doublons dans la table plus la table est grande, plus la probabilité de fusion est grande, donc l efficacité de la table décroit avec sa taille solution: générer l tables avec R0, R1,... Rl-1 dans ce cas: x, y x y R(x) = R(y) P table N m t 1 i=1 j =0 1 it N j +1 l 22

23 Authentification p 0,0 Table arcs-en-ciel (rainbow table) - P. Oechslin fonction de réduction différente à chaque étape H R 0 H R 1 R t-3 H R t-2 h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R i : fonction de réduction 23

24 Authentification Avantage cas défavorable: t(t-1)/2 opérations de hash nécessaires plus efficace que la méthode de Hellman: prenons t tables m.t (Hellman) et 1 table mt.t (Rainbow table), soit mt 2 mots de passe dans les deux cas les probabilités de succès sont approximativement égales T = t 2 (Hellman) vs T = t(t-1)/2 (Rainbow tables) 24

25 Authentification Données biométriques Données physiologiques ou comportementales empreinte digitale, rétinienne, vocale, frappe clavier Collecte des modèles Identification: trouver 1 parmi n Authentification: vérifier la correspondance pour 1 Algorithme de correspondance avec seuil 25

26 Authentification One-Time Passwords (OTP) principe: le client génère un mot de passe et l envoie au serveur pour établir la session. Ce mot de passe est valable pour une seule session/transaction unique rend inutile toute tentative d attaque brute force, dictionnaire ou rejeu mot de passe peut circuler en clair généré automatiquement plus besoin de le mémoriser 26

27 Authentification One-Time Passwords (OTP) secret partagé entre client et serveur mode de génération de OTP OTP = f(secret partagé, horloge) OTP = f(secret partagé, n de séquence) OTP = f(secret partagé, challenge aléatoire) autres solutions liste papier matrice de mots de passe cryptographie asymétrique au lieu d un secret partagé 27

28 Authentification One-Time Passwords (OTP) Vulnérabilités Social engineering Phishing MITM 28

29 Authentification Social engineering Le Social engineering consiste à manipuler, influencer ou tromper une personne pour l amener à effectuer une action. Souvent, cette action consiste à révéler de l information confidentielle ou toute autre action au bénéfice de l attaquant. L être humain est le point faible Sensible à l autorité, la gentillesse, le sentiment d urgence, de similarité, sens des responsabilités Cibles typiques Personne peu concernée par la sécurité Rôles de support/aide Rôles privilégiés Personne avec connaissance spécifique Personne avec accès à des actifs de valeur (information ou économique) 29

30 Authentification Le facteur humain est le maillon faible 30

31 Authentification Types d attaques physique Fouille (dumpster diving), vol, extortion, desktop hacking sociale Basé sur la tromperie ou fausse relation Mixte Récolte d information Développement de la relation Exploitation de la relation Action pour atteindre l objectif 31

32 Authentification Méthode de protection Education Défis principaux Distinguer le vrai du faux, le bien du mal Critères et procédure de reporting Savoir quand et comment rapporter un problème Définir des politiques claires Définir des lignes de communication claires Coordination entre sécurité IT et sécurité organisation 32

33 Authentification Sources des identités Fichier Simple à implémenter Expressivité limitée Encryption des données sensibles Contrôle d'accès aux données Base de données Simple à implémenter Modèle de données flexible et extensible Encryption des données sensibles Contrôle d'accès aux données Souvent spécifique à une application 33

34 Authentification LDAP Lightweight Directory Access Protocol Définit un protocole d'accès et un modèle de données Dérivé du standard X.500 Organise l'information sous forme d'arbre: DIT Directory Information Tree Données stockées sous forme de noeuds organisés en arbre structure des noeuds définis dans un schéma extensible Éléments du schéma identifiés par un Object Identifier (OID) Root suffix: racine de l'arbre ex: dc=fundp, dc=ac, dc=be 34

35 Authentification LDAP Lightweight Directory Access Protocol Noeud = DSE Directory Service Entry Identifié par un nom (DN & RDN) Instantiation d'une ou plusieurs classes ObjectClass Définit les attributs obligatoires et optionnels Héritage de classes Représente un utilisateur, un groupe (statique ou dynamique) Ou une entité quelconque: il faut juste définir l'objectclass approprié 35

36 Authentification LDAP Lightweight Directory Access Protocol Protocole d'accès: session Bind (ouverture de session) authenticated or anonymous Opération(s) search, delete, modify (add ou update) Unbind (fermeture de session) Contrôle d'accès Access Control List définit name, target, permission, bind rules aci: (target="ldap:///uid=jnc,dc=example,dc=com") (targetattr="*")(version 3.0; acl "example aci"; allow (write) userdn="ldap:///self";) Souvent spécifique à une implémentation 36

37 Authentification Sources indépendantes Simple Isolation Multiplication des identités Risque d'incohérence 37

38 Authentification Sources partagées Une seule identité Si identité compromise, plusieurs services compromis 38

39 Authentification Synchronisation des sources Une seule identité Coût de synchronisation Implémentation spécifique 39

40 Authentification Service d'authentification Libère l'application de la gestion des identités et du processus d'authentification Requiert un protocole sûr Requiert la confiance, éventuellement interorganisations 40

42 Gestion distribuée d'identités Principes Deux rôles Partie requérante (relying party) Fournisseur de service (Service provider) Partie certifiante (asserting party) Fournisseur d'identité (Identity provider) Relation de confiance Confiance: je crois ce que l autre me dit 42

43 Gestion distribuée d'identités Single Sign-On (SSO) Une seule authentification donne accès à plusieurs services Fédération d'identités Accord entre fournisseurs sur une manière commune de référencer un sujet Identifiant Attributs Définit un cercle de confiance (circle of trust) 43

44 Gestion distribuée d'identités Motivations Une source autoritaire de données Information sur les utilisateurs, privilèges Meilleur contrôle sur la vie privée Moins de travail de gestion des données des utilisateurs Sécurité Les données d'authentification ne sont jamais connues des Service Providers Coopération Accès aux ressources d'autres organisations de manière transparente 44

45 Gestion distribuée d'identités Motivations Satisfaction des utilisateurs Éviter les identifications et authentifications répétées Unifier la gestion des données d'identité Donner à l'utilisateur le contrôle sur la confidentialité de ses données (user centric) Architecture logicielle Décharger l'application des tâches d'authentification et de gestion des données personnelles Approche modulaire Abstraction du mécanisme d'authentification 45

46 Gestion distribuée d'identités Gestion distribuée requiert Standards flexibles et extensibles pour la représentation des données Protocoles d'échange d'information Indépendant de la technologie sous-jacente Préservant la confidentialité des données Interopérable Mécanismes de gestion de la confiance 46

47 Gestion distribuée d'identités Choix d une approche: Fonctionnalités Gestion des identités Unique, multiple? Qui gère? Utilisateur? Organisation? Respect de la vie privée Attributs Fédération ou délégation? Mécanisme de fédération Sur base des identifiants? Attributs? Pseudos? 47

48 Gestion distribuée d'identités Choix d une approche: Services Authentification Autorisation Attributs Pseudonyme/anonyme Service de découverte Journaux et audits 48

49 Gestion distribuée d'identités Choix d une approche: Gestion de la confiance Domaine unique? Cross-domain? Modèle de confiance? 49

50 Gestion distribuée d'identités Choix d une approche: Déploiement Protocoles utilisés Communication Sécurisation Authentification, autorisation Plateformes supportées, interopérabilité Code disponible, propriétaire ou non Résistance aux attaques: phishing, MITM, id de session 50

51 Gestion distribuée d'identités Lignes directrices de l OCDE limitation en matière de collecte qualité des données limitation de l'utilisation garanties de sécurité participation individuelle responsabilité 51

52 52 Kerberos

53 Needham-Schroeder Protocole d'authentification et d'échange de clé Alice (A) et Bob (B) veulent communiquer de manière sûre Échange d'un secret Authentification du partenaire Utilisation d'un tiers de confiance (T) Partage une clé différente avec chaque participant KAT = Clé secrète partagée par A et T Génération d'une clé de session K pour le dialogue entre Alice et Bob Utililisation de nombres aléatoires (nonce) pour contrer les attaques par rejeu 53

54 Needham-Schroeder Trent 1. A, B, R a 2. {Ra, B, K, {K, A}KBT }KAT 3. {K, A} KBT 4. {R b } K Alice 5. {R b -1} K Bob 54

55 Kerberos Objectif: authentifier un sujet tout en évitant la transmission de données qui permettraient de se faire passer pour ce sujet Système d'authentification distribué développé par le MIT Basé sur le protocole Needham-Schroeder Mécanisme de ticket: lorsqu'un client C veut accéder à un service S, il a besoin d'un ticket Tc,s pour prouver son identité Authentification du client par mot de passe Mot de passe conservé par le serveur Kerberos 55

56 Kerberos Cryptographie symétrique pour le chiffrement du mot de passe sur le serveur Le serveur est capable de déchiffrer les mots de passe Supporte Single Sign-On (SSO) Authentification mutuelle Renouvellement de ticket Délégation d'authentification 56

57 Kerberos Deux services Service d'authentification (aka KDC) Service de délivrance de ticket (Ticket Granting Service TGS) Deux phases Login Obtenir un TGT Ticket Granting Ticket Contient une clé de session + un ticket pour le TGS (TTGS) Demande d'accès à un service Obtenir un Ticket 57

58 Kerberos Remarques: Les mots de passe sont stockés uniquement sur le serveur Les mots de passe ne sont jamais transmis sur le réseau Les mots de passe constituent la base de l'authentification mutuelle entre le Client et le Service d'authentification 58

59 Kerberos Authentification 59

60 Kerberos Accès au service 60

61 Kerberos Authentification Cross-realm Établissement d'une relation de confiance entre les KDCs des deux realms, via un secret partagé Relation transitive: facilite la gestion des clés en définissant un chemin de confiance de realm en realm Délégation 61

62 Kerberos Tickets particuliers Tickets renouvellables Tickets postdatés Initialement invalides, date de validité dans le futur Tickets transmissibles Forme de TGT permettant de demander un nouveau ticket, mais avec une IP différente Notons encore que Kerberos ne protège pas contre une attaque brute force ou mots de passe faibles requiert un canal sûr pour établir le mot de passe 62

63 63 Yale's CAS

64 Central Authentication Service Objectif: service d'authentification centralisé, pour les applications Web Inspiré de Kerberos Basé sur le protocole HTTP(S) Développé par l'université de Yale Repris par le consortium jasig depuis 2004 Version 3 disponible, version 4 en préparation Supporté par de nombreuses plateformes (Moodle, uportal, Shibboleth, Liferay, Mantis...) 64

65 Central Authentication Service Architecture Serveur CAS Authentifie les utilisateurs Certifie les identités des utilisateurs envers les clients CAS Mécanismes d'authentification supportés: Client CAS AD, JAAS, JDBC, LDAP, RADIUS, X Application Web, supportant l'authentification via CAS Librairies disponibles pour.net, Java, ColdFusion, Perl, PHP, Ruby, Zope... Browser 65

66 Central Authentication Service Première étape: authentification Authentication TGC: Ticket Granting Cookie 66

67 Central Authentication Service Deuxième étape: accès au Client Id ST TGC ST ST: Service Ticket 1. Demande d'accès 2. Redirection vers le serveur CAS et présentation du TGC 3. Obtention du ST 4. Validation du ST et récupération de l'id 67

68 Central Authentication Service Ticket Granting Cookie Equivalent du TGT de Kerberos Utilisé pour obtenir un ticket d'accés à un service Ne contient aucune information personnelle Cookie privé (seulement pour le CAS serveur) Durée de vie limitée Service Ticket Usage unique Délivré par le serveur CAS sur présentation du TGC Durée de vie très limitée (quelques secondes) Spécifique à un client et à un service 68

69 Central Authentication Service Validation du ST Si ticket valide Retourne l'identifiant de l'utilisateur Format texte brut ou xml Si ticket invalide, retourne une erreur Possibilité de retourner d'autres informations que l'identifiant Attributs 69

70 Central Authentication Service Gestion des services Depuis la version Permet de définir: Quels services (clients) peuvent accéder au serveur Quelles informations de l'utilisateur peuvent être communiquées au client Meilleur contrôle sur la confidentialité des informations Premiers pas vers un mécanisme d'autorisation 70

71 Central Authentication Service CAS dans un environnement multi-couches Mécanisme de proxy Proxy CAS = Client CAS Problème: pour obtenir un ST pour un service, il faut le TGC, mais un Proxy CAS n'y a pas accès Solution: PGT Proxy Granting Ticket Equivalent pour le Proxy CAS du TGC pour le Browser Permet au Proxy CAS de demander au Serveur CAS un ticket (PT - Proxy Ticket) pour accéder à un Client Durée de vie limitée (quelques heures) Opaque 71

72 Central Authentication Service Mécanisme de Proxy Id PT PGT PT Id TGC ST ST PGT Service Backend PT 1. Demande d'accès 2. Redirection vers le serveur CAS et présentation du TGC 3. Obtention du ST 4. Validation du ST et récupération de l'id et du PGT 5. Demande d'accès au service backend et présentation du PGT 6. Obtention du PT et accès au service back-end 7. Validation du PT et récupération de l'id CAS Proxy 72

73 Central Authentication Service Mécanismes d'extension Authentification Front-end Fournisseur d'attributs Stockage des tickets 73

74 74 OpenId

75 OpenId 75

76 OpenId OpenID Provider (OP) Relying Party(RP) 76

77 OpenId Scénario simplifié 1. Mon identifiant est jn.colin.myopenid.com 3. C est vrai! Relying Party(RP) OpenID Provider(OP) 2. Est-ce vrai? 77

78 OpenId Scénario un peu plus complet 1. Mon identifiant est jn.colin.myopenid.com 4. C est vrai! 3. Validation et confirmation 2. Est-ce vrai? 78

79 OpenId En quelques mots OpenID propose un protocole ouvert pour une gestion décentralisée des identités, mettant l'utilisateur au centre des décisions le concernant OpenID est développé et supporté par la Fondation OpenId, organisée en chapitres locaux Acteurs privés importants: Google, Yahoo, Microsoft, IBM, Verisign Well-known OPs, like AOL, Google, and Yahoo! Exemple: 79

80 OpenId 80

81 OpenId Concepts OpenID Identifier URI (http ou https) ou XRI OpenID Provider (OP) Gère les identités Accessible via un service public (Endpoint URL) Atteste d'une authentification réussie OpenID Relying Party (RP) Demande la preuve d'une authentification du sujet par l'op 81

82 OpenId Types de communication Le protocole est basé sur HTTP Paramètres passés sous forme de paires (clé, valeur) Communication directe Initiée par le RP vers l'op HTTP POST Communication indirecte Au travers du navigateur Initiée aussi bien par le RP que par l'op HTTP Form submission ou HTTP Redirect 82

83 OpenId 83

84 OpenId Initialisation Utilisateur fournit un identifiant Soit le sien Soit celui d'un OP Normalisation 'Nettoyage' de l'identifiant fourni à la phase précédente en préparation de la phase de découverte' Détermine le type d'identifiant: XRI or URI? Résolution des redirections et règles rfc

85 OpenId Découverte A partir de l'identifiant normalisé, détermine l'information nécessaire pour établir une connexion avec un OP OP Endpoint URL Version(s) du protocole supportée(s) Identifiant peut être soit celui de l'utilisateur, soit celui de l'op 85

86 OpenId Découverte html > wget --save-headers HTTP/ OK Date: Tue, 28 Jul :34:06 GMT Server: Apache/ X-XRDS-Location: Set-Cookie:... P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"... <html> <link rel="openid.server" href=" /> <link rel="openid2.provider" href=" /> <link rel="stylesheet" href=" /> 86

87 OpenId Découverte XRDS > wget --save-headers <?xml version="1.0" encoding="utf-8"?> <xrds:xrds xmlns:xrds="xri://$xrds" xmlns:openid=" xmlns="xri://$xrd*($v*2.0)"> <XRD version="2.0"> <Service priority="0"> <Type> <Type> <Type> <Type> <Type> <URI> <LocalID> </Service> 87

88 OpenId Découverte XRDS <Service priority="1"> <Type> <Type> <Type> <Type> <Type> <URI> <openid:delegate> </Service>... </XRD> </xrds:xrds> 88

89 OpenId Requête d authentification Key openid.ns openid.mode openid.claimed_id openid.identity openid.assoc_handle openid.return_to openid.realm Value checkid_setup {HMAC-SHA1}{4bbb1d7b}{/Hxxkw==} oic.time= dbf9c9e de0f 89

90 OpenId Key Authentication Response openid.ns openid.mode openid.op_endpoint openid.claimed_id openid.identity openid.return_to openid.response_nonce openid.assoc_handle openid.signed openid.sig Value id_res hhttp:// oic.time= dbf9c9e de0f T11:33:58ZVA0pwk {HMAC-SHA1}{4bbb1d7b}{/Hxxkw==} assoc_handle,claimed_id,identity,mode,ns,op_endpoint,response_ nonce,return_to,signed F2xCeQ6Cc8sJw9Bn890+ABFGkCM= 90

91 OpenId Version URL 2.0&openid.return_to= %3D ba9d4502cab7675ca&openid.claimed_id= jn.colin.myopenid.com/&openid.identity= &openid.mode=checkid_setup&openid.realm= &openid.assoc_handle=%7bhmac-sha1%7d%7b4a5c2323%7d%7btxx1ha %3D%3D%7D 91

92 OpenId Version URL oic.time= ba9d4502cab7675ca&openid.assoc_handle=%7bhmac- SHA1%7D%7B4a5c2323%7D%7BTxx1HA%3D%3D%7D&openid.claimed_id=http%3A %2F%2Fjn.colin.myopenid.com%2F&openid.identity=http%3A%2F %2Fjn.colin.myopenid.com%2F&openid.mode=id_res&openid.ns=http%3A%2F %2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=http%3A%2F %2Fwww.myopenid.com %2Fserver&openid.response_nonce= T12%3A08%3A48Z1giwoS&openid.return_t o=http%3a%2f%2fwww.livejournal.com%2fopenid%2flogin.bml%3foic.time %3D ba9d4502cab7675ca&openid.sig=QK87KjU0snL30D %2BP8XkswydJLPs%3D&openid.signed=assoc_handle%2Cclaimed_id%2Cidentity %2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2Csigned 92

93 OpenId En cas d échec Key openid.ns openid.mode Value cancel Version URL b0656f4a4e6bb38a2d17&openid.mode=cancel&openid.ns=http%3a%2f %2Fspecs.openid.net%2Fauth%2F2.0 HTTP/1.1 93

94 OpenId Validation Du côté de l'op Authentifier l'utilisateur (ou valider une authentification antérieure) Validation complémentaire Vérification de l'url de retour avec le service endpoint du RP Du côté du RP Vérification: URL de retour (openid.return_to) correspond à l'url qui traite l'assertion Vérification de l'information découverte Vérification du nonce 94

95 OpenId Sécurité des messages Objectif: garantir l'intégrité de la communication Signature des réponses par OP HMAC-SHA1 ou HMAC-SHA256 Vérification de la signature par RP 95

96 OpenId Mode 'smart' Etablissement préalable à tout échange d'une Association (secret partagé) entre RP et OP Message direct 'associate' Clé MAC établie Soit par l'op Fortement recommandé d'utiliser SSL!! Soit négociée par Diffie-Hellman Valeurs par défaut pour le générateur et le modulus 96

97 OpenId Requête d'association Mode de signature: HMAC-SHA256 Type de session: DH-SHA256 openid.ns=http%3a%2f%2fspecs.openid.net%2fauth %2F2.0&openid.mode=associate&openid.session_type=DH- SHA256&openid.assoc_type=HMAC- SHA256&openid.dh_consumer_public=BoRbXby16PkQ3K39HrOUMmc QkXEHunfYnTffz6wFsAmGbHBDvDk0Cp99P3h2fll04DhJ%2BlOlApH %2BN%2B9WiyimtSEI9o8Z9xeCziWqZ2eu3Wpto5h%2BKExT0mNCc %2FsQGMyeok45JmOTAoye9o8%2Bznl1eM7aJERoav3gAWq44jHTfgc %3D 97

98 OpenId Réponse d'association assoc_handle:{hmac-sha256}{4a6dae6e}{wa0maq==} assoc_type:hmac-sha256 dh_server_public:u +IqMuc91HB3Nl4fJwA893XcnlSAwGUXGZSzT3PU77FqlePqMtsiuhAL5PeZfPpK T/776APjsPmU8gj/Iedd6J0y+tyLlQgHW/wTi+kriMj5esah +csntlbyid2j8usaxq120ibpj4hcbvbnl19yjbopngvqlogra2ogn8kervy= enc_mac_key:gd1v4ixgni7jrrt1aho9o4knoc0tgyf4adit6s2chdy= expires_in: ns: session_type:dh-sha256 98

99 OpenId Mode 'dumb' Pas de gestion des associations au niveau du RP Validation a posteriori de la réponse via une communication directe entre le RP et l'op Message direct 'check_authentication' Copie exacte des champs reçus dans la réponse d'authentification OP valide sa propre signature OP ne peut pas valider plus d'une fois une réponse d'authentification Plus lourd en terme d'échanges 99

100 OpenId Mesures de sécurité Utilisation de SSL pour se protéger d'une écoute illicite (eavesdropping) Utilisation d'un nonce pour se protéger d'une attaque par rejeu Utilisation de signature digitale pour garantir l'authenticité et l'intégrité des réponses de l'op MITM possible durant la phase de découverte et les communications directes (association et validation directe) Possibilité de signer les données découvertes pour garantir leur authenticité 100

101 OpenId Mécanisme d'extension Utilise les mêmes messages que le protocole de base Définit de nouveaux champs pour les messages Identifiés par un 'namespace' Ex: openid.ns.<extension_alias>= 101

102 OpenId Extension SREG: Simple Registration Objectif: obtenir des informations sur le sujet Etend la requête d'authentification openid.sreg.required openid.sreg.optional openid.sreg.policy_url Champs valides: nickname, , fullname, dob, gender, postcode, country, language, timezone Valeurs ajoutées à la réponse d'authentification Valeurs retournées par l'op doivent être signées 102

Montrer encore