security - Le guide définitif pour former

Translate

Authentification par formulaire pour les sites Web

Nous pensons que Stack Overflow ne devrait pas seulement être une ressource pour des questions techniques très spécifiques, mais aussi pour des directives générales sur la façon de résoudre des variations sur des problèmes courants. "L'authentification par formulaire pour les sites Web" devrait être un bon sujet pour une telle expérience.

Il devrait inclure des sujets tels que:

  • Comment s'identifier
  • Comment se déconnecter
  • Comment rester connecté
  • Gérer les cookies (y compris les paramètres recommandés)
  • Chiffrement SSL / HTTPS
  • Comment stocker les mots de passe
  • Utiliser des questions secrètes
  • Fonctionnalité de nom d'utilisateur / mot de passe oublié
  • Utilisation denoncespour prévenirfalsifications de requêtes intersites (CSRF)
  • OpenID
  • Case à cocher "Souviens-toi de moi"
  • Saisie automatique des noms d'utilisateur et des mots de passe du navigateur
  • URL secrètes (publiquesURLprotégé par digest)
  • Vérification de la force du mot de passe
  • Validation des e-mails
  • et bien plus sur authentification par formulaire...

Il ne devrait pas inclure des éléments tels que:

  • Rôles et autorisation
  • Authentification de base HTTP

Veuillez nous aider en:

  1. Suggérer des sous-thèmes
  2. Soumettre de bons articles sur ce sujet
  3. Modifier la réponse officielle
This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

PARTIE I: Comment se connecter

Nous supposerons que vous savez déjà comment créer un formulaire HTML de connexion + mot de passe qui POST les valeurs dans un script côté serveur pour l'authentification. Les sections ci-dessous traiteront des modèles d'authentification pratique et comment éviter les pièges de sécurité les plus courants.

Vers HTTPS ou pas vers HTTPS?

À moins que la connexion ne soit déjà sécurisée (c'est-à-dire, tunnelisé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 espionnant sur la ligne entre le navigateur et le serveur Web de lire les connexions à mesure qu'elles passent à travers. Ce type d'écoute électronique est effectué régulièrement par les gouvernements, mais en général, nous n'aborderons pas les fils «possédés» autrement que pour dire ceci: utilisez simplement HTTPS.

En substance, le seulpratiqueLe moyen de se protéger contre l'écoute électronique / le reniflage de paquets lors de la connexion consiste à utiliser HTTPS ou un autre schéma de chiffrement basé sur des certificats (par exemple,TLS) ou un schéma de provocation-réponse éprouvé et testé (par exemple, leDiffie-Hellmanbasé sur SRP).Toute autre méthode peut être facilement contournéepar un attaquant écoutant.

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 de type `` guerre froide '' ou un dongle générateur de clés RSA). Si elle est appliquée 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) Cryptage / hachage JavaScript personnalisé

Compte tenu de la perception (bien que maintenantévitable) coût et 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 fil non sécurisé.

Bien que ce soit une pensée noble, elle est essentiellement inutile (et peut êtrefaille de sécurité) à moins qu'il ne soit combiné avec l'un des éléments ci-dessus - c'est-à-dire en sécurisant la ligne avec un cryptage fort ou en utilisant un mécanisme de défi-réponse éprouvé (si vous ne savez pas ce que c'est, sachez simplement que c'est 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 passepeut êtreefficace contredivulgation du mot de passe, il est vulnérable aux attaques par rejeu, 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, il peut simplement commenter le hachage dans le JavaScript), ou des attaques par force brute (puisque vous donnez à l'attaquant le nom d'utilisateur, le sel et le mot de passe haché).

CAPTCHAS contre l'humanité

CAPTCHAest destiné à contrecarrer une catégorie spécifique d'attaque: dictionnaire automatisé / essai et erreur de 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 la gérer de manière transparente qui ne nécessitent pas de CAPTCHA, des schémas de limitation de connexion côté serveur spécialement conçus correctement - nous en discuterons plus tard.

Sachez que les implémentations CAPTCHA ne sont pas créées de la même manière; ils ne peuvent souvent pas être résolus par l'homme, la plupart d'entre eux sont en fait inefficaces contre les bots, tous sont inefficaces contre la main-d'œuvre bon marché du tiers-monde (selonOWASP, le tarif actuel des ateliers de misère est de 12 USD pour 500 tests), et certaines implémentations peuvent être techniquement illégales dans certains pays (voirAide-mémoire pour l'authentification OWASP). Si vous devez utiliser un CAPTCHA, utilisez GooglereCAPTCHA, car il est difficile OCR par définition (car il utilise déjà des scans de livres mal classés par OCR) et s'efforce 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 au maximum. Cela se produira assez rarement pour être acceptable et cela renforce le système dans son ensemble.

Stockage des mots de passe / vérification des connexions

