Question Le guide définitif de l'authentification de site Web basée sur un formulaire [fermé]


Authentification basée sur des formulaires pour les sites Web

Nous croyons que Stack Overflow ne devrait pas être seulement 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 communs. "L'authentification basée sur les formulaires 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é
  • Gestion des cookies (y compris les paramètres recommandés)
  • Chiffrement SSL / HTTPS
  • Comment stocker les mots de passe
  • Utiliser des questions secrètes
  • Nom d'utilisateur / mot de passe oublié
  • Utilisation de nonces pour prévenir falsifications de requêtes inter-sites (CSRF)
  • OpenID
  • "Remember me" case à cocher
  • Auto-complétion du navigateur des noms d'utilisateur et mots de passe
  • URL secrètes (publiques URL protégé par digest)
  • Vérification de la force du mot de passe
  • Validation par e-mail
  • et beaucoup plus sur  authentification basée sur un formulaire...

Cela ne devrait pas inclure des choses comme:

  • Rôles et autorisation
  • Authentification de base HTTP

Aidez-nous s'il vous plaît par:

  1. Suggérer des sous-thèmes
  2. Soumettre de bons articles sur ce sujet
  3. Modifier la réponse officielle

4992


origine


Réponses:


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 à un script du côté serveur pour l'authentification. Les sections ci-dessous traitent des modèles pour une authentification pratique solide, et comment éviter les pièges de sécurité les plus courants.

Pour HTTPS ou pas pour HTTPS?

Sauf si la connexion est déjà sécurisée (c'est-à-dire tunnelée via HTTPS en utilisant SSL / TLS), vos valeurs de formulaire de connexion seront envoyées en clair, ce qui permettra à tous ceux qui naviguent entre le navigateur et le serveur web de lire les connexions. 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 «possédés» autrement que de dire ceci: Si vous protégez quelque chose d'important, utilisez le protocole HTTPS.

En substance, le seul pratique La protection contre l'écoute électronique / le reniflage de paquets lors de la connexion consiste à utiliser HTTPS ou un autre système de chiffrement basé sur un certificat (par exemple, TLS) ou un schéma de test-réponse éprouvé et testé (par exemple, le Diffie-HellmanSRP basée sur la base). Toute autre méthode peut être facilement contournée par un attaquant indiscret.

Bien sûr, si vous souhaitez être un peu inutilisable, vous pouvez également utiliser une forme d'authentification à deux facteurs (par exemple, l'application Google Authenticator, un livre de codes physique «style guerre froide» ou un dongle générateur de clé RSA). S'il est appliqué correctement, cela peut 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 JavaScript / hachage

Compte tenu du coût non nul et la difficulté technique perçue de la mise en place d'un certificat SSL sur votre site Web, certains développeurs sont tentés de rouler leurs propres systèmes ou hachage de chiffrement dans le navigateur afin d'éviter de passer les connexions sur un fil en texte clair non sécurisé.

Bien que ce soit une pensée noble, elle est essentiellement inutile (et peut être une défaut de sécurité) sauf si elle est combinée avec l'un des éléments ci-dessus - soit sécuriser la ligne avec un cryptage fort ou utiliser un mécanisme de réponse-test éprouvé (si vous ne savez pas ce que c'est, sachez que c'est un du plus difficile à prouver, le plus difficile à concevoir, et le plus difficile à mettre en œuvre des concepts en sécurité numérique).

