Considérations de sécurité lors de l'authentification

L'authentification – login est l'un des vecteurs les plus prolifiques de vulnérabilités de sécurité dans les applications et les sites Web. L'accès à des données et fonctionnalités importantes pourrait être très rentable, donc compromettre les informations d'identification des utilisateurs est une cible de choix car nous ont vu dans le passé. Voici quelques pièges à éviter lors de la conception de votre interface d'authentification.

Contrôles de mot de passe appropriés

Forcez vos utilisateurs à choisir des mots de passe forts ! Une bonne politique de mot de passe rend les attaques par force brute et par dictionnaire (c'est-à-dire, deviner le mot de passe d'un utilisateur par des moyens manuels ou automatisés) peu pratiques. La restriction la plus importante est de définir la longueur minimale autorisée à 8 caractères, et cela doit être fait à tout moment. En dehors de cela, voici quelques restrictions courantes qui tentent de garantir un mot de passe adéquat avec une complexité minimale :

• Un mélange de lettres majuscules et minuscules.
• Un mélange de lettres et de chiffres.
• Au moins un caractère spécial : !@#$%^&*() etc.

Pourtant, il a été trouvé par recherche parrainée par le NIST américain ¹ que les utilisateurs ont tendance à réagir à ces restrictions supplémentaires de manière très prévisible. Par exemple, si un utilisateur avait l'intention d'utiliser le mot de passe "password", mais rencontrait les restrictions ci-dessus, il changerait probablement son mot de passe pour le prévisible "Password1!".
Le NIST suggère de comparer le mot de passe à une liste noire de mots de passe inacceptables et de rejeter les mots de passe qui correspondent. Devis:

Cette liste doit inclure les mots de passe des corpus de violation précédents, des mots du dictionnaire et des mots spécifiques (tels que le nom du service lui-même) que les utilisateurs sont susceptibles de choisir. Étant donné que le choix des mots de passe par l'utilisateur sera également régi par une exigence de longueur minimale, ce dictionnaire n'a besoin d'inclure que les entrées répondant à cette exigence.

NIST

L'implémenter vous-même peut être une tâche ardue, mais heureusement, il existe des services et des bibliothèques conçus pour vous aider. La zxcvbn bibliothèque disponible dans de nombreuses langues est une option. La Pwned La base de données de mots de passe contient des centaines de millions de mots de passe piratés, par rapport auxquels vous pouvez vérifier le mot de passe choisi par l'utilisateur. Vous pouvez soit l'héberger localement, soit utiliser un API pour communiquer avec lui (en utilisant des hachages bien sûr !).

Si vous vous attendez à ce que vos utilisateurs parlent des langues qui utilisent soit un alphabet non latin, soit du latin étendu (avec des signes diacritiques ou des lettres spéciales comme ø, æ, œ), autoriser théoriquement la palette complète de caractères Unicode améliorera la sécurité. Cela empêchera la plupart des attaques par force brute, qui supposent de toute façon les normes ASCII, et augmentera également considérablement le nombre de combinaisons possibles². Bien que cela puisse sembler une évidence, en pratique, vous devez tenir compte du fait que vous pouvez ne pas gérer correctement UTF-8 (par exemple, la gestion de caractères canoniquement équivalents). Une mauvaise gestion d'Unicode pourrait réduire la convivialité et même avoir un impact négatif sur la sécurité. Ne le faites que si vous avez confiance en vos capacités.
Enfin, il est important de définir une restriction de longueur maximale. Ne pas le faire peut vous exposer à un mot de passe long DOS attaque. 64 caractères est une bonne limite supérieure.

Hachage de mot de passe

La première règle de stockage des informations d'identification est de ne jamais stocker de mots de passe bruts sur le serveur. Au lieu de cela, stockez les hachages pour l'authentification. Le hachage est une bien meilleure méthode que de restreindre l'utilisation de certains caractères spéciaux.

Pour remettre les pendules à l'heure : le hachage est ne sauraient chiffrement. Le hachage est une fonction à sens unique qui associe chaque mot de passe à un hachage unique ou presque toujours unique (oui, des hachages contradictoires ont été découverts avec certaines fonctions de hachage, et c'est un vecteur d'attaque, le choix de la fonction est donc important). Alors que le cryptage peut être inversé pour obtenir le mot de passe d'origine. À cette fin, les mots de passe bruts ne doivent jamais être stockés chiffrés sur le serveur.