Cela peut enfin être de notoriété publique après tous les hacks et fuites de données utilisateur très médiatisés que nous avons constatés 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 régulièrement piratées, divulguées ou glanées par injection SQL, et si vous stockez des mots de passe bruts et en texte clair, la sécurité de votre connexion est terminée.

Donc, si vous ne pouvez pas stocker le mot de passe, comment vérifier que la combinaison login + mot de passe POSTÉE à partir du formulaire de connexion est correcte? La réponse est le hachage en utilisant unfonction 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 longue chaîne d'apparence aléatoire , 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 saisi, cette fois en passant le salt 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. Regarde çaarticlesur sec.stackexchange pour des informations plus détaillées.

La raison pour laquelle un sel est utilisé est que le hachage en lui-même n'est pas suffisant - vous voudrez ajouter un soi-disant `` sel '' pour protéger le hachage contretables arc-en-ciel. Un salt empêche en fait deux mots de passe qui correspondent exactement d'être stockés avec la même valeur de hachage, empêchant toute la base de données d'être analysée en une seule exécution si un attaquant exécute une attaque par devinette de mot de passe.

Un hachage cryptographique ne doit pas être utilisé pour le stockage des mots de passe car les mots de passe sélectionnés par l'utilisateur ne sont pas assez forts (c'est-à-dire ne contiennent généralement pas assez d'entropie) et une attaque de devinette de mot de passe pourrait être menée à bien dans un temps relativement court par un attaquant ayant accès aux hachages. C'est pourquoi les KDF sont utilisés - ils"étirer 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é le login 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 souvenir que le navigateur a été authentifié. Ce fait ne devrait 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 aléatoirement 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 lors de l'envoi au navigateur. L'indicateur HttpOnly fournit une certaine protection contre le cookie en cours de lecture via une attaque XSS. Le drapeau sécurisé garantit que le cookie n'est renvoyé que via HTTPS et protège donc contre les attaques de reniflage 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 éviterfixation de session.

PARTIE II: Comment rester connecté - La tristement célèbre 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 tout aussi sûrs que les connexions conventionnelles lorsque les utilisateurs comprennent comment les gérer; et d'autre part, ils représentent un énorme risque de 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 de 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 claire. Sinon - eh bien, vous pouvez souscrire à la philosophie selon laquelle les utilisateurs négligents avec leurs identifiants de connexion s'en sont pris s'ils sont piratés. Ce n'est pas comme si nous allions chez nos utilisateurs et déchirions tous ces post-it induisant le visage avec des mots de passe qu'ils ont alignés sur le bord de leurs moniteurs.

Bien sûr, certains systèmes ne peuvent pas se permettretoutcomptes piratés; pour de tels systèmes, vous ne pouvez en aucun cas justifier des connexions persistantes.

Si vous décidez de mettre en œuvre des cookies de connexion persistants, voici comment procéder:

  1. Tout d'abord, prenez le temps de lireArticle de Paragon Initiativesur le sujet. Vous aurez besoin d'un bon nombre d'éléments, et l'article fait un excellent travail pour les expliquer.

  2. Et juste pour rappeler l'un des pièges les plus courants,NE CONSERVEZ PAS LE COOKIE DE CONNEXION PERSISTANTE (TOKEN) DANS VOTRE BASE DE DONNÉES, UNIQUEMENT UN HASH!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 connexion-mot de passe en texte clair. Par conséquent, utilisez le hachage (selonhttps://security.stackexchange.com/a/63438/5002un hachage faible fera très bien l'affaire) lors du stockage de jetons de connexion persistants.

PARTIE III: Utiliser des questions secrètes

N'implémentez pas de «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 MUST-READ. Vous pouvez interroger Sarah Palin à ce sujet, après son Yahoo! 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 fort probable que la plupart des utilisateurs choisissent soit:

  • Une question secrète `` standard '' comme le nom de jeune fille de la mère ou l'animal de compagnie préféré

  • Une simple anecdote que n'importe qui pourrait tirer de son blog, de son profil LinkedIn ou similaire

  • Toute question à laquelle il est plus facile de répondre que de deviner leur mot de passe. Quelle est, pour tout mot de passe décent, toutes les questions que vous pouvez imaginer

En conclusion, les questions de sécurité sont intrinsèquement non sécurisées dans pratiquement toutes leurs formes et variantes, et ne devraient pas être utilisées dans un schéma d'authentification pour quelque raison que ce soit.

La vraie raison pour laquelle les questions de sécurité existent même dans la nature est qu'elles économisent commodément le coût de quelques appels d'assistance de la part d'utilisateurs qui ne peuvent pas accéder à leur courrier électronique pour accéder à un code de réactivation. Ceci au détriment de la sécurité et de la réputation de Sarah Palin. Ça vaut le coup? Probablement pas.

PARTIE IV: Fonctionnalité du mot de passe oublié

