PARTIE I: Comment se connecter
Nous supposerons que vous savez déjà comment créer un formulaire HTML de connexion + mot de passe qui POSTE les valeurs dans un script côté serveur pour l'authentification. Les sections ci-dessous traiteront des modèles d'authentification pratique et expliquent comment éviter les pièges de sécurité les plus courants.
Pour HTTPS ou pas pour HTTPS?
À moins que la connexion ne soit déjà sécurisée (c'est-à-dire tunnelée via HTTPS à l'aide de SSL / TLS), les valeurs de votre formulaire de connexion seront envoyées en texte clair, ce qui permet à toute personne qui écoute sur la ligne entre le navigateur et le serveur Web de pouvoir lire les connexions au fur et à mesure de leur passage par. Ce type d'écoute électronique est effectué de manière routinière par les gouvernements, mais en général, nous ne traiterons pas des fils «détenus» autrement que pour dire ceci: utilisez simplement HTTPS.
En substance, le seul moyen pratique de se protéger contre l'écoute électronique / le reniflement de paquets pendant la connexion est d'utiliser HTTPS ou un autre schéma de chiffrement basé sur certificat (par exemple, TLS ) ou un schéma de réponse-défi éprouvé (par exemple, le Diffie-Hellman SRP). Toute autre méthode peut être facilement contournée par un attaquant indiscret.
Bien sûr, si vous êtes prêt à devenir un peu impraticable, vous pouvez également utiliser une forme de schéma d'authentification à deux facteurs (par exemple, l'application Google Authenticator, un livre de codes physique `` style guerre froide '' ou un dongle de générateur de clé RSA). Si appliqué correctement, cela pourrait fonctionner même avec une connexion non sécurisée, mais il est difficile d'imaginer qu'un développeur serait prêt à implémenter l'authentification à deux facteurs mais pas SSL.
(Ne pas faire) Chiffrement / hachage JavaScript à votre guise
Étant donné le coût perçu (mais désormais évitable ) et la difficulté technique de la mise en place d'un certificat SSL sur votre site Web, certains développeurs sont tentés de lancer leurs propres schémas de hachage ou de chiffrement dans le navigateur afin d'éviter de passer des connexions en texte clair sur un câble non sécurisé.
Bien que ce soit une pensée noble, elle est essentiellement inutile (et peut être une faille de sécurité ) à moins qu'elle ne soit combinée avec l'une des solutions ci-dessus - c'est-à-dire, sécuriser la ligne avec un cryptage fort ou utiliser une réponse-défi éprouvée mécanisme (si vous ne savez pas ce que c'est, sachez simplement que c'est l'un des concepts les plus difficiles à prouver, les plus difficiles à concevoir et les plus difficiles à mettre en œuvre en matière de sécurité numérique).
S'il est vrai que le hachage du mot de passe peut être efficace contre la divulgation du mot de passe , il est vulnérable aux attaques de réexécution, aux attaques / détournements de Man-In-The-Middle (si un attaquant peut injecter quelques octets dans votre page HTML non sécurisée avant qu'elle n'atteigne votre navigateur, ils peuvent simplement commenter le hachage dans le JavaScript), ou les attaques par force brute (puisque vous remettez à l'attaquant à la fois le nom d'utilisateur, le sel et le mot de passe haché).
CAPTCHAS contre l'humanité
CAPTCHA est destiné à contrecarrer une catégorie spécifique d'attaque: dictionnaire automatisé / essais et erreurs par force brute sans opérateur humain. Il ne fait aucun doute qu'il s'agit d'une menace réelle, cependant, il existe des moyens de le gérer de manière transparente qui ne nécessitent pas de CAPTCHA, des schémas de limitation de connexion côté serveur spécifiquement conçus - nous en discuterons plus tard.
Sachez que les implémentations CAPTCHA ne sont pas créées de la même manière; ils ne sont souvent pas résolubles par l'homme, la plupart d'entre eux sont en fait inefficaces contre les robots, tous sont inefficaces contre la main-d'œuvre bon marché du tiers monde (selon l' OWASP , le taux d'atelier actuel est de 12 $ pour 500 tests), et certaines mises en œuvre peuvent être techniquement illégale dans certains pays (voir la feuille de triche d'authentification OWASP ). Si vous devez utiliser un CAPTCHA, utilisez reCAPTCHA de Google , car il est difficile par définition de l'OCR (car il utilise des numérisations de livres déjà classées de manière incorrecte par l'OCR) et essaie très fort d'être convivial.
Personnellement, j'ai tendance à trouver CAPTCHAS ennuyeux et à ne les utiliser qu'en dernier recours lorsqu'un utilisateur n'a pas réussi à se connecter plusieurs fois et que les délais de limitation sont maximisés. Cela se produira rarement assez pour être acceptable, et cela renforce le système dans son ensemble.
Stockage des mots de passe / vérification des connexions
Cela peut finalement être de notoriété publique après tous les hacks très médiatisés et les fuites de données utilisateur que nous avons vues ces dernières années, mais il faut dire: ne stockez pas les mots de passe en texte clair dans votre base de données. Les bases de données des utilisateurs sont systématiquement piratées, divulguées ou glanées par injection SQL, et si vous stockez des mots de passe bruts et en texte clair, c'est un jeu instantané pour votre sécurité de connexion.
Donc, si vous ne pouvez pas stocker le mot de passe, comment vérifiez-vous que la combinaison login + mot de passe POSTÉE à partir du formulaire de connexion est correcte? La réponse est le hachage à l'aide d'une fonction de dérivation de clé . Chaque fois qu'un nouvel utilisateur est créé ou qu'un mot de passe est modifié, vous prenez le mot de passe et l'exécutez via un KDF, tel que Argon2, bcrypt, scrypt ou PBKDF2, transformant le mot de passe en texte clair ("correcthorsebatterystaple") en une chaîne longue et aléatoire , ce qui est beaucoup plus sûr à stocker dans votre base de données. Pour vérifier une connexion, vous exécutez la même fonction de hachage sur le mot de passe entré, en passant cette fois le sel et comparez la chaîne de hachage résultante à la valeur stockée dans votre base de données. Argon2, bcrypt et scrypt stockent déjà le sel avec le hachage. Consultez cet article sur sec.stackexchange pour des informations plus détaillées.
La raison pour laquelle un sel est utilisé est que le hachage en soi n'est pas suffisant - vous voudrez ajouter un soi-disant «sel» pour protéger le hachage contre les tables arc-en-ciel . Un sel empêche efficacement deux mots de passe qui correspondent exactement d'être stockés sous la même valeur de hachage, empêchant toute la base de données d'être analysée en une seule fois si un attaquant exécute une attaque de devinette de mot de passe.
Un hachage cryptographique ne doit pas être utilisé pour le stockage de mot de passe car les mots de passe sélectionnés par l'utilisateur ne sont pas assez forts (c'est-à-dire qu'ils ne contiennent généralement pas assez d'entropie) et une attaque de devinette de mot de passe pourrait être terminée en un temps relativement court par un attaquant ayant accès aux hachages. C'est pourquoi les KDF sont utilisés - ceux-ci "étirent la clé" , ce qui signifie que chaque mot de passe deviné par un attaquant provoque plusieurs répétitions de l'algorithme de hachage, par exemple 10 000 fois, ce qui oblige l'attaquant à deviner le mot de passe 10 000 fois plus lentement.
Données de session - "Vous êtes connecté en tant que Spiderman69"
Une fois que le serveur a vérifié la connexion et le mot de passe par rapport à votre base de données d'utilisateurs et trouvé une correspondance, le système a besoin d'un moyen de se rappeler que le navigateur a été authentifié. Ce fait ne doit jamais être stocké côté serveur dans les données de session.
Si vous n'êtes pas familier avec les données de session, voici comment cela fonctionne: une seule chaîne générée de manière aléatoire est stockée dans un cookie expirant et utilisée pour référencer une collection de données - les données de session - qui sont stockées sur le serveur. Si vous utilisez un framework MVC, cela est sans aucun doute déjà géré.
Dans la mesure du possible, assurez-vous que le cookie de session a les indicateurs sécurisé et HTTP uniquement définis lorsqu'il est envoyé au navigateur. L'indicateur HttpOnly offre une certaine protection contre la lecture du cookie lors d'une attaque XSS. L'indicateur sécurisé garantit que le cookie est renvoyé uniquement via HTTPS et protège donc contre les attaques de reniflement du réseau. La valeur du cookie ne doit pas être prévisible. Lorsqu'un cookie référençant une session inexistante est présenté, sa valeur doit être remplacée immédiatement pour éviter la fixation de la session .
PARTIE II: Comment rester connecté - La fameuse case à cocher "Se souvenir de moi"
Les cookies de connexion persistants (fonctionnalité "se souvenir de moi") sont une zone de danger; d'une part, ils sont entièrement aussi sûrs que les connexions conventionnelles lorsque les utilisateurs savent comment les gérer; et d'autre part, ils représentent un énorme risque pour la sécurité entre les mains d'utilisateurs imprudents, qui peuvent les utiliser sur des ordinateurs publics et oublier de se déconnecter, et qui peuvent ne pas savoir ce que sont les cookies du navigateur ou comment les supprimer.
Personnellement, j'aime les connexions persistantes pour les sites Web que je visite régulièrement, mais je sais comment les gérer en toute sécurité. Si vous êtes certain que vos utilisateurs savent la même chose, vous pouvez utiliser des connexions persistantes avec une conscience propre. Si ce n'est pas le cas - eh bien, vous pouvez souscrire à la philosophie selon laquelle les utilisateurs négligents avec leurs identifiants de connexion s'en sont chargés s'ils étaient piratés. Ce n'est pas comme si nous allions chez nos utilisateurs et que nous déchirions toutes ces notes Post-It induisant le visage avec des mots de passe qu'ils ont alignés sur le bord de leur moniteur.
Bien sûr, certains systèmes ne peuvent pas se permettre d'avoir des comptes piraté; pour de tels systèmes, il n'y a aucun moyen de justifier d'avoir des connexions persistantes.
Si vous décidez de mettre en place des cookies de connexion persistants, voici comment procéder:
Tout d'abord, prenez le temps de lire l'article de Paragon Initiative sur le sujet. Vous aurez besoin d'obtenir un bon nombre d'éléments, et l'article fait un excellent travail pour expliquer chacun.
Et juste pour réitérer l'un des pièges les plus courants, NE PAS STOCKER LE COOKIE DE CONNEXION PERSISTANT (JETON) DANS VOTRE BASE DE DONNÉES, SEULEMENT UN HASH OF IT! Le jeton de connexion est équivalent au mot de passe, donc si un attaquant mettait la main sur votre base de données, il pourrait utiliser les jetons pour se connecter à n'importe quel compte, comme s'il s'agissait de combinaisons de mot de passe de connexion en texte clair. Par conséquent, utilisez le hachage (selon https://security.stackexchange.com/a/63438/5002, un hachage faible fera très bien l'affaire à cette fin) lors du stockage de jetons de connexion persistants.
PARTIE III: Utilisation de questions secrètes
Ne mettez pas en œuvre des «questions secrètes» . La fonction «questions secrètes» est un anti-modèle de sécurité. Lisez l'article du lien numéro 4 de la liste à lire absolument. Vous pouvez demander à Sarah Palin à ce sujet, après son Yahoo! Le compte de messagerie a été piraté lors d'une précédente campagne présidentielle parce que la réponse à sa question de sécurité était ... "Wasilla High School"!
Même avec des questions spécifiées par l'utilisateur, il est très probable que la plupart des utilisateurs choisissent:
Une question secrète «standard» comme le nom de jeune fille de la mère ou l'animal préféré
Une simple anecdote que n'importe qui pourrait retirer de son blog, de son profil LinkedIn ou similaire
Toute question à laquelle il est plus facile de répondre que de deviner son mot de passe. Ce qui, pour tout mot de passe décent, est chaque question que vous pouvez imaginer
En conclusion, les questions de sécurité sont intrinsèquement précaires dans pratiquement toutes leurs formes et variantes, et ne doivent pas être utilisées dans un schéma d'authentification pour une raison quelconque.
La vraie raison pour laquelle les questions de sécurité existent même dans la nature est qu'elles permettent de réduire facilement le coût de quelques appels d'assistance d'utilisateurs qui ne peuvent pas accéder à leur messagerie pour obtenir un code de réactivation. Cela au détriment de la sécurité et de la réputation de Sarah Palin. Ça vaut le coup? Probablement pas.
PARTIE IV: Fonctionnalité de mot de passe oublié
J'ai déjà expliqué pourquoi vous ne devriez jamais utiliser de questions de sécurité pour gérer les mots de passe utilisateur oubliés / perdus; il va également de soi que vous ne devez jamais envoyer aux utilisateurs par e-mail leurs mots de passe réels. Il y a au moins deux écueils trop communs à éviter dans ce domaine:
Ne réinitialisez pas un mot de passe oublié en un mot de passe fort généré automatiquement - de tels mots de passe sont notoirement difficiles à retenir, ce qui signifie que l'utilisateur doit soit le modifier, soit l'écrire - par exemple, sur un Post-It jaune vif sur le bord de son moniteur. Au lieu de définir un nouveau mot de passe, laissez simplement les utilisateurs en choisir un nouveau immédiatement - c'est ce qu'ils veulent faire de toute façon. (Une exception à cela pourrait être si les utilisateurs utilisent universellement un gestionnaire de mots de passe pour stocker / gérer des mots de passe qui seraient normalement impossibles à retenir sans l'écrire).
Hachez toujours le code / jeton de mot de passe perdu dans la base de données. ENCORE , ce code est un autre exemple d'équivalent de mot de passe, il DOIT donc être haché au cas où un attaquant mettrait la main sur votre base de données. Lorsqu'un code de mot de passe perdu est demandé, envoyez le code en clair à l'adresse e-mail de l'utilisateur, puis hachez-le, enregistrez le hachage dans votre base de données - et jetez l'original . Tout comme un mot de passe ou un jeton de connexion persistant.
Une dernière remarque: assurez-vous toujours que votre interface pour entrer le `` code de mot de passe perdu '' est au moins aussi sécurisée que votre formulaire de connexion lui-même, ou un attaquant l'utilisera simplement pour y accéder à la place. Assurez-vous de générer de très longs `` codes de mot de passe perdus '' (par exemple, 16 caractères alphanumériques sensibles à la casse) est un bon début, mais pensez à ajouter le même schéma de limitation que vous faites pour le formulaire de connexion lui-même.
PARTIE V: Vérification de la force du mot de passe
Tout d'abord, vous voudrez lire ce petit article pour une vérification de la réalité: les 500 mots de passe les plus courants
D'accord, alors peut-être que la liste n'est pas la liste canonique des mots de passe les plus courants sur n'importe quel système, où que ce soit , mais c'est une bonne indication de la façon dont les gens choisissent mal leurs mots de passe lorsqu'il n'y a pas de politique appliquée en place. De plus, la liste semble terriblement proche de chez vous lorsque vous la comparez aux analyses accessibles au public des mots de passe récemment volés.
Donc: sans aucune exigence minimale de résistance des mots de passe, 2% des utilisateurs utilisent l'un des 20 mots de passe les plus courants. Signification: si un attaquant n'obtient que 20 tentatives, 1 compte sur 50 sur votre site Web sera crackable.
Pour éviter cela, il faut calculer l'entropie d'un mot de passe, puis appliquer un seuil. La publication spéciale 800-63 de l'Institut national des normes et de la technologie (NIST) propose un ensemble de très bonnes suggestions. Cela, lorsqu'il est combiné avec une analyse de la disposition du dictionnaire et du clavier (par exemple, 'qwertyuiop' est un mauvais mot de passe), peut rejeter 99% de tous les mots de passe mal sélectionnés à un niveau d'entropie de 18 bits. Le simple fait de calculer la force du mot de passe et de montrer un indicateur de force visuel à un utilisateur est bon, mais insuffisant. À moins qu'il ne soit appliqué, de nombreux utilisateurs l'ignoreront très probablement.
Et pour une approche rafraîchissante de la convivialité des mots de passe à haute entropie, Password Strength xkcd de Randall Munroe est fortement recommandé.
Utilisez l' API Have I Been Pwned de Troy Hunt pour vérifier les mots de passe des utilisateurs par rapport aux mots de passe compromis dans les violations de données publiques.
PARTIE VI: Beaucoup plus - Ou: Empêcher les tentatives de connexion à tir rapide
Tout d'abord, jetez un œil aux chiffres: Vitesses de récupération de mot de passe - Combien de temps votre mot de passe restera-t-il
Si vous n'avez pas le temps de parcourir les tableaux de ce lien, voici leur liste:
Il ne faut pratiquement pas de temps pour déchiffrer un mot de passe faible, même si vous le déchirez avec un boulier
Il ne faut pratiquement pas de temps pour déchiffrer un mot de passe alphanumérique à 9 caractères s'il n'est pas sensible à la casse
Il ne faut pratiquement pas de temps pour déchiffrer un mot de passe complexe, composé de symboles et de lettres et de chiffres, en majuscules et en minuscules s'il contient moins de 8 caractères (un ordinateur de bureau peut rechercher tout l'espace de touches jusqu'à 7 caractères dans un sujet de jours ou même d'heures)
Cependant, cela prendrait un temps excessif pour casser même un mot de passe à 6 caractères, si vous étiez limité à une tentative par seconde!
Alors, que pouvons-nous apprendre de ces chiffres? Eh bien, beaucoup, mais nous pouvons nous concentrer sur la partie la plus importante: le fait d'empêcher un grand nombre de tentatives de connexion successives à tir rapide (c'est-à-dire l' attaque par force brute ) n'est vraiment pas si difficile. Mais empêcher droit n'est pas aussi facile qu'il semble.
De manière générale, vous avez trois choix qui sont tous efficaces contre les attaques par force brute (et les attaques par dictionnaire, mais puisque vous utilisez déjà une politique de mots de passe forts, ils ne devraient pas être un problème) :
Présenter un CAPTCHA après N tentatives infructueuses (ennuyeux comme l'enfer et souvent inefficaces - mais je me répète ici)
Verrouillage des comptes et exigeant une vérification des e-mails après N tentatives infructueuses (il s'agit d'une attaque DoS en attente de se produire)
Et enfin, la limitation de la connexion : c'est-à-dire la définition d'un délai entre les tentatives après N tentatives infructueuses (oui, les attaques DoS sont toujours possibles, mais au moins, elles sont beaucoup moins probables et beaucoup plus compliquées à réaliser).
Meilleure pratique n ° 1: un court délai qui augmente avec le nombre de tentatives infructueuses, comme:
- 1 tentative échouée = pas de retard
- 2 tentatives infructueuses = 2 secondes de retard
- 3 tentatives infructueuses = 4 secondes de retard
- 4 tentatives infructueuses = délai de 8 s
- 5 tentatives infructueuses = délai de 16 secondes
- etc.
Une attaque DoS contre ce schéma serait très peu pratique, car le temps de verrouillage résultant est légèrement supérieur à la somme des temps de verrouillage précédents.
Pour clarifier: Le délai n'est pas un délai avant de renvoyer la réponse au navigateur. Cela ressemble plus à un délai d'expiration ou à une période réfractaire pendant laquelle les tentatives de connexion à un compte spécifique ou à partir d'une adresse IP spécifique ne seront pas acceptées ou évaluées du tout. Autrement dit, les informations d'identification correctes ne reviendront pas dans une connexion réussie et les informations d'identification incorrectes ne déclencheront pas une augmentation de délai.
Meilleure pratique n ° 2: un délai de durée moyenne qui entre en vigueur après l'échec de N tentatives, comme:
- 1-4 tentatives infructueuses = pas de retard
- 5 tentatives infructueuses = 15-30 min de retard
Le DoS attaquant ce schéma serait tout à fait impraticable, mais certainement faisable. En outre, il peut être pertinent de noter qu'un délai aussi long peut être très ennuyeux pour un utilisateur légitime. Les utilisateurs oublieux ne vous aimeront pas.
Meilleure pratique n ° 3: Combiner les deux approches - soit un court délai fixe qui entre en vigueur après l'échec de N tentatives, comme:
- 1-4 tentatives infructueuses = pas de retard
- 5+ tentatives infructueuses = 20 secondes de retard
Ou, un retard croissant avec une limite supérieure fixe, comme:
- 1 tentative échouée = 5 secondes de retard
- 2 tentatives infructueuses = 15 secondes de retard
- 3+ tentatives infructueuses = délai de 45 secondes
Ce schéma final est tiré des suggestions de bonnes pratiques de l'OWASP (lien 1 de la liste MUST-READ) et doit être considéré comme une bonne pratique, même s'il est certes restrictif.
En règle générale, cependant, je dirais: plus votre politique de mot de passe est solide, moins vous avez de bugs pour les utilisateurs avec des retards. Si vous avez besoin de mots de passe forts (alphanumériques sensibles à la casse + chiffres et symboles requis) de plus de 9 caractères, vous pouvez donner aux utilisateurs 2 à 4 tentatives de mot de passe non retardées avant d'activer la limitation.
DoS attaquant ce schéma de limitation de connexion final serait très peu pratique. Et comme touche finale, autorisez toujours les connexions persistantes (cookies) (et / ou un formulaire de connexion vérifié par CAPTCHA), afin que les utilisateurs légitimes ne soient même pas retardés pendant que l'attaque est en cours . De cette façon, l'attaque DoS très impraticable devient une attaque extrêmement impraticable.
De plus, il est logique de limiter plus agressivement les comptes d'administrateur, car ce sont les points d'entrée les plus attrayants
PARTIE VII: Attaques réparties de force brute
Soit dit en passant, les attaquants plus avancés tenteront de contourner la limitation de la connexion en «répartissant leurs activités»:
Distribution des tentatives sur un botnet pour empêcher le marquage d'adresse IP
Plutôt que de choisir un utilisateur et d'essayer les 50 000 mots de passe les plus courants (ce qu'ils ne peuvent pas, en raison de notre limitation), ils choisiront LE mot de passe le plus courant et l'essayeront contre 50 000 utilisateurs à la place. De cette façon, non seulement ils contournent les mesures de tentatives maximales comme les CAPTCHA et la limitation de la connexion, mais leurs chances de succès augmentent également, car le mot de passe le plus courant numéro 1 est beaucoup plus probable que le numéro 49.995.
Espacer les demandes de connexion pour chaque compte d'utilisateur, disons à 30 secondes d'intervalle, pour se faufiler sous le radar
Ici, la meilleure pratique consisterait à enregistrer le nombre de connexions ayant échoué, à l'échelle du système , et à utiliser une moyenne mobile de la fréquence des mauvaises connexions de votre site comme base pour une limite supérieure que vous imposez ensuite à tous les utilisateurs.
Trop abstrait? Permettez-moi de reformuler:
Supposons que votre site ait enregistré en moyenne 120 mauvaises connexions par jour au cours des 3 derniers mois. En utilisant cela (moyenne courante), votre système peut fixer la limite globale à 3 fois - c'est-à-dire. 360 tentatives infructueuses sur une période de 24 heures. Ensuite, si le nombre total de tentatives infructueuses sur tous les comptes dépasse ce nombre en un jour (ou mieux, surveillez le taux d'accélération et le déclenchement sur un seuil calculé), il active la limitation de connexion à l'échelle du système, ce qui signifie de courts délais pour TOUS les utilisateurs. (toujours, à l'exception des connexions de cookies et / ou des connexions CAPTCHA de sauvegarde).
J'ai également posté une question avec plus de détails et une très bonne discussion sur la façon d'éviter les pièges délicats en repoussant les attaques par force brute distribuées
PARTIE VIII: Authentification à deux facteurs et fournisseurs d'authentification
Les informations d'identification peuvent être compromises, que ce soit par des exploits, des mots de passe écrits et perdus, des ordinateurs portables avec des clés volées ou des utilisateurs qui se connectent à des sites de phishing. Les connexions peuvent être davantage protégées avec une authentification à deux facteurs, qui utilise des facteurs hors bande tels que les codes à usage unique reçus d'un appel téléphonique, d'un message SMS, d'une application ou d'un dongle. Plusieurs fournisseurs proposent des services d'authentification à deux facteurs.
L'authentification peut être entièrement déléguée à un service d'authentification unique, où un autre fournisseur gère la collecte des informations d'identification. Cela pousse le problème à un tiers de confiance. Google et Twitter fournissent tous deux des services d'authentification unique basés sur des normes, tandis que Facebook propose une solution propriétaire similaire.
LIENS À LIRE À PROPOS À propos de l'authentification Web
- OWASP Guide To Authentication / OWASP Authentication Cheat Sheet
- À faire et à ne pas faire pour l'authentification des clients sur le Web (document de recherche du MIT très lisible)
- Wikipédia: cookie HTTP
- Questions de connaissances personnelles pour l'authentification de secours: questions de sécurité à l'ère de Facebook (document de recherche très lisible de Berkeley)