Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Vers les défauts logiques d’authentification
Pour identifier et caractériser les risques relatifs au parcours d’authentification, nous avons réalisé une enquête au sein des équipes (différentes entités au sein d’Orange) de développement et de conception des applications. Nous avons également analysé des défauts sur les applications existantes au sein d’Orange et d’ailleurs (e.g., Skype, Yahoo).
Les résultats de cette étude révèlent entre autres que le processus de spécifica-tion des parcours d’authentification se limite à spécifier, uniquement, les mécanismes d’authentification à utiliser. De plus, grâce à la modélisation des menaces [153, 165], nous découvrons que les défauts identifiés ne sont pas dus à des défauts sur les mé-canismes d’authentification mais aux détournements de l’usage légitime du système d’authentification d’où leur qualification en défauts logiques.
En effet, deux grands types de défauts de sécurité existent dans la sécurité des applications Web/Mobile [91, 171] : Les bugs (y compromis les vulnérabilités) et les défauts de conception (i.e., failles) de sécurité. Les différences fondamentales sont dans leurs exploitations par un attaquant et leurs points d’entrées.
Un bug est un défaut localisé qui est dû à une erreur d’implémentation d’un ser-vice (e.g., erreur de vérification des variables d’entrée, buffer overflow). Pour exploi-ter de tels défauts, l’attaquant tire parti de ces erreurs (e.g., injection de code mal-vaillant [84, 149]). À l’opposé, une faille de sécurité (ou faute de conception) est due
à une erreur dans la conception ou la définition des exigences [91]. Ainsi, indépen-damment de l’implémentation du service, un défaut introduit durant ce stade de la conception risque de persister tout au long du cycle de vie de l’application concernée. Par exemple, une application de vente en ligne qui stocke les informations d’achats (e.g., prix, nombre de produits) dans un cookie non sécurisé serait en défaut. En effet, une personne malicieuse peut modifier le prix de son achat sur le cookie malgré le fait que l’application soit bien implémentée.
Dans cette dernière catégorie de failles de sécurité, nous nous focalisons les failles logiques de sécurité définies par OWASP [72] comme étant le détournement de l’usage légitime d’un système à des fins malicieuses. L’adaptation de cette définition au par-cours d’authentification donne la définition suivante :
Une faille ou défaut logique d’authentification est une conséquence de l’usage légitime du parcours d’authentification de manière à ce que cet usage produit un impact négatif pour le service ou l’application concernée.
Du fait que le comportement logique d’une application varie en fonction du do-maine applicatif et du contexte, il advient que les failles logiques aussi varient d’une application à une autre. De plus, grâce à l’exemple illustratif, on constate également que ce détournement de l’usage légitime d’une application peut être dû aux choix d’usages de l’utilisateur ou aux choix de conception. Ainsi, intuitivement, nous cher-chons à vérifier si ces failles logiques peuvent être généralisées sur d’autres parcours d’authentification. Cela introduit la question suivante :
Dans quelles conditions les failles logiques peuvent mettre en dé-faut les parcours d’authentification des applications Web/Mobile ? Comment peut-on les caractériser ?
De l’étude empirique à l’ontologie des défauts logiques d’authentification
Pour répondre à la question posée dans la section précédente, nous conduisons une évaluation empirique du parcours d’authentification d’applications grands publiques. Cette étude empirique a permis, d’une part de généraliser l’existence de failles lo-giques sur ces applications. D’autre part, elle a permis de confirmer que ces failles de sécurité sont dues à des défauts de spécification qui ne prennent en considéra-tion ni le comportement de l’utilisateur final, ni les éléments de contexte qui peuvent modifier le schéma initial d’authentification et introduire de nouveaux risques. Ces découvertes introduisent la deuxième question de recherche à savoir :
RQ2 : Dans quelles mesures le processus de spécification pourrait-il prendre en considération les défauts de sécurité identifiés ?
Pour répondre à cette deuxième question, nous avons caractérisé les défauts lo-giques à l’aide d’une ontologie du parcours d’authentification, puis en déduire une taxonomie qui va permettre de capturer un ensemble d’exigences de sécurité spéci-fiques à ce contexte de défauts logiques de sécurité.
Ces exigences permettent de prendre en considération ces défauts logiques dès la phase de conception. En effet, parce que ces défauts logiques dépendent du concept de l’application, ils sont difficilement détectables par les méthodes de test et de dé-tection des vulnérabilités [91, 171]. De plus, notre enquête au sein des équipes de conception logiciel révèle que les parcours d’authentification ne sont pas formalisés durant la conception des applications et l’implémentation de ceux-ci est à la charge des développeurs. C’est tout naturellement que ces derniers ont recours à des frame-works ou des API d’authentification dont la conception initiale n’a pas prévu les failles logiques dont nous discutons dans cette thèse. Par conséquent, ces failles logiques ne sont jamais testées, et leur existence dans la vie réelle du parcours d’authentification est ignorée des concepteurs.
Par ailleurs, proposer des exigences sans un formalisme adéquat, peut entraîner des confusions quant à leur interprétation. De plus, cette thèse vise à réduire le gap entres les concepteurs et les développeurs en proposant des outils pour faciliter leurs échanges et permettre l’application des exigences pertinentes.
C’est à la recherche d’une telle approche que nous explorons la question de re-cherche suivante : RQ3 : Quelles approches permettent de spécifier les exigences de sécurité d’un parcours d’authentification ? Comment vérifier le res-pect ou non de ces exigences ?
Cette question de recherche sous-entend une approche qui soit capable de prévenir les défauts logiques dès la phase de conception. Pour cela, celle-ci doit permettre la spécification des exigences de sécurité capturées, mais aussi la sensibilisation des concepteurs sur les risques liés à cette spécification.
C’est dans ce contexte que nous proposons un cadre d’évaluation du niveau de risques des défauts logiques relatifs à une spécification d’un parcours d’authentifica-tion. Afin de valider ce cadre d’évaluation, nous proposons un langage dédié qui, d’une part, permet de spécifier un parcours d’authentification avec ces exigences de sécu-rité, et d’autre part, se fonde sur le cadre d’évaluation afin de donner l’évaluation du niveau de risque des attaques logiques et en même temps sensibiliser les concepteurs sur ces risques.
Les démarches proposées pour répondre à ces questions de recherche sont orga-nisées autour de trois contributions majeures.
Contributions
La Figure 1.4 présente une vue d’ensemble des différentes contributions détaillées ci-dessous.
Contribution 1 : Une taxonomie des exploitations logiques et une démarche d’ingénierie des exigences
Notre première contribution est une approche généraliste qui consiste à identi-fier les défauts logiques et à les caractériser en fonction des composants du parcours d’authentification que nous avons définis. Ensuite, nous proposons un ensemble d’exi-gences de sécurité dans le but de lutter contre ces défauts logiques dès la phase de conception du parcours d’authentification.
Contribution 2 : Un cadre d’évaluation du niveau de risques
La deuxième contribution s’inscrit dans le cadre de l’évaluation du niveau de sé-curité ou inversement du niveau de risque de la spécification d’un parcours d’authentification. En ce sens, elle propose un cadre d’évaluation du niveau de risque dont la sémantique se fonde, d’une part, sur la définition du parcours d’authentification et d’autre part, sur l’ensemble des exigences de sécurité que nous avons établi. Ce cadre permet ainsi d’évaluer la capacité de la spécification d’un parcours d’authentification à prévoir ou à éviter les classes de défauts logiques caractérisées dans la première contribution.
Contribution 3 : Un environnement de modélisation du parcours d’authentification
Enfin, la troisième et dernière contribution propose de formaliser la spécification d’un parcours d’authentification, via des abstractions adaptées, sous forme d’un en-vironnement de modélisation fondé sur un langage dédié. Ces abstractions dont la sémantique est fondée sur le cadre d’évaluation, offrent deux avantages : d’une part, elles permettent de spécifier le parcours d’authentification en prenant en compte les éléments de contexte et améliorent également la communication entre les concep-teurs et les experts sécurité, d’autre part, elles permettent de vérifier la satisfaction ou non des exigences de sécurité en fournissant un rapport d’évaluation des risques relatifs à cette spécification.
La sécurité des applications Web/Mobile
La sécurité occupe une place importante dans le processus de développement des applications en général. Fondamentalement, le but de la sécurité est de s’assurer des propriétés ci-après pour un système donné.
— La confidentialité stipule que seules les entités autorisées peuvent accéder en lecture aux ressources qui leurs sont destinées. Cette propriété est souvent traitée à l’aide des méthodes de chiffrement, de gestion des droits d’accès et des permissions [150, 182] ou par l’usage de protocoles d’échanges via des canaux sécurisés [46, 75, 145].
— L’authentification garantit que tout utilisateur d’un système doit prouver l’iden-tité qu’il revendique. Cette notion est différente de l’identification qui consiste à trouver l’identité d’une entité au sein d’un groupe [184].
— L’intégrité assure que les données échangées lors d’une communication sont telles qu’elles sont attendues. Autrement dit, que les données n’ont pas été altérées ni modifiées. La garantie de cette propriété est assurée à l’aide de fonctions de hachage ou de vérification de somme de contrôle (checksum en anglais).
— La disponibilité assure que l’accès aux ressources d’un système est garanti en permanence dans le temps imparti aux utilisateurs légitimes. Plusieurs aspects sont à prendre en considération pour garantir cette propriété ; les événements les plus redoutés sont les attaques de déni de service (i.e., DoS – Denial of Service) [127].
En plus de ces quatre propriétés fondamentales, d’autres propriétés peuvent être considérées notamment : la non-répudiation ou la traçabilité. Ceci étant dit, dans cette thèse nous nous focalisation sur la propriété d’authentification pour les raisons expli-quées dans l’introduction. Les protocoles cryptographiques sous-jacents ne sont pas dans le cadre de cette thèse, nous présentons ci-après l’état de l’art des différents méthodes d’authentification existantes.
Les Méthodes d’authentification
Fondamentalement, il existe deux types d’authentification : l’authentification mu-tuelle et l’authentification simple. Dans l’authentification mutuelle, les entités concer-nées s’authentifient mutuellement l’une auprès de l’autre. Cet aspect de l’authentifi-cation n’est pas traité dans cette thèse. En effet, nous nous focalisons sur l’authentifi-cation d’une entité pour accéder à un service : processus par lequel une entité prouve son identité auprès d’un vérifieur.
Ce type d’authentification comprend deux déclinaisons principales : l’authentifica-tion à un seul facteur et l’authentification à plusieurs facteurs. Un facteur d’authenti-fication étant :
— quelque chose que l’on connait : e.g., un mot de passe ;
— quelque chose que l’on est : e.g., un comportement unique (e.g., la manière de marcher) ou un attribut biométrique (i.e., empreinte digitale) ;
— quelque chose que l’on a : e.g., il s’agit d’un appareil physique (i.e., une clé physique) ou d’un ensemble d’information contenu dans un appareil physique protégé ou non (i.e., carte à puce). L’authentification fondée sur la connaissance d’un secret est parmi les moyens d’authentification les plus utilisés aujourd’hui. Cette utilisation massive est favorisée par sa facilité de déploiement, de gestion et de stockage comparée aux autres fac-teurs d’authentification. Celle-ci peut offrir un niveau de sécurité satisfaisant quand les exigences sont bien définies (e.g., qualité du secret, chiffrement). Cependant, elle peut aussi être source de faiblesse dans le système du fait de ces nombreuses li-mitations liées à la capacité de l’homme à retenir une succession de chiffres et de lettres [151, 96] ou à une mauvaise implémentation (i.e., absence de chiffrement, faible entropie [121]). Ci-après quelques exemples de méthodes d’authentification fon-dées sur la connaissance. Le mot de passe : Souvent associé à un identifiant, le mot de passe est le moyen d’authentification le plus utilisé pour garantir l’authenticité des entités utilisatrices d’une application web ou mobile. Malgré les nombreux avantages qu’il offre, le mot de passe est sujet à un risque majeur : le vol par une entité malicieuse (ou la découverte). Ce risque peut-être occasionné par l’utilisateur final ou par le fournisseur de service lui-même. Ci-après, la plupart des causes pouvant favoriser ce risque de vol.
— La réutilisabilité est l’usage d’un même mot de passe sur plusieurs services différents. Le problème majeur de cette pratique est l’effet domino que la com-promission de celui-ci peut causer [96]. En effet, si le mot de passe est compro-mis via un site avec une protection faible des mots de passe ou par négligence de l’utilisateur [1, 151], alors l’ensemble des autres services seront également compromis.
— L’absence de chiffrement ou protection anti-brute force : Dans leur étude sur les mécanismes d’authentification fondés sur le mot de passe, Bonneau et al. [22] montrent que sur 150 sites web étudiés, 84% n’ont pas de mécanisme anti brute force et 57% n’utilisent pas de TLS [46] pour sécuriser la transmission de ce mot de passe. De plus l’étude montre que 29% des sites web étudiés envoient en clair le mot de passe à l’utilisateur ce qui permet de constater que les mots de passe n’étaient pas hachés avant d’être stockés en base de données. Cette dernière pratique constitue un problème de sécurité (i.e., en cas de compromission de la base de données), mais aussi un problème d’atteinte à la vie privée (i.e., le fournisseur de service a accès aux mots de passe de ces utilisateurs).
— La qualité du mot de passe constitue aussi un aspect très important dans la politique de sécurité d’une authentification. En effet, si le choix du mot de passe est très contraignant, cela peut causer des problèmes de sécurité tels que mon-tré par Sasse et al. [1]. À l’inverse, ce mot de passe ne doit pas être faible sous peine de faciliter son exploitation par un utilisateur malicieux. Par conséquent, un compromis est nécessaire pour allier sécurité et utilisabilité [151, 48].
Le code pin : La particularité du code pin est qu’il est constitué uniquement de ca-ractères numériques, très souvent entre 4 et 8 chiffres. Il est moins sécurisé que le mot de passe en terme d’entropie, cependant dans certains contextes d’usage (e.g.verrouillage d’écrans) il est considéré comme d’un niveau de sécurité accep-table [20]. En effet, le code pin est souvent utilisé pour protéger des appareils qui sont souvent sous le contrôle de l’utilisateur légitime (i.e., téléphone portable). Par ailleurs, le code pin peut être facilement découvert par ingénierie sociale, surtout quand une personne malicieuse a accès aux données personnelles d’un utilisateur légitime (e.g., date de naissance, code postale) [21, 152]. Notons aussi que le code pin est souvent associé à d’autres facteurs (e.g., code pin et carte à puce) afin de renforcer la sécurité du mécanisme d’authentification.
La question secrète L’authentification via une question secrète se fonde sur la capacité à répondre à une question connue de l’utilisateur légitime et du vérifieur. Souvent fondée sur les préférences (e.g., date de naissance, ville préférée, nom de jeune fille de votre mère), elle est considérée comme très faible car facilement devi-nable [152, 98, 142]. Du fait qu’elle est plus facile à retenir que le mot de passe, la question secrète est beaucoup utilisée comme alternative pour récupérer un mot de passe ou un identifiant perdu ou révoqué [21]. Cependant, à cause de son niveau de sécurité faible, elle est exploitée pour frauduleusement accéder à une application [80].
L’authentification biométrique
L’authentification à facteur biométrique permet d’authentifier une personne en se fondant sur ses attributs physiologiques (e.g., empreinte digitale, le visage) ou sur ses attributs comportementaux (e.g., façon de parler, façon de marcher) [17].
Fondamentalement, un système d’authentification biométrique est constitué de deux phases : la phase d’enrôlement qui consiste à recueillir les points caractéris-tiques qui serviront de gabarit et la phase de comparaison où le gabarit préalablement stocké est comparé à la nouvelle acquisition [97] (Figure 2.1).
|
Table des matières
1 Introduction
1.1 Contexte
1.1.1 Le parcours d’authentification
1.1.2 Exemple illustratif
1.2 Problématique de la thèse
1.2.1 Vers les défauts logiques d’authentification
1.2.2 De l’étude empirique à l’ontologie des défauts logiques d’authentification
1.3 Contributions
1.3.1 Contribution 1 : Une taxonomie des exploitations logiques et une émarche d’ingénierie des exigences
1.3.2 Contribution 2 : Un cadre d’évaluation du niveau de risques
1.3.3 Contribution 3 : Un environnement de modélisation du parcours d’authentification
1.4 Organisation du document
2 Contexte et état de l’art
2.1 Éléments de contexte
2.1.1 La sécurité des applications Web/Mobile
2.1.2 Les Méthodes d’authentification
2.2 État de l’art
2.2.1 Taxonomie et ontologies des failles de sécurité
2.2.2 Défauts logiques de conception
2.2.3 Langage de modélisation
2.2.4 Ingénierie des exigences
2.2.5 Test et détection automatique de failles logiques
2.2.6 Failles logiques dans la sécurité et la vie privée
2.2.7 Évaluation du niveau de sécurité
2.3 Conclusion de l’état de l’art
3 Exigences de sécurité pour l’amélioration du parcours d’authentification
3.1 Étude empirique
3.1.1 Les critères de choix des applications
3.1.2 Démarche de l’étude empirique
3.1.3 Résultats de l’étude empirique
3.1.4 Conclusions de l’étude empirique
3.1.5 Atteintes à la validité
3.2 Caractérisation des exploitations logiques
3.2.1 Défauts logiques liés à la phase d’enregistrement
3.2.2 Défauts logiques liés au mécanisme d’authentification
3.2.3 Vers une ontologie du parcours d’authentification
3.3 Les exigences de sécurité
3.3.1 Exigences sur la vérification des attributs d’identité
3.3.2 Exigences sur les mécanismes d’authentification
3.4 Conclusion du chapitre
4 Cadre d’évaluation du niveau de risques des exploitations logiques relatives à un parcours d’authentification
4.1 Préambule
4.1.1 Définition du niveau de risque dans ce cadre
4.1.2 Critères d’évaluation du niveau de risque
4.2 Évaluation du niveau de risque de souscription d’une entité frauduleuse
4.2.1 Évaluation du niveau de risque associé aux attributs d’identité numérique
4.2.2 Évaluation du niveau de risque associé aux attributs d’identité physique
4.2.3 Récapitulatif de l’évaluation du niveau de risque de souscription d’une entité frauduleuse
4.3 Évaluation du niveau de risque d’un accès non autorisé
4.3.1 Authentification à un facteur
4.3.2 Évaluation du niveau de risque associé à un mécanisme d’authentification à plusieurs facteurs
4.3.3 Évaluation du niveau de risque associé à une fédération d’identité
4.3.4 Niveau de risque d’un accès non autorisé : phase de login
4.3.5 Niveau de risque d’un accès non autorisé : phase de récupération d’une preuve d’identité
4.3.6 Processus d’évaluation globale du niveau de risque d’un accès non autorisé
4.4 Usurpation d’identité : substitution de l’entité légitime
4.5 Conclusion du chapitre
5 Environnement de modélisation du parcours d’authentification
5.1 Concepts fondamentaux
5.2 Processus de description d’un parcours d’authentification
5.3 Concepts fondamentaux du DSL
5.3.1 Syntaxe abstraite et exigences
5.3.2 Syntaxe concrète
5.4 Processus d’évaluation du niveau de risque
5.4.1 Risque de souscription frauduleuse via la phase d’enregistrement
5.4.2 Risque d’accès non autorisé via la phase de login et la phase de mise à jour de preuves de sécurité
5.5 Risque de substitution de l’entité légitime via la phase de mise à jour
5.6 Conclusion du chapitre
6 Conclusion et Perspectives
6.1 Conclusion
6.2 Une ontologie pour améliorer l’écosystème du développement des parcours d’authentification
6.2.1 Cas d’usage
6.2.2 Implémentation et réponses aux questions
6.3 Vers la fin des cookies de session
Télécharger le rapport complet