J'ai déjà mentionné pourquoi tu devraisne jamais utiliser de questions de sécuritépour gérer les mots de passe utilisateur oubliés / perdus; il va sans dire également que vous ne devez jamais envoyer aux utilisateurs par courrier électronique leurs mots de passe réels. Il y a au moins deux autres écueils trop courants à éviter dans ce domaine:

  1. Ne pasréinitialiserun mot de passe oublié à un mot de passe fort généré automatiquement - ces mots de passe sont notoirement difficiles à mémoriser, ce qui signifie que l'utilisateur doit soit le changer 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 tout de suite - ce qu'ils veulent 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 à mémoriser sans les écrire).

  2. 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 - etjeter 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 saisir le «code de mot de passe perdu» est au moins aussi sécurisée que votre formulaire de connexion lui-même, sinon un attaquant l'utilisera simplement pour y accéder. S'assurer 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 lacanoniqueliste des mots de passe les plus courants surtoutsystèmen'importe où jamais, mais c'est une bonne indication de la façon dont les gens choisiront mal leurs mots de passe lorsqu'aucune politique n'est appliquée. De plus, la liste semble terriblement proche de chez vous lorsque vous la comparez aux analyses publiques de mots de passe récemment volés.

Donc: sans exigences minimales de force de mot 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 contrer cela, il faut calculer l'entropie d'un mot de passe puis appliquer un seuil. L'Institut national des normes et de la technologie (NIST)Publication spéciale 800-63a un ensemble de très bonnes suggestions. Cela, lorsqu'il est combiné avec un dictionnaire et une analyse de la disposition du clavier (par exemple, 'qwertyuiop' est un mauvais mot de passe), peutrejeter 99% de tous les mots de passe mal sélectionnésà un niveau de 18 bits d'entropie. Calculer simplement la force du mot de passe etmontrant un indicateur de force visuelà un utilisateur est bon, mais insuffisant. À moins que cela ne soit appliqué, de nombreux utilisateurs l'ignoreront probablement.

Et pour une version rafraîchissante de la convivialité des mots de passe à haute entropie, Randall Munroe'sForce du mot de passe xkcdest fortement recommandé.

Utilisez Troy Hunt'sAi-je été Pwned APIpour vérifier les mots de passe des utilisateurs par rapport aux mots de passe compromis lors de violations de données publiques.

PARTIE VI: Bien plus - Ou: Empêcher les tentatives de connexion Rapid-Fire

Tout d'abord, regardez les chiffres:Vitesses de récupération de mot de passe - Combien de temps votre mot de passe restera-t-il valide

Si vous n'avez pas le temps de parcourir les tableaux de ce lien, voici la liste d'entre eux:

  1. Ça prendpratiquement pas de tempspour déchiffrer un mot de passe faible, même si vous le craquez avec un boulier

  2. Ça prendpratiquement pas de tempspour déchiffrer un mot de passe alphanumérique à 9 caractères s'il estinsensible à la casse

  3. Ça prendpratiquement pas de tempspour déchiffrer un mot de passe complexe, symboles-et-lettres-et-chiffres, majuscules et minuscules s'il estmoins de 8 caractères(un ordinateur de bureau peut rechercher dans tout l'espace de touches jusqu'à 7 caractères en quelques jours, voire quelques heures)

  4. Cependant, il faudrait un temps excessif pour déchiffrer 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 rapides (c.-à-d.Force bruteattaque) n'est vraiment pas si difficile. Mais l'empêcherdroiten'est pas aussi facile qu'il y paraît.

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 forte, elles ne devraient pas être un problème):

  • Présenter unCAPTCHAaprès N tentatives ratées (ennuyeux comme l'enfer et souvent inefficace - mais je me répète ici)

  • Verrouillage des compteset exigeant une vérification de l'e-mail après N tentatives infructueuses (il s'agit d'unDoSattaque en attente de se produire)

  • Et enfin,limitation de connexion: c'est-à-dire définir 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 ratée = aucun délai
  • 2 tentatives infructueuses = 2 secondes de retard
  • 3 tentatives infructueuses = 4 secondes de retard
  • 4 tentatives infructueuses = 8 secondes de retard
  • 5 tentatives infructueuses = délai de 16 s
  • 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 estne pasun 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 du tout acceptées ou évaluées. Autrement dit, les informations d'identification correctes ne seront pas renvoyées lors d'une connexion réussie et les informations d'identification incorrectes ne déclencheront pas d'augmentation du délai.

Meilleure pratique n ° 2:Un délai moyen qui entre en vigueur après N tentatives infructueuses, comme:

  • 1-4 tentatives infructueuses = aucun délai
  • 5 tentatives infructueuses = 15-30 min de retard

Attaquer ce schéma par DoS serait tout à fait irréalisable, 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:Combinant les deux approches - soit un délai fixe et court qui entre en vigueur après N tentatives infructueuses, comme:

  • 1-4 tentatives infructueuses = aucun délai
  • 5+ tentatives infructueuses = 20 secondes de retard

Ou, un délai croissant avec une limite supérieure fixe, comme:

  • 1 tentative ratée = 5 s de retard
  • 2 tentatives infructueuses = délai de 15 s
  • 3+ tentatives infructueuses = 45 secondes de retard

Ce schéma final a été tiré des suggestions de bonnes pratiques de l'OWASP (lien 1 de la liste MUST-READ) et devrait être considéré comme une meilleure pratique, même si elle est certes restrictive.

En règle générale, cependant, je dirais: plus votre politique de mot de passe est forte, moins vous devez déranger 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 différées avant d'activer la limitation.

DoS attaquer ce schéma de limitation de connexion final seraittrèspas pratique. Et comme touche finale, autorisez toujours les connexions persistantes (cookies) (et / ou un formulaire de connexion vérifié par CAPTCHA) à passer, afin que les utilisateurs légitimes ne soient même pas retardéspendant que l'attaque est en cours. De cette façon, l'attaque DoS très peu pratique devient unextrêmementattaque peu pratique.

De plus, il est logique de procéder à une limitation plus agressive des comptes administrateurs, car ce sont les points d'entrée les plus attrayants.

PARTIE VII: Attaques par force brute répartie

En passant, des attaquants plus avancés tenteront de contourner la limitation de connexion en `` propageant 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, à cause 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 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.

  • Espacement des demandes de connexion pour chaque compte utilisateur, disons à 30 secondes d'intervalle, pour se faufiler sous le radar

Ici, la meilleure pratique seraitconsignation du nombre d'échecs de connexion, à l'échelle du système, et en utilisant une moyenne mobile de la fréquence de connexion incorrecte de votre site comme base d'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 définir la limite globale à 3 fois celle-ci - 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 encore, surveillez le taux d'accélération et de 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 par cookie et / ou des connexions de sauvegarde CAPTCHA).

