Authentification multi-facteurs

Les attaques de pirates informatiques ne sont plus rares de nos jours. Il est donc d’autant plus important de bien protéger les données sans augmenter massivement l’effort requis pour y accéder.

La sécurité devrait être un enjeu pour tous (particuliers et entreprises). Un gros problème est que souvent un (1) seul mot de passe ou certificat/clé est utilisé. Si cette information est volée, le voleur peut s’authentifier sur tous les systèmes. C’est exactement là qu’une authentification multifactorielle, souvent appelée aussi authentification à deux facteurs, entre en jeu. L’objectif est d’avoir plusieurs facteurs qui ne sont jamais maintenus ensemble. Si l’un des facteurs est également dynamique (mot de passe unique ou procédure de réponse au défi), cela devrait également empêcher les attaques dites de rejeu.

En principe, une authentification multifactorielle peut également être réalisée avec un mot de passe et un certificat. Pour SSH par exemple avec mot de passe et clé RSA, sur le Web avec mot de passe et certificats x509. Dans ce qui suit, cependant, les mots de passe uniques et les procédures de réponse aux défis seront discutés, qui nécessitent un composant matériel supplémentaire. L’idée ici est qu’un mot de passe (le facteur connaissance) et un matériel (le facteur possession) sont dans le jeu, ce qui rend le vol simple prévenir.

FIDO U2F

FIDO U2F est un tout nouveau protocole basé sur la cryptographie à clé publique. Un support natif dans le navigateur (actuellement uniquement dans Chrome / Chromium et via Addon dans Firefox) est requis. Théoriquement, il peut également être utilisé pour les sciences humaines et d’autres services. Ici aussi, la condition préalable est que les programmes le soutiennent nativement. Des correctifs appropriés pour le client OpenSSH sont déjà disponibles.
Une fois l’authentification par mot de passe ou certificat réussie, le serveur envoie un défi unique au client, après quoi le client renvoie au serveur une réponse signée avec sa propre clé privée.

OATH

OATH a deux protocoles, l’algorithme de mot de passe à usage unique basé sur le temps TOTP (RFC6238) et l’algorithme de mot de passe à usage unique basé sur HMAC HOTP (RFC4226).
Tout d’abord, un secret partagé est échangé entre le serveur et le client. Ceci est souvent réalisé par un code QR.

TOTP

Avec TOTP, le temps est utilisé comme base. La condition préalable est que l’heure soit synchronisée entre le serveur et le client.
Le code d’authentification est généré avec la fonction suivante : HMAC(sharedSecret, timestamp) et est valide pendant 30 secondes.

HOTP

HOTP fonctionne de la même manière que TOTP, mais utilise un compteur au lieu du temps, qui doit toujours être synchrone du côté serveur et client.
Le code d’authentification est généré par la fonction suivante : HMAC(sharedSecret, counter) et est valide pour le login suivant (indépendant du temps).

Mot de passe à usage unique (OTP)

Les mots de passe à usage unique (OTP) sont une méthode simple de Yubico, qui nécessite une infrastructure supplémentaire en arrière-plan. Une fois l’authentification par mot de passe ou certificat réussie, le serveur a toujours besoin d’un OTP. S’il est envoyé, le serveur doit le transmettre à un serveur de validation pour le contrôle d’unicité.

Par exemple, trois ANP du même Yubikey ressemblent à ceci :
<b>rjvrllbbckhe</b>flnbdhnbdgluhedfneecjrluudknuecu
<b>rjvrllbbckhe</b>nrvblgfvkcbdhbtnjegvdicnhcutundg
<b>rjvrllbbckhe</b>lvrdjdrjccrvkrlbiijictlullglfglj

Les 12 premiers caractères de la séquence sont le nom public et le reste de la séquence est généré en utilisant une clé AES et un compteur. La clé AES doit être connue de Yubikey et du serveur de validation (en particulier le yubikey-ksm).
A chaque OTP le compteur est donné, afin que le serveur puisse synchroniser son compteur.

Serveur de validation

Le logiciel serveur de validation de Yubico yubikey-val et yubikey-ksm peut être facilement hébergé par vous-même. Vous pouvez également utiliser le YubicoCloud, qui est hébergé et offert par Yubico lui-même.
Dans le cas d’une infrastructure critique, il est plus logique d’héberger le système vous-même, en termes de sécurité. Il s’agit moins de la protection des données que de la disponibilité. Si, par exemple, la connexion Internet est interrompue et qu’une connexion par authentification à deux facteurs avec OTP est nécessaire pour réparer le pare-feu, vous êtes dans une impasse et n’avez plus de connexion à Internet.