e-Xpert Solutions Lausanne
Auteur : Michael Molho
Date de publication : 29 mars 2017 - Dernière mise à jour : 10 juillet 2018
e-Xpert Solutions est régulièrement sollicité pour implémenter des solutions de protection des applications web pour ses clients. Dans la phase de protection des accès, nous sommes souvent amenés à mettre en œuvre des mécanismes d’authentification forte et ainsi augmenter le niveau de sécurité des accès aux applications web. Dans cet article, nous présentons comment intégrer dans la solution F5 un mécanisme Multi facteur basé sur Google Authenticator.
Nos solutions supportent nativement de nombreux types d’authentifications fortes comme l’utilisation de certificats numériques, l’intégration de solution supportant le protocole RADIUS ou directement les tokens RSA SecurID. Le panel de solutions disponible pour l’entreprise est très large et, bien que présentant des niveaux de sécurité différents, les mécanismes suivants peuvent être mis en place :
La majorité des solutions reposent sur des serveurs tiers que l’entreprise doit installer sur des machines virtuelles ou physique séparées :
La solution basée sur Google Authenticator présente une particularité intéressante comparée aux autres solutions, elle ne nécessite pas de serveurs tiers pour fonctionner. L’utilisateur doit uniquement utiliser l’application mobile sur son smartphone ou sa tablette.
Google Authenticator n’est ni plus ni moins qu’une app mobile développée par Google et disponible sur les stores iOS et Android. Cette app se comporte comme un portefeuille de tokens. Une fois installée, elle génère des OTP valides quelques secondes pour s’authentifier sur ses applications ou sites web favoris :
Ce qui est intéressant avec cette application, c’est qu’elle n’est aucunement liée à Google ! Nul besoin d’avoir un compte Google, ni même d’être connecté à Internet pour pouvoir l’utiliser. Tout est hors ligne et il n’y a strictement aucune interaction avec les services de Google.
Cette app implémente en fait un algorithme Time Based One Time Password (TOTP) basé sur des standards définis par Initiative for Open Authentication (OATH). En effet, les OTP sont calculés en appliquant un algorithme basé sur :
Ainsi, à n’importe quel moment, l’app est capable, à partir de ces deux informations, de générer un code temporaire valide quelques seconds. Pour que l’authentification fonctionne, il faut donc :
A un instant donné, lorsque l’utilisateur soumet son code généré par l’app « Google Authenticator » au système de contrôle d’accès, ce dernier peut effectuer le même calcul basé sur l’heure courante et la chaine secrète de l’utilisateur pour vérifier si le code ainsi obtenu est le même que celui soumit par l’utilisateur.
Comme nous l’avons vu, cette authentification est basée sur le partage d’un code secret unique pour chaque utilisateur entre les mobiles et le serveur d’authentification. Il faut donc, à un moment donné, générer ces codes secrets et les transmettre aux utilisateurs. Cette étape s’appelle « l’enrôlement » des mobiles. C’est d’ailleurs la première chose que demande l’application « Google Authenticator » après l’installation : « Enter a provided key » :
Dans le principe, les codes secrets sont générés par le serveur d’authentification puis transmis de manière sécurisée à chaque utilisateur pour qu’il enregistre son mobile en utilisant le code personnel deliver.
Pour pouvoir mettre en place l’authentification Google Authenticator, il y a deux parties à mettre en place :
Plusieurs propositions d’implémentations existent déjà dans la communauté F5 (DevCentral).Pour stocker le secret de chaque utilisateur, la communauté propose actuellement deux alternatives :
L’option 1 nécessite une action manuelle de l’administrateur sur le F5 à chaque ajout/suppression d’utilisateur alors que l’option 2 est à bannir pour des raisons de sécurité.
Nous proposons ici une alternative qui offre à la fois un haut niveau de sécurité et une maintenance simplifiée. De manière classique, le code secret de chaque utilisateur est parfaitement aléatoire. Nous proposons une variante ou le code secret ne serait pas aléatoire mais dérivé d’informations sur l’utilisateur (son nom, son prénom, son téléphone, etc.) ainsi qu’une « master key » unique stockée de manière sécurisée sur le F5.
Exemple :
Master key = 74ce2e1a498f2fa27b5542040be774dc
code_secret(Michael Molho) = SHA1( MichaelMolho + 74ce2e1a498f2fa27b5542040be774dc )
De cette manière, tous les codes secrets n’ont plus besoin d’être stockés sur le F5 puisqu’ils peuvent être recalculés à la volée pour chaque utilisateur. Seule la « master key » doit être stockée. Ceci permet également de pouvoir générer très simplement des codes secrets pour des nouveaux utilisateurs en réduisant les efforts d’administration au maximum.
Nous avons donc développé un outil à destination des administrateurs permettant de calculer les codes secrets des utilisateurs afin de pouvoir leur transmettre de manière sécurisée et une irule sur F5 pour vérifier les OTP saisis par les utilisateurs.
Techniquement, pour générer un code secret d’un utilisateur, il suffit d’avoir son username et la « master key ». Les autres informations sont ensuite récupérées depuis l’annuaire d’entreprise (AD ou LDAP). Nous avons développé un outil en ligne de commande (disponible sous Windows et Linux) pour calculer le code secret d’un utilisateur à partir d’attributs de ce dernier (ex : username)
Dans l’exemple ci-dessus, l’administrateur doit ensuite de transmettre le code « HBRWIMJSME4WGZJS » à l’utilisateur « mmolho » pour qu’il puisse initialiser son application Google Authenticator sur son mobile.
Pour faciliter d’avantage l’enrôlement des utilisateurs, nous offrons des options dans l’outil pour :
Au niveau du contrôle d’accès réalisé par les équipements F5, l’administrateur doit configurer une page de logon pour demander le code généré par l’app Google Authenticator. L’exemple ci-dessous montre le processus d’authentification par nom d’utilisateur et mot de passe suivi du code Google Authenticator :
Le produit F5 étant extrêmement flexible, l’administrateur peut envisager plusieurs workflow d’authentifications différents.
Dans notre cas, nous avons ajouté un block « AD Query » nous permettant de récupérer des attributs utilisateur dans l’annuaire Active Directory. Pour finir, nous intégrons la logique d’authentification Google Authenticator en ajoutant une page de logon pour demander le code généré par l’app Google.
Le bloc « Verify MFA Token » est un bloc de type « iRule Event » qui va appeler une iRule chargée de vérifier la validité de l’OTP. Cette iRule contient la master key.
L’utilisateur se rend sur le site web. N’étant pas authentifié, il est redirigé sur la page de logon F5 demandant une authentification par nom d’utilisateur et mot de passe.
Une fois authentifié auprès de l’Active Directory, nous demandons à l’utilisateur de rentrer son code Google Authenticator.
L’utilisateur ouvre son application mobile « Google Authenticator » et génère un code de vérification. Il devra ensuite l’entrer dans la page de logon pour être authentifié.
En cas d’authentification réussie, l’utilisateur est redirigé sur le site web demandé.
L’intégration de Google Authenticator avec les solutions F5 est relativement simple. En ajoutant quelques développements internes, nous avons optimisé le processus d’enrôlement des utilisateurs et ainsi simplifié les tâches administratives des techniciens en charge de l’exploitation de ces solutions. Cette intégration n’est qu’un exemple de ce que nous sommes en mesure de réaliser en mixant les technologies F5 et nos compétences.
Events
Archives