J'ai également posté une question avecplus de détails et une très bonne discussion sur la façon d'éviter les pièges délicatspour repousser les attaques par force brute distribuées

PARTIE VIII: Fournisseurs d'authentification et d'authentification à deux facteurs

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 grâce à l'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 complètement déléguée à un service d'authentification unique, où un autre fournisseur gère la collecte des informations d'identification. Cela renvoie le problème à un tiers de confiance. Google et Twitter fournissent tous deux des services SSO normalisés, tandis que Facebook fournit une solution propriétaire similaire.

LIENS INCONTOURNABLES À propos de l'authentification Web

  1. Guide OWASP pour l'authentification/Aide-mémoire pour l'authentification OWASP
  2. À faire et à ne pas faire en matière d'authentification client sur le Web (document de recherche du MIT très lisible)
  3. Wikipédia: cookie HTTP
  4. 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)
La source
Translate

Article définitif

Envoi des informations d'identification

Le seul moyen pratique d'envoyer des informations d'identification de manière 100% sécurisée consiste à utiliserSSL. L'utilisation de JavaScript pour hacher le mot de passe n'est pas sûre. Pièges courants pour le hachage de mot de passe côté client:

  • Si la connexion entre le client et le serveur n'est pas chiffrée, tout ce que vous faites estvulnérable aux attaques man-in-the-middle. Un attaquant pourrait remplacer le javascript entrant pour casser le hachage ou envoyer toutes les informations d'identification à son serveur, il pourrait écouter les réponses des clients et usurper parfaitement l'identité des utilisateurs, etc. etc. SSL avec des autorités de certification de confiance est conçu pour empêcher les attaques MitM.
  • Le mot de passe haché reçu par le serveur estMoins sécurisési vous n'effectuez pas de travail supplémentaire et redondant sur le serveur.

Il existe une autre méthode sécurisée appeléeSRP, mais il est breveté (bien qu'il soitlicence libre) et il existe peu de bonnes implémentations disponibles.

Stockage des mots de passe

Ne stockez jamais les mots de passe sous forme de texte brut dans la base de données. Pas même si vous ne vous souciez pas de la sécurité de votre propre site. Supposons que certains de vos utilisateurs réutiliseront le mot de passe de leur compte bancaire en ligne. Alors, stockez le mot de passe haché et jetez l'original. Et assurez-vous que le mot de passe n'apparaît pas dans les journaux d'accès ou les journaux d'application. OWASPrecommande l'utilisation d'Argon2comme premier choix pour les nouvelles applications. Si ce n'est pas disponible, PBKDF2 ou scrypt doit être utilisé à la place. Et enfin, si aucun des éléments ci-dessus n'est disponible, utilisez bcrypt.

Les hachages en eux-mêmes ne sont pas non plus sécurisés. Par exemple, des mots de passe identiques signifient des hachages identiques - cela fait des tables de recherche de hachage un moyen efficace de déchiffrer de nombreux mots de passe à la fois. Au lieu de cela, stockez lesaléhacher. Un salt est une chaîne ajoutée au mot de passe avant le hachage - utilisez un sel différent (aléatoire) par utilisateur. Le sel est une valeur publique, vous pouvez donc les stocker avec le hachage dans la base de données. Voiricipour en savoir plus.

Cela signifie que vous ne pouvez pas envoyer à l'utilisateur ses mots de passe oubliés (car vous n'avez que le hachage). Ne réinitialisez pas le mot de passe de l'utilisateur sauf si vous l'avez authentifié (les utilisateurs doivent prouver qu'ils sont capables de lire les e-mails envoyés à l'adresse e-mail stockée (et validée).)