Alors qu'il est vrai que hashing le mot de passe peut être efficace contre mot de passe, Il est vulnérable aux attaques par rejeu, Man-In-The-Middle attaques / détournements d'avions (si un attaquant peut injecter quelques octets dans votre page HTML sans garantie avant d'atteindre votre navigateur, ils peuvent tout simplement commenter le hash dans le JavaScript), ou des attaques en force brute (puisque vous donnez à l'attaquant à la fois le nom d'utilisateur, le mot de passe de sel et le mot de passe haché).

CAPTCHAS contre l'humanité

CAPTCHAs sont destinés à contrecarrer une catégorie spécifique d'attaque: dictionnaire automatique / force brute essai-et-erreur sans opérateur humain. Il ne fait aucun doute qu'il s'agit d'une menace réelle, mais il existe des moyens de la gérer de manière transparente qui ne nécessitent pas de CAPTCHA, spécifiquement conçu schémas de limitation de connexion côté serveur - nous en discuterons plus tard.

Sachez que les implémentations de CAPTCHA ne sont pas créées de la même façon; ils ne sont souvent pas solubles dans l'homme, la plupart d'entre eux sont inefficaces contre les robots, tous sont inefficaces contre le travail du tiers-monde bon marché (selon OWASP, le taux de sweatshop actuel est de 12 $ par 500 tests), et certaines implémentations peuvent être techniquement illégales dans certains pays (voir OWASP Authentification Cheat Sheet). Si vous devez utiliser un CAPTCHA, utilisez Google reCAPTCHA, car il est OCR-hard par définition (puisqu'il utilise déjà des lectures de livres OCR-mal classées) et essaie très fort d'être convivial.

Personnellement, j'ai tendance à trouver ennuyeux CAPTCHAS, et de les utiliser seulement en dernier recours quand un utilisateur a échoué à se connecter un certain nombre de fois et les délais d'étranglement sont maxxed out. Cela arrivera 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 hautement médiatisés et les fuites de données d'utilisateurs que nous avons vus ces dernières années, mais il doit être dit: Ne stockez pas les mots de passe en clair dans votre base de données. Les bases de données utilisateur sont régulièrement piratées, fuites ou glanées via l'injection SQL, et si vous stockez des mots de passe bruts et en 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 POSTed du formulaire de connexion est correcte? La réponse est hashing en utilisant un 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 sur un KDF, comme Argon2, bcrypt, scrypt ou PBKDF2, transformant le mot de passe cleartext ("correcthorsebatterystaple") en une longue chaîne 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é, cette fois en passant dans 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 le sel avec le hash déjà. Regarde ça article sur 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 aurez besoin d'ajouter un soi-disant «sel» pour protéger le hachage contre tables arc-en-ciel. Un salt empêche efficacement deux mots de passe qui correspondent exactement d'être stockés comme la même valeur de hachage, empêchant l'analyse de la base de données entière 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 puissants (par exemple, ne contient généralement pas assez d'entropie) et un attaquant ayant un accès aux hachages peut effectuer une attaque par devinette. C'est pourquoi un KDF est utilisé - ceux-ci efficacement "étirer la clé" ce qui signifie que chaque mot de passe que suppose un attaquant implique l'itération de l'algorithme de hachage plusieurs fois, par exemple 10 000 fois, ce qui rend le mot de passe de l'attaquant 10 000 fois plus lent.

Données de session - "Vous êtes connecté en tant que Spiderman69"

Une fois que le serveur a vérifié le nom d'utilisateur et le mot de passe dans votre base de données utilisateur et trouvé une correspondance, le système doit pouvoir se souvenir que le navigateur a été authentifié. Ce fait devrait seulement ê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 est stockée sur le serveur. Si vous utilisez un framework MVC, c'est déjà géré.

Dans la mesure du possible, assurez-vous que le cookie de session possède les indicateurs sécurisés et HTTP Only définis lors de l'envoi au navigateur. L'indicateur httponly fournit une certaine protection contre la lecture du cookie par une attaque XSS. L'indicateur de sécurité garantit que le cookie est uniquement renvoyé via HTTPS et protège ainsi contre les attaques de reniflage de réseau. La valeur du cookie ne devrait 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 fixation de session.

PARTIE II: Comment rester connecté - La fameuse case à cocher "Se souvenir de moi"

Les cookies de connexion persistants (fonctionnalité "remember me") constituent une zone dangereuse; d'une part, ils sont tout aussi sûrs que les connexions conventionnelles lorsque les utilisateurs comprennent comment les gérer; et d'un autre côté, ils constituent un énorme risque de sécurité pour les utilisateurs négligents, qui peuvent les utiliser sur les ordinateurs publics et oublier de se déconnecter, et qui peuvent ne pas savoir ce que sont les cookies 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 connaissent la même chose, vous pouvez utiliser des connexions persistantes avec une conscience propre. Si non - bien, alors vous pouvez vous abonner à la philosophie que les utilisateurs qui sont négligents avec leurs identifiants de connexion l'ont pris sur eux-mêmes si elles sont piratées. Ce n'est pas comme si nous allions chez nos utilisateurs et que nous arrachions toutes ces notes Post-It factices avec des mots de passe qu'elles ont alignés sur le bord de leurs moniteurs.

Bien sûr, certains systèmes ne peuvent pas se permettre d'avoir tout comptes piratés; pour de tels systèmes, vous ne pouvez pas justifier d'avoir des connexions persistantes.

Si vous décidez d'implémenter des cookies de connexion persistants, voici comment procéder:

  1. D'abord, prenez le temps de lire L'article de Paragon Initiative sur le sujet. Vous aurez besoin d'un bon nombre d'éléments, et l'article explique parfaitement chacun d'eux.

  2. Et juste pour réitérer l'un des pièges les plus courants, NE CONSERVEZ PAS LE COOKIE DE CONNEXION PERSISTANT (TOKEN) DANS VOTRE BASE DE DONNÉES, SEULEMENT UN HASH DE LUI! Le jeton de connexion est équivalent à un mot de passe, donc si un attaquant mettait la main sur votre base de données, il pouvait utiliser les jetons pour se connecter à n'importe quel compte, comme s'il s'agissait de combinaisons de mots de passe. Par conséquent, utilisez le hachage (selon https://security.stackexchange.com/a/63438/5002 un hachage faible fera très bien à cet effet) lors du stockage des jetons de connexion persistants.

PARTIE III: Utiliser des questions secrètes

Ne pas implémenter des 'questions secrètes'. La fonction "questions secrètes" est un anti-pattern de sécurité. Lisez le document du lien numéro 4 de la liste MUST-READ. Vous pouvez demander à Sarah Palin à ce sujet, après son Yahoo! Le compte e-mail a été piraté lors d'une campagne présidentielle précédente 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 favori

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

  • Toute question qui est plus facile à répondre que de deviner leur mot de passe. Lequel, pour tout mot de passe décent, est chaque question que vous pouvez imaginer

En conclusion, les questions de sécurité sont intrinsèquement insécurisées dans pratiquement toutes leurs formes et variations, 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, c'est qu'elles économisent facilement le coût de quelques appels de support d'utilisateurs qui ne peuvent pas accéder à leur courrier électronique pour obtenir 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é de mot de passe oublié

J'ai déjà mentionné pourquoi vous devriez N'utilisez jamais de questions de sécuritépour gérer les mots de passe utilisateur oubliés / perdus; Il va sans dire que vous ne devriez jamais envoyer vos mots de passe par courriel aux utilisateurs. Il y a au moins deux autres pièges à éviter dans ce domaine:

  1. Ne pas réinitialiser un mot de passe oublié pour un mot de passe fort généré automatiquement - de tels mots de passe sont notoirement difficiles à mémoriser, ce qui signifie que l'utilisateur doit le modifier ou 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 choisir un nouveau mot de passe - ce qu'ils veulent faire de toute façon. (Une exception à ceci pourrait être si les utilisateurs utilisent universellement un gestionnaire de mots de passe pour stocker / gérer les mots de passe qui seraient normalement impossibles à mémoriser sans les écrire).

  2. Toujours hacher le mot de passe perdu / jeton dans la base de données. ENCORE, ce code est un autre exemple d'un mot de passe équivalent, il doit donc être haché dans le cas où un attaquant a mis la main sur votre base de données. Quand 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 jeter l'original. Tout comme un mot de passe ou un jeton de connexion persistant.

Une note finale: assurez-vous toujours que votre interface pour saisir le 'code mot de passe perdu' est au moins aussi sécurisée que votre formulaire de connexion, ou qu'un attaquant utilisera simplement ceci pour y accéder à la place. Assurez-vous de générer de très longs «codes de mots de passe perdus» (par exemple, 16 caractères alphanumériques sensibles à la casse), c'est un bon début, mais pensez à ajouter le même schéma de limitation que le formulaire de connexion lui-même.

PARTIE V: Vérification de la force du mot de passe

Tout d'abord, vous aurez envie de 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 canonique liste des mots de passe les plus courants sur tout système partout, mais c'est une bonne indication de la façon dont les gens choisiront mal leurs mots de passe quand il n'y a pas de politique appliquée en place. De plus, la liste est terriblement proche de chez vous lorsque vous la comparez à des analyses publiques de mots de passe récemment volés.

Donc: Sans exigences de force de mot de passe minimum, 2% des utilisateurs utilisent l'un des 20 mots de passe les plus courants. Ce qui signifie: si un attaquant obtient seulement 20 tentatives, 1 compte sur 50 sur votre site web sera cassable.

Pour contrecarrer cela, il faut calculer l'entropie d'un mot de passe et ensuite appliquer un seuil. L'Institut national des normes et de la technologie (NIST) Publication spéciale 800-63 a un ensemble de très bonnes suggestions. Que, lorsqu'il est combiné avec un dictionnaire et l'analyse de la disposition 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 de 18 bits d'entropie. Il suffit de calculer la force du mot de passe et montrant un indicateur de force visuelle à un utilisateur est bon, mais insuffisant. À moins qu'il ne soit appliqué, beaucoup d'utilisateurs l'ignoreront probablement.

Et pour une approche rafraîchissante de la convivialité des mots de passe à forte entropie, Randall Munroe Force de mot de passe xkcd est fortement recommandé.

PARTIE VI: Beaucoup plus - Ou: Prévention des tentatives de connexion rapide

Tout d'abord, jetez un oeil aux chiffres: Les délais de récupération du mot de passe - combien de temps votre mot de passe se lèvera

Si vous n'avez pas le temps de parcourir les tableaux de ce lien, voici la liste de ceux-ci:

  1. Ça prend pratiquement pas de temps pour casser un mot de passe faible, même si vous le craquez avec un abaque

  2. Ça prend pratiquement pas de temps pour déchiffrer un mot de passe alphanumérique de 9 caractères, s'il est insensible à la casse

  3. Ça prend pratiquement pas de temps pour déchiffrer un mot de passe complexe, symboles-et-lettres-et-chiffres, majuscules et minuscules, s'il est moins de 8 caractères (un ordinateur de bureau peut rechercher l'espace de clé entier jusqu'à 7 caractères en quelques jours ou même heures)

  4. Cela prendrait toutefois énormément de temps 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 que la prévention d'un grand nombre de tentatives de connexion successives rapides (c.-à-d. Force brute attaque) n'est vraiment pas si difficile. Mais le prévenir droite n'est pas aussi facile qu'il n'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 de dictionnaire, mais puisque vous utilisez déjà une politique de mots de passe forte, ils ne devraient pas être un problème):

  • Présenter un CAPTCHA après N échecs tentatives (ennuyeux comme l'enfer et souvent inefficace - mais je me répète ici)

  • Verrouiller les comptes et exigeant la vérification d'email après N tentatives échouées (ceci est un DoS attaque en attente de se produire)

  • Et enfin, Limitation de connexion: c'est-à-dire, fixer 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 à enlever).

Meilleure pratique n ° 1: Un délai court qui augmente avec le nombre de tentatives infructueuses, comme:

  • 1 tentative ratée = pas de retard
  • 2 tentatives échouées = délai de 2 secondes
  • 3 tentatives échouées = délai de 4 secondes
  • 4 tentatives échouées = délai de 8 secondes
  • 5 tentatives échouées = délai de 16 secondes
  • etc.

DoS attaquer ce schéma serait très peu pratique, puisque le temps de verrouillage résultant est légèrement plus grand que la somme des temps de verrouillage précédents.

Pour clarifier: le délai est ne pas un délai avant de renvoyer la réponse au navigateur. Il s'agit plutôt d'un délai d'expiration ou d'une période réfractaire durant 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. Cela signifie que les informations d'identification correctes ne seront pas renvoyées lors d'une connexion réussie et que les informations d'identification incorrectes ne déclencheront pas une augmentation du délai.

Meilleure pratique n ° 2: Une temporisation de moyenne durée qui prend effet après N tentatives infructueuses, comme:

  • 1-4 tentatives échouées = pas de retard
  • 5 tentatives échouées = délai de 15-30 min

DoS attaquer 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 aiment pas.

Meilleure pratique n ° 3: Combiner les deux approches - soit un délai fixe et court qui prend effet après N tentatives infructueuses, comme:

  • 1-4 tentatives échouées = pas de retard
  • 5 tentatives échouées = délai de 20 secondes

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

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

Ce schéma final a été tiré des suggestions de meilleures pratiques de l'OWASP (lien 1 de la liste MUST-READ), et devrait être considéré comme la meilleure pratique, même s'il est admis qu'il est restrictif.

En règle générale, cependant, je dirais: plus votre politique de mot de passe est forte, moins vous devez retarder les utilisateurs. 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 attaquer ce dernier schéma de limitation de connexion serait très pas pratique. Enfin, permettez toujours aux connexions persistantes (cookie) (et / ou un formulaire de connexion vérifié par CAPTCHA) de passer, afin que les utilisateurs légitimes ne soient même pas retardés alors que l'attaque est en cours. De cette façon, l'attaque DoS très peu pratique devient un extrêmement attaque impraticable.

En outre, il est judicieux de faire des restrictions plus agressives sur les comptes admin, car ce sont les points d'entrée les plus attrayants.

PARTIE VII: Attaques de forces brutes réparties

Juste à part, des attaquants plus avancés tenteront de contourner la limitation des connexions en 'déployant leurs activités':

  • Distribuer les 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 vont choisir le mot de passe le plus courant et l'essayer contre 50.000 utilisateurs à la place. De cette façon, non seulement ils contourneront les mesures de maximum de tentatives comme les CAPTCHA et la limitation de connexion, mais leurs chances de succès augmenteront aussi, puisque le mot de passe numéro 1 le plus courant est beaucoup plus probable que le numéro 49.995

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

Ici, la meilleure pratique serait consignation du nombre d'échecs de connexion, à l'échelle du systèmeet en utilisant une moyenne courante 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? Laissez-moi reformuler:

Supposons que votre site a enregistré en moyenne 120 mauvaises connexions par jour au cours des trois derniers mois. En utilisant cela (moyenne courante), votre système pourrait définir la limite globale à 3 fois ce - ie. 360 tentatives infructueuses sur une période de 24 heures. Ensuite, si le nombre total de tentatives échouées sur tous les comptes dépasse ce nombre en un jour (ou mieux, surveillez le taux d'accélération et déclenchez sur un seuil calculé), il active la limitation de connexion à l'échelle du système. (encore, à l'exception des connexions aux cookies et / ou des connexions CAPTCHA de sauvegarde).

J'ai aussi posté une question avec plus de détails et une très bonne discussion sur la façon d'éviter les pièges difficiles en repoussant 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 ou perdus, des ordinateurs portables avec des clés volées ou des utilisateurs qui entrent dans des sites de phishing. Les connexions peuvent être davantage protégées par une authentification à deux facteurs, qui utilisent 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 offrent des services d'authentification à deux facteurs.

L'authentification peut être complètement déléguée à un service de connexion unique, où un autre fournisseur gère les informations d'identification de collecte. Cela pousse le problème à un tiers de confiance. Google et Twitter proposent tous deux des services SSO basés sur des standards, tandis que Facebook propose une solution propriétaire similaire.

LIRE LES LIENS À PROPOS DE L'authentification Web

  1. OWASP Guide d'authentification / OWASP Authentification Cheat Sheet
  2. Dos et ne pas faire de l'authentification du client sur le Web (document de recherche MIT très lisible)
  3. Wikipedia: cookie HTTP
  4. Questions de connaissances personnelles pour l'authentification de secours: questions de sécurité à l'ère de Facebook (document de recherche Berkeley très lisible)

3497



Article définitif

Envoyer des informations d'identification

Le seul moyen pratique d'envoyer des informations d'identification à 100% en toute sécurité consiste à utiliser SSL. Utiliser JavaScript pour hacher le mot de passe n'est pas sûr. Pièges courants pour le hachage du 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 est vulnérable aux attaques de l'homme du milieu. Un attaquant pourrait remplacer le javascript entrant pour rompre le hachage ou envoyer toutes les informations d'identification à son serveur, écouter les réponses des clients et usurper l'identité des utilisateurs, etc. etc. SSL avec des autorités de certification fiables est conçu pour empêcher les attaques MitM.
  • Le mot de passe haché reçu par le serveur est Moins sécurisé si vous ne faites pas de travail supplémentaire et redondant sur le serveur.

Il y a une autre méthode sécurisée appelée SRP, mais il est breveté (bien qu'il soit librement autorisé) et il existe peu de bonnes implémentations disponibles.

Stockage des mots de passe

Ne stockez jamais vos mots de passe sous forme de texte en clair 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. OWASP recommande l'utilisation d'Argon2 comme votre premier choix pour de nouvelles applications. Si ce n'est pas disponible, PBKDF2 ou scrypt devrait être utilisé à la place. Et enfin, si aucun des éléments ci-dessus n'est disponible, utilisez bcrypt.

Les hachages par eux-mêmes sont également peu sûrs. Par exemple, des mots de passe identiques signifient des hachages identiques - ce qui fait des tables de recherche de hachage un moyen efficace de déchiffrer plusieurs mots de passe à la fois. Au lieu de cela, enregistrez le salé hacher. Un salt est une chaîne attachée au mot de passe avant le hachage - utilisez un sel différent (aléatoire) par utilisateur. Le salt est une valeur publique, vous pouvez donc les stocker avec le hash dans la base de données. Voir ici pour en savoir plus

Cela signifie que vous ne pouvez pas envoyer à l'utilisateur ses mots de passe oubliés (parce que vous avez seulement le hash). Ne réinitialisez pas le mot de passe de l'utilisateur à moins d'avoir authentifié l'utilisateur (les utilisateurs doivent prouver qu'ils sont en mesure de lire les courriels envoyés à l'adresse e-mail enregistré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. Lis PARTIE III: Utiliser des questions secrètes dans @Jens Roland répondre ici dans ce wiki.

Cookies de session

Une fois l'utilisateur connecté, le serveur envoie un cookie de session à l'utilisateur. 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 sont aussi sûrs 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, soulevés par une attaque de script intersite, phishing à partir d'un DNS empoisonné afin que le client envoie leurs cookies aux mauvais serveurs. N'envoyez pas de cookies persistants. Les cookies devraient expirer à la fin de la session client (le navigateur ferme ou quitte votre domaine).

Si vous souhaitez authentifier 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 que l'utilisateur a connecté automatiquement et doit se connecter pour des opérations sensibles. Ceci est populaire auprès des sites d'achat qui veulent vous offrir une expérience de magasinage personnalisée et transparente tout en protégeant vos données financières. Par exemple, lorsque vous revenez sur Amazon, une page s'affiche comme si vous étiez connecté, mais lorsque vous passez une commande (ou modifiez votre adresse de livraison, votre carte de paiement, etc.), ils vous demandent de confirmer votre mot de passe.

D'un autre côté, les sites financiers tels que les banques et les cartes de crédit ne disposent que de données sensibles et ne devraient pas autoriser l'auto-connexion ou un mode de faible sécurité.

Liste des ressources externes


387



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

Je vais aller de l'avant et mentionner le projet de Mozilla BrowserID (ou peut-être plus précisément, le Protocole de courriel vérifié) dans l'esprit de trouver un chemin de mise à niveau vers de meilleures approches d'authentification à l'avenir.

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

  1. Mozilla est un but non lucratif avec valeurs qui s'harmonisent bien avec la recherche de bonnes solutions à ce problème.
  2. La réalité aujourd'hui est que la plupart des sites utilisent l'authentification basée sur des formulaires
  3. L'authentification basée sur un formulaire a un gros inconvénient, à savoir le risque accru de hameçonnage. Les utilisateurs sont invités à entrer 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. Puisque 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 force primaire retenant le progrès ici est blocage de déploiement. Les solutions doivent être décomposées en étapes qui offrent un avantage supplémentaire par elles-mêmes.
  6. La méthode décentralisée la plus simple pour exprimer l'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 supporté par un large éventail de protocoles et de schémas d'URI. Un tel identifiant est, bien sûr, le plus universellement reconnu comme une adresse e-mail.
  9. Les fournisseurs de messagerie sont déjà les fournisseurs d'identité principaux de facto 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 Verified Email Protocol 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 supportent pas le protocole Verified Email Protocol (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 Email 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 tiers; cette fonctionnalité est uniquement destinée à 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 en tant que tiers de confiance. Les fournisseurs de services (c'est-à-dire les parties utilisatrices) qui mettent en œuvre le protocole d'e-mail vérifié peuvent choisir de faire confiance aux assertions 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 email avec un lien de confirmation.
  14. Les fournisseurs de services peuvent, bien sûr, offrir ce protocole en option en plus de toute autre méthode d'authentification qu'ils pourraient souhaiter offrir.
  15. Un gros avantage d'interface utilisateur recherché est le "sélecteur d'identité". Quand un utilisateur visite un site et choisit de s'authentifier, son navigateur lui montre une sélection d'adresses email ("personnel", "travail", "activisme politique", etc.) qu'il peut utiliser pour s'identifier sur le site.
  16. Un autre grand avantage de l'interface utilisateur étant recherché dans le cadre de cet effort est aider le navigateur à en savoir plus sur la session de l'utilisateur - à qui ils sont connectés en tant que actuellement, principalement - de sorte qu'il peut afficher dans le chrome du navigateur.
  17. En raison de la nature distribuée de ce système, il évite de s'enfermer sur des sites majeurs comme Facebook, Twitter, Google, etc. Tout individu peut posséder son propre domaine et ainsi agir comme son propre fournisseur d'identité.

Ceci n'est pas strictement une "authentification basée sur un formulaire pour les sites Web". Mais il s'agit d'un effort pour passer de la norme actuelle d'authentification basée sur les formulaires à quelque chose de plus sécurisé: l'authentification par navigateur.


146



Je pensais juste partager cette solution que je trouvais fonctionner correctement.

Je l'appelle le Champ factice (bien que je n'ai pas inventé cela, alors ne me créditez pas).

En bref: il suffit d'insérer ceci dans votre <form> et vérifiez qu'il soit vide lors de la validation:

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

L'astuce consiste à tromper un bot 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 fictif quelque chose d'autre comme "company", "phone" ou "emailaddress". Choisissez simplement quelque chose dont vous savez que vous n'avez pas besoin et qui ressemble à quelque chose que les gens trouveraient logique de remplir dans un formulaire Web. Maintenant cachez le input champ en utilisant CSS ou JavaScript / jQuery - tout ce qui vous convient le mieux - juste ne pas régler l'entrée type à hidden sinon le bot ne tombera pas pour ça.

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

Exemple:

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

Dans le cas d'un bot: Le bot verra un champ dont le type est text et un nom email (ou peu importe comment vous l'appelez) et tentera logiquement de le remplir avec les données appropriées. Il ne se soucie pas si vous avez stylisé le formulaire d'entrée avec un CSS de fantaisie, les développeurs web le font tout le temps. Quelle que soit la valeur du champ factice, nous ne nous en soucions pas tant qu'il est plus grand que 0 personnages.

J'ai utilisé cette méthode sur un livre d'or en combinaison avec CAPTCHA, et je n'ai pas vu un seul message de spam depuis. J'avais déjà utilisé une solution CAPTCHA seulement, mais finalement, il en a résulté environ cinq messages de spam toutes les heures. Ajouter le champ fictif dans le formulaire a arrêté (au moins jusqu'à maintenant) tous les spams d'apparaître.

Je crois 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 robots peuvent être programmés pour ignorer les champs de saisie avec le style display:none appliqué à elle. Vous devez également penser aux personnes qui utilisent une certaine forme d'auto-complétion (comme la plupart des navigateurs ont intégré!) Pour remplir automatiquement tous les champs de formulaire pour eux. Ils pourraient tout aussi bien prendre un champ factice.

Vous pouvez également varier un peu 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!


120



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

Mes modifications / réponses suggérées 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
  • Ne tentez PAS d'implémenter votre propre formulaire de connexion ou de stockage de mots de passe, sauf si les données stockées sont sans valeur à la création du compte et auto-générées (c'est-à-dire, style web 2.0 comme Facebook, Flickr, etc.)

    1. Digest Authentication est une approche basée sur les standards supportée par tous les principaux navigateurs et serveurs, qui n'enverra pas de mot de passe même sur un canal sécurisé.

Cela évite d'avoir besoin de "sessions" ou de cookies car le navigateur lui-même recrée 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 roulée à la main. Il suffit de demander, par demande, si la demande est authentifiée. Tout le reste doit être pris en charge par la configuration et les logiciels de confiance tiers.

Alors ...

D'abord, nous confondons la création initiale d'un compte (avec un mot de passe) avec re-vé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 à une valeur nulle (espace web vide). Je m'en fiche vraiment si la personne qui crée le compte ment à propos de son nom. Si je crée un compte de l'intranet / extranet de l'hôpital, la valeur réside dans tous les dossiers médicaux, et donc je faire se soucient de l'identité (*) du créateur du compte.

C'est la partie très très difficile. le seulement solution décente est un réseau de confiance. Par exemple, vous vous joignez à 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 les hachez tous avec la clé privée. Vous vous rendez ensuite à l'hôpital et l'administrateur du système regarde votre passeport, voit si la photo vous correspond, puis hache la page Web / hash photo avec la clé privée de l'hôpital. A partir de maintenant, nous pouvons échanger des clés et des jetons en toute sécurité. Comme tous ceux qui font confiance à l'hôpital (il y a la sauce secrète BTW). L'administrateur système peut également vous donner un RSA dongle ou autre authentification à deux facteurs.

Mais c'est un lot de 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 de connexion unique avec une tierce partie de confiance - essentiellement l'utilisateur vérifie contre un tiers de confiance. (NB ce n'est en aucun cas le non digne de confiance OAuth)

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

  3. SSL Côté client - Donner aux clients un certificat de clé publique (support 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 violation de la sécurité par rapport au coût de la mise en œuvre d'approches plus sécurisées. Un jour, nous pouvons voir un bon ICP largement accepté et donc plus propre roulé des formulaires d'authentification et des bases de données. Un jour...


71



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 meilleurs.

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


48



Un bon article sur l'estimation réaliste de la force d'un mot de passe est:

Zxcvbn: estimation réaliste de la force d'un mot de passe


46



Ma règle préférée en matière de systèmes d'authentification: utiliser des mots de passe, pas des mots de passe. Facile à retenir, difficile à casser. Plus d'informations: Coder l'horreur: Mots de passe et phrases de passe


41



J'aimerais ajouter une suggestion que j'ai utilisée, fondée sur la défense en profondeur. Vous n'avez pas besoin du même système d'auth & auth pour les administrateurs que les utilisateurs réguliers. Vous pouvez avoir un formulaire de connexion séparé sur une URL séparée en exécutant un code séparé 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 envoyer un courriel à l'administrateur de la nouvelle URL. Arrête toute attaque de force brute tout de suite car votre nouvelle URL peut être arbitrairement difficile (chaîne aléatoire très longue) mais le seul inconvénient de votre utilisateur admin est de suivre un lien dans son email. L'attaquant ne sait plus où POSER.


20