Pour stocker un mot de passe, il doit être haché sur le serveur (peut aller jusqu'à 10,000 XNUMX itérations). Le hachage côté client n'a que des avantages marginaux ; un attaquant man-in-the-middle (MITM) peut simplement saisir le hachage et l'envoyer au serveur pour se connecter comme un utilisateur légitime. Cela pourrait empêcher le mot de passe réel de fuir et d'être réutilisé pour ouvrir d'autres services, mais pour la sécurité d'une application spécifique, cela a un faible effet tout en ajoutant de la complexité. Le hachage côté serveur est plus puissant car un attaquant ne connaît pas votre configuration de hachage sur le serveur, donc même si tous vos hachages fuient, il ne peut toujours pas s'authentifier. Cela devrait être considéré comme obligatoire.

Même si toutes les étapes ci-dessus sont suivies, il est important de se préparer à la cause possible de la fuite de votre base de données avec les hachages : un attaquant peut alors forcer brutalement les hachages. Ceci est fait par

1. Hachage d'un mot de passe candidat.
2. Tester si le hachage correspond à un mot de passe dans la base de données.

Le salage des hachages est donc important. Le salage consiste à concaténer une chaîne aléatoire au mot de passe, à hacher le résultat, puis à stocker le hachage avec le sel dans la base de données. L'attaquant est alors incapable de vérifier le hachage d'un éventuel mot de passe par rapport à chaque hachage de la base de données. Au lieu de cela, il doit ajouter le sel d'un utilisateur au mot de passe proposé, le hacher, puis le tester par rapport au hachage de l'utilisateur, le forçant à déchiffrer un hachage à la fois. Les fonctions modernes de hachage de mot de passe salent généralement automatiquement l'entrée avant le hachage.

Les meilleurs étirement des touches algorithmes disponibles aujourd'hui pour les mots de passe sont Argon2id ³, qui a remporté l'édition 2015 Concours de hachage de mot de passeet une PBKDF2 ⁴, qui est recommandé par le NIST. Ceux-ci utilisent des fonctions de hachage simples comme SHA256 en tant que «backends», mais les appliquent des milliers de fois et ajoutent automatiquement du sel. Par conséquent, n' utilisez directement des fonctions de hachage simples comme SHA ou MD5 non conçues pour les mots de passe, ni n'essayez de construire vos propres méthodes d'étirement de clé, c'est une course folle.

TLS et authentification

Une autre précaution obligatoire lors de l'authentification consiste à s'assurer que l'ensemble de la transaction passe par TLS, ce qui rend les attaques HTTP MITM beaucoup plus difficiles en exigeant des certificats.

TLS (Transport Layer Security) est le protocole successeur de SSL (Secure Socket Layer). En bref, TLS comprend d'abord une procédure de prise de contact qui oblige le serveur à envoyer un certificat d'une autorité de confiance qui se porte garant de sa légitimité. Les clés de chiffrement sont ensuite échangées à l'aide du Méthode Defie-Hellman (les clés publiques et privées sont générées). Le reste de la session est ensuite crypté et décrypté à l'aide de ces clés.

Comment implémenter correctement TLS pour votre service est un sujet en soi, nous n'en parlerons donc pas aujourd'hui, mais vous pouvez lire par vous-même le les meilleures pratiques.

Authentification multi-facteurs

De loin, le meilleur moyen d'éviter les problèmes de sécurité des mots de passe est de recommander ou d'exiger l'authentification multifacteur (MFA). Cela signifie utiliser une ou plusieurs autres méthodes afin d'authentifier l'utilisateur. Cela peut inclure l'utilisation d'e-mails, de SMS, de codes QR, de scans biométriques et d'applications d'authentification. La façon la plus courante de le faire est d'utiliser un e-mail ou un SMS pour envoyer à l'utilisateur un OTP qu'il devra saisir pour y accéder. Un attaquant devrait alors avoir accès à l'e-mail de l'utilisateur afin d'accéder à votre service.
Cela ouvre d'autres vecteurs d'attaque, mais pour la plupart des applications, cela devrait suffire.

Une façon de réduire les frais généraux supportés par l'authentification MFA pour le développeur et l'utilisateur consiste à n'exiger l'authentification MFA que lors de transactions importantes. Par exemple, lorsque

• Modification des mots de passe.
• Effectuer des transactions monétaires.
• Désactivation de MFA.
• Obtention d'un accès administrateur.

Il est également possible de mandater MFA uniquement tous les deux jours, après une longue période d'inactivité ou après des tentatives de connexion infructueuses (avec l'avantage d'empêcher la force brute). 

Prévention des robots

Une façon d'empêcher les tentatives de connexion automatisées, que ce soit dans le cadre d'une attaque par force brute ou du DOS, consiste à implémenter des délais d'attente après plusieurs tentatives infructueuses. Cela rend les attaques par force brute et par dictionnaire tout simplement trop longues pour être réalisables. Une autre possibilité consiste à demander à l'utilisateur de résoudre un captcha lors de chaque connexion, ou peut-être après un nombre prédéterminé de tentatives infructueuses. 

Le service de captcha tiers le plus populaire est peut-être le reCAPTCHA de Google, mais il a vu quelques critiques pour ses politiques de confidentialité. reCAPTCHA oblige également efficacement vos utilisateurs à accepter un accord de conditions d'utilisation de tiers afin d'utiliser votre service, ce que certains considèrent comme problématique sur le plan éthique. Pourtant, l'utilisation de reCAPTCHA est probablement le moyen le plus simple et l'un des plus fiables d'empêcher les spams ou les bots de force brute. Il existe d'autres solutions Captcha en ligne, comme hCaptcha, mais en tant que solutions tierces, elles pourraient toutes souffrir des mêmes problèmes que reCAPTCHA.

Messages d'erreur

Pour empêcher les attaquants de déterminer si un nom d'utilisateur est valide ou non, il est recommandé d'avoir un seul message d'erreur ambigu, que l'erreur soit due ou non à

• Le mot de passe était incorrect.
• Le compte n'existe pas.
• Le compte est verrouillé, désactivé ou banni.

Un message d'erreur approprié et sécurisé serait quelque chose comme

"Login failed; Invalid user ID or password."

La restauration de compte ne doit également jamais reconnaître si le processus a été un succès ou non, mais plutôt envoyer des réponses telles que

"If that email address is in our database, we will send you an email to reset your password."

Et

"A link to activate your account has been emailed to the address provided."

Respectivement.

Même si vos messages d'erreur sont vagues, un attaquant tenace peut tenter de comparer les écarts de temps de réponse pour déterminer si le mot de passe est erroné ou si le compte n'existe pas. Par exemple, ce pseudo-code

if (user_exists(username)) {
    String password_hash = hash(password);
    bool valid = lookup_credentials(username, password_hash);
    if (!valid) {
        return Error("Invalid Username or Password!");
    }
} else {
   return Error("Invalid Username or Password!");
}

Reviendra plus vite si l'utilisateur n'existe pas, ce que l'attaquant peut exploiter, alors que ce code

String password_hash = hash(password);
bool valid = lookup_credentials(username, password_hash);
if (!valid) {
   return Error("Invalid Username or Password!");
}

Cela prendra à peu près le même temps dans les deux cas.

Authentification par authentification unique

Ces dernières années, une méthode d'authentification connue sous le nom de Single Sign-On est devenue à la mode. Lorsqu'un utilisateur souhaite se connecter à votre service, il est invité à choisir un fournisseur d'identité de confiance, généralement une méga-entreprise qui propose ce service, comme Google, Amazon ou Facebook. L'utilisateur est alors redirigé vers le site Web du fournisseur d'identité et doit s'y connecter en utilisant son compte. Le fournisseur d'identité envoie ensuite à votre service une garantie que l'utilisateur est autorisé, généralement sous la forme d'un schéma XML, qui fournit également des détails sur l'identité de l'utilisateur. Il existe plusieurs protocoles pour ce faire, mais le plus populaire est de loin OpenID.

Le principal avantage est la facilité d'utilisation. L'utilisateur n'a qu'à maintenir un seul compte avec un seul mot de passe pour accéder à de nombreux services différents. De plus, si l'utilisateur est déjà connecté à ce compte, il n'a pas besoin de ressaisir ses informations d'identification. Cela permet également à l'utilisateur de retenir un mot de passe unique pour tous ses comptes. Un autre avantage pour le développeur est de réduire le besoin de s'occuper lui-même de l'autorisation. Au lieu de cela, vous le déléguez à un tiers de confiance comme Google.

Mais cette approche présente certains inconvénients en matière de sécurité : le plus flagrant est le fait que si le compte du fournisseur d'identité de l'utilisateur est piraté, une myriade d'autres services peuvent également être accessibles par l'attaquant. Cela a le même effet que d'utiliser le même mot de passe et le même nom d'utilisateur sur tous les comptes, une pratique qui est néanmoins pratiquée par de nombreux utilisateurs de toute façon.

De nombreux sites Web modernes proposent fréquemment à la fois des comptes SSO et des comptes à service unique traditionnels, laissant le choix à l'utilisateur.