Questions de sécurité

Les questions de sécurité ne sont pas sécurisées - évitez de les utiliser. Pourquoi? Tout ce qu'une question de sécurité fait, un mot de passe fait mieux. LisPARTIE III: Utiliser des questions secrètesdans@Jens Roland réponseici dans ce wiki.

Cookies de session

Une fois que l'utilisateur s'est connecté, le serveur envoie à l'utilisateur un cookie de session. Le serveur peut récupérer le nom d'utilisateur ou l'identifiant du cookie, mais personne d'autre ne peut générer un tel cookie (TODO explique les mécanismes).

Les cookies peuvent être détournés: ils ne sont aussi sécurisés que le reste de la machine du client et d'autres communications. Ils peuvent être lus à partir du disque, reniflés dans le trafic réseau, levés par une attaque de script intersite, phishing à partir d'un DNS empoisonné afin que le client envoie ses cookies aux mauvais serveurs. N'envoyez pas de cookies persistants. Les cookies doivent expirer à la fin de la session client (le navigateur ferme ou quitte votre domaine).

Si vous souhaitez connecter automatiquement vos utilisateurs, vous pouvez définir un cookie persistant, mais il doit être distinct d'un cookie de session complète. Vous pouvez définir un indicateur supplémentaire indiquant que l'utilisateur s'est connecté automatiquement et doit se connecter pour de vrai pour les opérations sensibles. Ceci est populaire auprès des sites d'achat qui souhaitent vous offrir une expérience d'achat transparente et personnalisée tout en protégeant vos informations financières. Par exemple, lorsque vous revenez visiter Amazon, ils vous montrent une page qui ressemble à votre connexion, mais lorsque vous passez une commande (ou changez votre adresse de livraison, votre carte de crédit, etc.), ils vous demandent de confirmer votre mot de passe.

Les sites Web financiers tels que les banques et les cartes de crédit, en revanche, ne contiennent que des données sensibles et ne devraient pas permettre la connexion automatique ou un mode de faible sécurité.

Liste des ressources externes

La source
Translate

Tout d'abord, une mise en garde forte est que cette réponse n'est pas la meilleure solution pour cette question exacte. Cela ne devrait certainement pas être la meilleure réponse!

Je vais aller de l'avant et mentionner la proposition de MozillaBrowserID(ou peut-être plus précisément, leProtocole de messagerie vérifié) dans l'esprit de trouver une voie de mise à niveau vers de meilleures approches d'authentification à l'avenir.

