Gestion de l'identité : Utilisation de l'authentification à deux facteurs pour réduire les fraudes
Vous pouvez – et doit – utiliser l'authentification à deux facteurs avec les périphériques mobiles et de bureau.
Dan Griffin et Tom Jones
Au cœur de toutes les transactions sur le Web est le processus de gestion des fraudes. Il est essentiel d'équilibrer le désagrément d'authentification des utilisateurs avec le risque d'être usurpée. Pour mettre un autre passant, quand y a-t-il une connaissance suffisante de l'identité de l'utilisateur pour permettre la transaction de procéder ?
Authentifier l'identité d'un utilisateur est déjà un problème difficile face à l'évolution constante des attaques. Nous sommes maintenant au milieu d'un changement de paradigme majeur. Les appareils mobiles, les ordinateurs de bureau pas, sera la plate-forme pour la plupart des transactions.
Appareils mobiles créent de nouveaux obstacles à la sécurisation des services Internet. Claviers incompatibles et maladroits rendent incommode d'entrer des mots de passe complexes, alors que la plupart des appareils offrent des fonctionnalités pour « se souvenir » de mots de passe. Les périphériques mobiles sont également beaucoup plus facilement perdu ou volé, de matériel de bureau. De plus, les applications mobiles — y compris ceux qui peuvent avoir accès à des mots de passe sauvés — sont avérés difficiles à contrôler. Ces facteurs exposent les identités des utilisateurs à un risque supplémentaire.
Il y a une autre façon de voir la prolifération des appareils mobiles. Il n'est pas nécessairement un problème, mais une solution à des méthodes d'authentification précédente coincé dans une bataille perdue d'avance avec les développeurs de logiciels malveillants et les voleurs.
Le chemin de communication distincte — à savoir, le réseau cellulaire — à plus mobile permet de dispositifs vous fortifier les obstacles rencontrés par un logiciel malveillant. Vous pouvez utiliser ce chemin d'accès distinct pour lier l'utilisateur à un numéro de téléphone spécifique. Par la suite, la liaison de l'utilisateur-à-chiffres (ou tout simplement avoir une puce SIM spécifique) soit confirmée comme nécessaire lors des transactions en ligne. Cela se traduit par une augmentation exponentielle du nombre de tentatives qu'un attaquant devra monter pour obtenir le même niveau de succès.
Numéro de téléphone comme preuve
À l'aide de numéros de téléphone pour réduire la fraude en ligne n'est pas nouveau. Les banques ont été employant cette technique pour des années. Ce qui est nouveau est la possibilité pour tout service en ligne, petit ou grand, de facilement intégrer cette capacité.
Microsoft a récemment acquis PhoneFactor, une solution d'authentification à facteurs multiples par téléphone mobile. Il est maintenant disponible pour les clients comme Active l'authentification de Windows Azure. Avec PhoneFactor, lorsqu'un service en ligne nécessite l'authentification à deux facteurs, le téléphone peut fournir le deuxième facteur dans une variété de moyens :
- Le serveur effectue un appel automatisé vers le téléphone avec un message vocal, y compris un code secret unique. Puis, l'utilisateur tape le code dans un formulaire Web pour terminer la transaction en ligne désirée.
- Il peut également envoyer un message SMS, au lieu d'un message vocal, de transmettre le code une seule fois et de prouver la possession de l'utilisateur de l'appareil.
- Une variante du précédent processus consiste à configurer le système pour permettre à l'utilisateur répond directement au SMS (ou à un arbre de téléphone pendant un appel vocal). Cela évite d'avoir à mémoriser le code tout en passant d'un écran ou fenêtre à l'autre et d'avoir à faire une frappe supplémentaire. Au lieu de cela, le service Web en ligne est prévenu de façon asynchrone de la réponse SMS valide de l'utilisateur, et la transaction demandée, qui était en attente, est autorisée.
- Une application mobile prenant en charge les PhoneFactor peut recevoir et répondre correctement à un authentificateur du service cloud. À la différence des variations précédentes, cette approche exige explicitement un app smartphone installé sur le périphérique mobile.
- Vous pouvez transférer un jeton doux (tels que OAuth) envoyé vers le PC ou le téléphone pour le service consommant de la réclamation. Le serveur de PhoneFactor n'est pas impliqué dans la transmission du jeton et n'a pas même besoin de savoir où il est envoyé.
Compte tenu de l'hypothèse que la plupart des utilisateurs ont déjà leur téléphone la plupart du temps, l'avantage est une authentification multifacteur sans coût matériel différentiels habituels (jeton). Cette approche peut avoir des conséquences dramatiques sur votre courbe de risque/récompense de fraude.
Maintenant imaginez que vous êtes un écrivain malware essayer d'attaquer un site Web qui nécessite ce type d'authentification. Attaques typiques se concentrent sur l'appareil ou le chemin de communication vers le périphérique. Une attaque sur la connexion HTTP (TLS) ne suffit pas accéder au service Web parce que le code d'autorisation est envoyé par l'intermédiaire de cellules. Pour être réussie, une attaque doit compromettre les deux canaux.
Menaces émergentes
Il est bon de comprendre les menaces atténués par les nouvelles technologies, et comment et quand les nouvelles menaces sont introduits. Heureusement, rootkits n'ont pas encore pris un facteur dans la sécurité du téléphone. PhoneFactor fonctionne à la couche application et n'offre donc aucune atténuation des menaces de rootkit.
À l'app, niveau, ajout d'un deuxième facteur avec aucune voie de communications en commun avec d'autres facteurs est importante. Il est important de s'assurer il n'y a aucun code partagé entre les chemins d'accès. Cela signifie que l'utilisateur doit être associé à un certain niveau, soit en copiant un code pin d'un processus à l'autre ou en relevant un défi sur le téléphone qui est ensuite transmis à l'aide de l'un des mécanismes décrits ici.
Toute interaction qui n'implique pas un être humain dans le processus est ouverte aux attaques électroniques. En revanche, nouvelles menaces à l'un des chemins d'accès d'authentification n'entraînent pas une menace plus grande que ce qui est déjà posé par mots de passe statiques.
Parce que le code d'autorisation est différent sur chaque accès de chaque utilisateur, une attaque réussie de niveau application ne permet pas un accès sans entraves au service Web par l'attaquant. Ainsi, la valeur de l'attaque est réduite.
Attaquants sont intéressés par le meilleur rendement à moindre coût, donc à l'aide d'une authentification multifacteur encourage à chercher ailleurs une proie plus facile. En faisant une authentification multifacteur relativement peu coûteux à mettre en œuvre, des services comme PhoneFactor réduisent le risque une attaque va réussir.
Jouets fantaisies viennent souvent avec une mise en garde imprimée sur l'extérieur de la boîte : « Certains assemblage requis. » C'est la même chose avec PhoneFactor. Pour aider les grandes lignes aux exigences d'intégration typique, le reste de cet article décrit des solutions à l'aide de PhoneFactor dans les deux scénarios utilisateur différent.
Ouverture de session Web
Pour ouverture de session Web interopérable, l'objectif est d'utiliser PhoneFactor pour l'authentification forte. Ensuite, vous pouvez représenter l'identité de l'utilisateur avec un format de jeton Web standard. Vous pouvez utiliser PhoneFactor dans basé sur un navigateur Web scénarios d'authentification de la demande en attente, tandis que la partie arrière entre en contact avec le téléphone de l'utilisateur. Une fois que l'utilisateur s'authentifie, actualise la page Web et l'utilisateur est libre de procéder à des opérations sensibles.
Pour ce faire, l'application Web doit approuver le service PhoneFactor pour authentifier l'utilisateur. Il devra retourner une représentation de l'identité de l'utilisateur ou d'autres attributs de l'utilisateur. La mesure du possible, les applications Web devraient viser à utiliser des formats de jeton normalisé, comme SAML Security Assertion Markup Language () ou JSON Web Token (JWT). Cela contribue à rendre interopérables.
PhoneFactor avec Active Directory
PhoneFactor n'est pas seulement pour l'authentification sur le Web, cependant. Il peut aussi aider à sécuriser davantage l'authentification des utilisateurs sans trop d'inconvénients pour l'ouverture de bureau de Windows. Microsoft a depuis longtemps reconnu la nécessité de soutenir les méthodes d'authentification alternatives sur Windows.
L'API de fournisseur d'informations d'identification offre l'extensibilité. Pour lancer le processus, l'utilisateur télécharge un fournisseur d'informations d'identification (CP) à l'appareil. Lorsque l'utilisateur tente de se connecter, le CP envoie un message au service d'authentification dorsal, demandant un défi PhoneFactor. Le CP prévoit une zone d'édition pour l'utilisateur de saisir le code reçu sur son téléphone.
Une fois que le code est vérifié, le système d'authentification principal prend une étape supplémentaire de la délivrance d'un certificat d'infrastructure à clé publique (PKI) de courte durée pour l'utilisateur. Le CP utilise le certificat pour effectuer une ouverture de session Kerberos. Comme une couche supplémentaire de protection, vous pouvez avoir la clé privée du certificat lié à la puce de sécurité modèle de paramètre de Type (TPM) sur la machine cliente. Il peut également être lié à une broche aléatoire générée par le CP. Cela se traduit par une information d'identification non exportables, multifactorielle qui est interopérable avec le matériel et les applications existantes.
Cette approche a l'avantage de combler le fossé entre les PhoneFactor comme le nouveau mode d'authentification et de l'infrastructure Active Directory existante. Il existe plusieurs composants impliqués dans l'authentification à deux facteurs Windows desktop :
- L'utilisateur ouvre une session avec le mot de passe du domaine existant, en plus un code secret fourni par PhoneFactor. Ce modèle utilise un service Web de confiance pour gérer l'interaction entre le client et le serveur principal de PhoneFactor.
- Le CP acquiert un certificat de l'autorité de certification (AC) et se connecte à Windows Active Directory. Le service Web de confiance utilise le jeton SAML de Active Directory Federation Services (ADFS) pour acquérir le certificat pour l'ouverture de session Kerberos/PKINIT.
Même si ce scénario a l'utilisateur en saisissant le code PIN dans l'ordinateur joint au domaine, vous pouvez également installer une application de téléphone qui permet à l'utilisateur à accepter la demande au téléphone avec un simple clic.
Les avantages de l'authentification à deux facteurs sont bien connus, mais ont été difficiles à mettre en pratique en raison de la dépense en obtenant le deuxième facteur dans les mains des utilisateurs. Voici les deux façons d'étendre la nouvelle technologie de Microsoft PhoneFactor dans les royaumes de l'authentification de connexion intranet interactif, ainsi que d'ouverture de session Web normalisé.
.jpg)
Tom Jones a été le Président fondateur du sous-comité des normes nationales américaines ASC X9A10 sur les paiements électroniques. Il a travaillé au sein de la communauté de services financiers avec plusieurs organisations dont Electronic Data Interchange (EDI X 12) et Accredited Standards Committee X 9 Inc. sur les paiements électroniques, ainsi qu'avec First Data Corp., Intel Corp. et Microsoft.
.jpg)
**Dan Griffin**est le fondateur de JW Secure Inc. et une sécurité d'entreprise de Microsoft MVP. Il est l'auteur des livres « Cloud Security and Control » (CreateSpace Independent Publishing Platform, 2012) et « les quatre piliers de Endpoint Security : Protection de votre réseau à l'ère du Cloud Computing et l'amener-votre-propre-appareil tendance "(CreateSpace indépendant publiant plate-forme, 2013). Il est également un conférencier fréquent et blogueur sur jwsecure.com/dan.