Je vais le résumer de cette façon:

  1. Mozilla est une organisation à but non lucratif avecvaleursqui correspondent bien à la recherche de bonnes solutions à ce problème.
  2. La réalité d'aujourd'hui est que la plupart des sites Web utilisent l'authentification par formulaire
  3. L'authentification par formulaire présente un gros inconvénient, qui est un risque accru deHameçonnage. Les utilisateurs sont invités à saisir des informations sensibles dans une zone contrôlée par une entité distante, plutôt que dans une zone contrôlée par leur agent utilisateur (navigateur).
  4. Étant donné que les navigateurs sont implicitement approuvés (l'idée même d'un agent utilisateur est d'agir au nom de l'utilisateur), ils peuvent aider à améliorer cette situation.
  5. La principale force retenant le progrès ici estblocage du déploiement. Les solutions doivent être décomposées en étapes qui procurent à elles seules des avantages supplémentaires.
  6. La méthode décentralisée la plus simple pour exprimer une identité intégrée à l'infrastructure Internet est le nom de domaine.
  7. En tant que deuxième niveau d'expression de l'identité, chaque domaine gère son propre ensemble de comptes.
  8. Le formulaire "compte@domain »est concis et pris en charge par un large éventail de protocoles et de schémas d'URI. Un tel identifiant est, bien entendu, le plus universellement reconnu comme une adresse e-mail.
  9. Les fournisseurs de messagerie électronique sont déjà de facto les principaux fournisseurs d'identité en ligne. Les flux de réinitialisation de mot de passe actuels vous permettent généralement de prendre le contrôle d'un compte si vous pouvez prouver que vous contrôlez l'adresse e-mail associée à ce compte.
  10. Le protocole de messagerie vérifié a été proposé pour fournir une méthode sécurisée, basée sur la cryptographie à clé publique, pour rationaliser le processus de preuve au domaine B que vous avez un compte sur le domaine A.
  11. Pour les navigateurs qui ne prennent pas en charge le protocole de messagerie vérifié (actuellement tous), Mozilla fournit un shim qui implémente le protocole dans le code JavaScript côté client.
  12. Pour les services de messagerie qui ne prennent pas en charge le protocole de messagerie vérifié, le protocole permet à des tiers d'agir en tant qu'intermédiaire de confiance, affirmant qu'ils ont vérifié la propriété d'un compte par un utilisateur. Il n'est pas souhaitable d'avoir un grand nombre de ces tiers; cette fonctionnalité est destinée uniquement à autoriser un chemin de mise à niveau, et il est préférable que les services de messagerie fournissent eux-mêmes ces assertions.
  13. Mozilla propose son propre service pour agir comme un tiers de confiance. Les fournisseurs de services (c'est-à-dire les parties utilisatrices) mettant en œuvre le protocole de courrier électronique vérifié peuvent choisir de faire confiance aux affirmations de Mozilla ou non. Le service de Mozilla vérifie la propriété du compte des utilisateurs en utilisant les moyens conventionnels d'envoyer un e-mail avec un lien de confirmation.
  14. Les fournisseurs de services peuvent, bien entendu, proposer ce protocole en option en plus de toute autre méthode d'authentification qu'ils souhaiteraient proposer.
  15. Un grand avantage de l'interface utilisateur recherché ici est le «sélecteur d'identité». Lorsqu'un utilisateur visite un site et choisit de s'authentifier, son navigateur lui montre une sélection d'adresses e-mail («personnelles», «travail», «activisme politique», etc.) qu'il peut utiliser pour s'identifier sur le site.
  16. Un autre grand avantage de l'interface utilisateur recherché dans le cadre de cet effort estaider le navigateur à en savoir plus sur la session de l'utilisateur- avec qui ils sont connectés actuellement, principalement - il peut donc l'afficher dans le chrome du navigateur.
  17. En raison de la nature distribuée de ce système, il évite le verrouillage sur des sites majeurs comme Facebook, Twitter, Google, etc. Tout individu peut posséder son propre domaine et donc agir comme son propre fournisseur d'identité.

Il ne s'agit pas strictement d'une «authentification par formulaire pour les sites Web». Mais c'est un effort pour passer de la norme actuelle d'authentification par formulaire à quelque chose de plus sûr: l'authentification prise en charge par le navigateur.

La source
Translate

J'ai juste pensé partager cette solution qui fonctionnait très bien.

Je l'appelle leChamp factice(même si je n'ai pas inventé cela, alors ne me créditez pas).

En bref: il vous suffit de l'insérer dans votre<form>et vérifiez qu'il est vide lors de la validation:

<input type="text" name="email" style="display:none" />

L'astuce consiste à tromper un robot en lui faisant croire qu'il doit insérer des données dans un champ obligatoire, c'est pourquoi j'ai nommé l'entrée "email". Si vous avez déjà un champ appelé e-mail que vous utilisez, vous devriez essayer de nommer le champ factice autre chose comme "entreprise", "téléphone" ou "adresse e-mail". Choisissez simplement quelque chose dont vous savez que vous n'avez pas besoin et ce qui ressemble à quelque chose que les gens trouveraient normalement logique de remplir dans un formulaire Web. Maintenant cachez leinputchamp en utilisant CSS ou JavaScript / jQuery - ce qui vous convient le mieux - justenerégler l'entréetypeàhiddenou bien le bot ne tombera pas amoureux.

Lorsque vous validez le formulaire (côté client ou côté serveur), vérifiez si votre champ factice a été rempli pour déterminer s'il a été envoyé par un humain ou un robot.

Exemple:

Dans le cas d'un humain:L'utilisateur ne verra pas le champ factice (dans mon cas nommé "email") et n'essaiera pas de le remplir. Ainsi, la valeur du champ factice doit toujours être vide lorsque le formulaire a été envoyé.

En cas de bot:Le bot verra un champ dont le type esttextet un nomemail(ou peu importe comment vous l'avez appelé) et tentera logiquement de le remplir avec les données appropriées. Peu importe si vous avez stylé le formulaire de saisie avec du CSS sophistiqué, les développeurs Web le font tout le temps. Quelle que soit la valeur du champ factice, nous ne nous soucions pas tant qu'elle est supérieure à0personnages.

J'ai utilisé cette méthode sur un livre d'or en combinaison avecCAPTCHA, et je n'ai pas vu un seul message de spam depuis. J'avais déjà utilisé une solution CAPTCHA uniquement, mais finalement, cela a abouti à environ cinq messages de spam toutes les heures. L'ajout du champ factice dans le formulaire a empêché (du moins jusqu'à présent) tout le spam d'apparaître.

Je pense que cela peut également être utilisé très bien avec un formulaire de connexion / authentification.

Attention: Bien sûr, cette méthode n'est pas à 100% infaillible. Les bots peuvent être programmés pour ignorer les champs de saisie avec le styledisplay:noneappliqué à lui. Vous devez également penser aux personnes qui utilisent une forme de saisie semi-automatique (comme la plupart des navigateurs ont intégré!) Pour remplir automatiquement tous les champs du formulaire. Ils pourraient tout aussi bien ramasser un champ factice.

Vous pouvez également varier légèrement cela en laissant le champ factice visible mais en dehors des limites de l'écran, mais cela dépend entièrement de vous.

Sois créatif!

La source
Translate

Je ne pense pas que la réponse ci-dessus soit "fausse" mais il y a de grands domaines d'authentification qui ne sont pas abordés (ou plutôt l'accent est mis sur "comment implémenter des sessions de cookies", pas sur "quelles options sont disponibles et quels sont les échanges -offs ".

Mes suggestions de modifications / réponses sont

  • Le problème réside plus dans la configuration du compte que dans la vérification du mot de passe.
  • L'utilisation de l'authentification à deux facteurs est beaucoup plus sûre que des moyens plus intelligents de cryptage de mot de passe
  • N'essayez PAS de mettre en œuvre votre propre formulaire de connexion ou le stockage de vos mots de passe dans la base de données, à moins que les données stockées ne soient sans valeur lors de la création du compte et auto-générées (c'est-à-dire un style Web 2.0 comme FacebookFlickr, etc.)

    1. L'authentification Digest est une approche basée sur des normes prise en charge dans tous les principaux navigateurs et serveurs, qui n'enverra pas de mot de passe même via un canal sécurisé.

Cela évite tout besoin d'avoir des «sessions» ou des cookies car le navigateur lui-même rechiffre la communication à chaque fois. C'est l'approche de développement la plus «légère».

Cependant, je ne le recommande pas, sauf pour les services publics de faible valeur. C'est un problème avec certaines des autres réponses ci-dessus - n'essayez pas de réimplémenter les mécanismes d'authentification côté serveur - ce problème a été résolu et est pris en charge par la plupart des principaux navigateurs. N'utilisez pas de cookies. Ne stockez rien dans votre propre base de données déroulée à la main. Demandez simplement, par requête, si la requête est authentifiée. Tout le reste doit être pris en charge par la configuration et un logiciel de confiance tiers.

Alors ...

Tout d'abord, nous confondons la création initiale d'un compte (avec un mot de passe) avec la revérification du mot de passe par la suite. Si je suis Flickr et que je crée votre site pour la première fois, le nouvel utilisateur a accès à la valeur zéro (espace Web vide). Je me fiche vraiment de savoir si la personne qui crée le compte ment sur son nom. Si je crée un compte sur l'intranet / extranet de l'hôpital, la valeur réside dans tous les dossiers médicaux, donc jedose soucient de l'identité (*) du créateur du compte.

C'est la partie la plus difficile. leseulementune solution décente est un réseau de confiance. Par exemple, vous rejoignez l'hôpital en tant que médecin. Vous créez une page Web hébergée quelque part avec votre photo, votre numéro de passeport et une clé publique, et vous les hachez toutes avec la clé privée. Vous visitez ensuite l'hôpital et l'administrateur système examine votre passeport, voit si la photo vous correspond, puis hache la page Web / la photo avec la clé privée de l'hôpital. Désormais, nous pouvons échanger des clés et des jetons en toute sécurité. Comme n'importe qui qui fait confiance à l'hôpital (il y a la sauce secrète BTW). L'administrateur système peut également vous donner unRSAdongle ou autre authentification à deux facteurs.

Mais c'est unlotd'un tracas, et pas très Web 2.0. Cependant, c'est le seul moyen sécurisé de créer de nouveaux comptes qui ont accès à des informations précieuses qui ne sont pas auto-créées.

  1. Kerberos et SPNEGO - mécanismes d'authentification unique avec un tiers de confiance - essentiellement, l'utilisateur vérifie par rapport à un tiers de confiance. (NB ce n'est en aucun cas le moyen de ne pas faire confianceOAuth)

  2. SRP- sorte d'authentification par mot de passe intelligente sans tiers de confiance. Mais ici, nous entrons dans les domaines de "il est plus sûr d'utiliser l'authentification à deux facteurs, même si c'est plus coûteux"

  3. SSLcôté client - donne aux clients un certificat de clé publique (prise en charge dans tous les principaux navigateurs - mais soulève des questions sur la sécurité de la machine cliente).

En fin de compte, c'est un compromis - quel est le coût d'une faille de sécurité par rapport au coût de mise en œuvre d'approches plus sécurisées. Un jour, nous verrons peut-être unPKIlargement acceptés et donc plus de formulaires et bases de données d'authentification roulés. Un jour...

La source
Translate

Lors du hachage, n'utilisez pas d'algorithmes de hachage rapide tels que MD5 (de nombreuses implémentations matérielles existent). Utilisez quelque chose comme SHA-512. Pour les mots de passe, les hachages plus lents sont préférables.

Plus vite vous pouvez créer des hachages, plus vite un vérificateur de force brute peut fonctionner. Des hachages plus lents ralentiront donc le forçage brutal. Un algorithme de hachage lent rendra le forçage brutal impraticable pour les mots de passe plus longs (8 chiffres +)

La source
Translate

Un bon article sur l'estimation réaliste de la force des mots de passe est:

Blog technique de Dropbox »Archives de blogs» zxcvbn: estimation réaliste de la force des mots de passe

La source
Translate

Ma règle préférée en ce qui concerne les systèmes d'authentification: utilisez des mots de passe, pas des mots de passe. Facile à retenir, difficile à craquer. Plus d'informations:Coding Horror: mots de passe et phrases de passe

La source
Yehudi Lee
Translate

J'aimerais ajouter une suggestion que j'ai utilisée, basée sur la défense en profondeur. Vous n'avez pas besoin d'avoir le même système d'authentification et d'authentification pour les administrateurs que les utilisateurs réguliers. Vous pouvez avoir un formulaire de connexion distinct sur une URL distincte exécutant un code distinct pour les demandes qui accorderont des privilèges élevés. Celui-ci peut faire des choix qui seraient une douleur totale pour les utilisateurs réguliers. Un tel que j'ai utilisé est de brouiller l'URL de connexion pour l'accès administrateur et d'envoyer par e-mail à l'administrateur la nouvelle URL. Arrête immédiatement toute attaque par force brute car votre nouvelle URL peut être arbitrairement difficile (très longue chaîne aléatoire) mais le seul inconvénient de votre administrateur est de suivre un lien dans son e-mail. L'attaquant ne sait plus où même POST.

La source
Page Lee
Translate

Je ne sais pas s'il était préférable de répondre à cette question sous forme de réponse ou de commentaire. J'ai opté pour la première option.

Concernant le poingPARTIE IV: Fonctionnalité du mot de passe oubliédans la première réponse, je voudrais faire un point sur les attaques chronométrées.

dans leSouvenez-vous de votre mot de passeformulaires, un attaquant pourrait potentiellement vérifier une liste complète des e-mails et détecter ceux qui sont enregistrés dans le système (voir le lien ci-dessous).

En ce qui concerne le formulaire de mot de passe oublié, j'ajouterais que c'est une bonne idée d'égaliser les temps entre les requêtes réussies et infructueuses avec une fonction de retard.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

La source
Translate

Je voudrais ajouter un commentaire très important: -

  • "Dans unentreprise, intra-net, "la plupart sinon la totalité de ce qui précède peut ne pas s'appliquer!

De nombreuses entreprises déploient des sites Web «à usage interne uniquement» qui sont, en fait, des «applications d'entreprise» qui ont été implémentées via des URL. Ces URL peuvent(soi-disant ...)être résolu uniquement au sein du «réseau interne de l'entreprise».(Quel réseau inclut comme par magie tous les `` guerriers de la route '' connectés au VPN.)

Lorsqu'un utilisateur est consciencieusement connecté au réseau susmentionné, son identité("authentification")est [déjà ...] «définitivement connue», tout comme leur permission("autorisation")pour faire certaines choses ... comme ... "accéder à ce site Web."

Ce service «authentification + autorisation» peut être fourni par plusieurs technologies différentes, comme LDAP(Microsoft OpenDirectory)ou Kerberos.

De votre point de vue, vous savez simplement ceci: quen'importe quiqui se termine légitimement sur votre site Webdoitêtre accompagné par [une variable d'environnement contenant comme par magie ...] un «jeton». (c'est à direL'absence d'un tel jeton doit être un motif immédiat pour404 Not Found.)

La valeur du jeton n'a aucun sens pour vous,mais,en cas de besoin, "des moyens appropriés existent" par lesquels votre site Web peut "[avec autorité] interroger quelqu'un qui sait (LDAP ... etc.)"et chaque (!)question que vous pourriez avoir. En d'autres termes, vous faitesne pasprofiter detout«logique locale». Au lieu de cela, vous demandez à l'Autorité et faites implicitement confiance à son verdict.

Euh huh ... c'estassezun changement mental de «l'Internet sauvage et laineux».

La source
Leo Lee
Translate

UtilisationOpenID ConnectouAccès géré par l'utilisateur.

Car rien n'est plus efficace que de ne pas le faire du tout.

La source