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

08-06-2019
|

Question

Authentification par formulaire pour les sites Web

Nous pensons que Stack Overflow ne doit pas seulement être une ressource pour des questions techniques très spécifiques, mais également pour des directives générales sur la manière de résoudre des variantes de problèmes courants."L'authentification basée sur un 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é
Gestion des cookies (y compris les paramètres recommandés)
Cryptage SSL/HTTPS
Comment stocker les mots de passe
Utiliser des questions secrètes
Fonctionnalité de nom d'utilisateur/mot de passe oublié
Utilisation de occasionnels pour prévenir contrefaçons de demandes intersites (CSRF)
ID ouvert
Case à cocher "Se souvenir de moi"
Saisie semi-automatique du navigateur des noms d'utilisateur et des 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 bien plus encore sur authentification basée sur un formulaire...

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

Rôles et autorisation
Authentification de base HTTP

S'il vous plaît, aidez-nous en :

Suggestion de sous-thèmes
Soumettre de bons articles sur ce sujet
Modification de la réponse officielle

La solution

PARTIE I :Comment s'identifier

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 de la manière d'é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 permettra à toute personne espionnant la ligne entre le navigateur et le serveur Web de pouvoir lire les connexions au fur et à mesure de leur passage. à 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 « appartenant » autrement que pour dire ceci :Si vous protégez quelque chose d'important, utilisez HTTPS.

En substance, le seul pratique Un moyen de se protéger contre les écoutes téléphoniques/le reniflage de paquets lors de la connexion consiste à utiliser HTTPS ou un autre système de cryptage basé sur un certificat (par exemple, TLS) ou un système de défi-réponse éprouvé et testé (par exemple, le Diffie-HellmanSRP basé sur . Toute autre méthode peut être facilement contournée par un attaquant qui écoute aux portes.

Bien sûr, si vous souhaitez être un peu irréaliste, vous pouvez également utiliser une forme de système d'authentification à deux facteurs (par ex.l'application Google Authenticator, un livre de codes physique de « style guerre froide » ou un dongle générateur de clé RSA).S'il est appliqué correctement, cela pourrait fonctionner même avec une connexion non sécurisée, mais il est difficile d'imaginer qu'un développeur serait prêt à implémenter l'authentification à deux facteurs mais pas SSL.

(Ne pas) Effectuer votre propre cryptage/hachage JavaScript

Étant donné le coût non nul et la difficulté technique perçue de la configuration d'un certificat SSL sur votre site Web, certains développeurs sont tentés de déployer leurs propres systèmes de hachage ou de cryptage dans le navigateur afin d'éviter de transmettre des connexions en clair sur un fil non sécurisé.

Bien qu’il s’agisse d’une pensée noble, elle est essentiellement inutile (et peut être un faille de sécurité) à moins qu'il ne soit combiné avec l'un des éléments ci-dessus - c'est-à-dire soit en sécurisant la ligne avec un cryptage fort, soit en utilisant un mécanisme de défi-réponse éprouvé (si vous ne savez pas ce que c'est, sachez simplement qu'il s'agit d'un mécanisme de défi-réponse éprouvé). des concepts les plus difficiles à prouver, les plus difficiles à concevoir et les plus difficiles à mettre en œuvre en matière de sécurité numérique).

S'il est vrai que le hachage du mot de passe peut être efficace contre divulgation du mot de passe, il est vulnérable aux attaques par rejeu, aux attaques/détournements 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 à la fois un nom d'utilisateur, du sel et un mot de passe haché).

CAPTCHAS contre l'humanité

CAPTCHA vise à contrecarrer une catégorie spécifique d’attaques :dictionnaire automatisé/essais et erreurs par force brute sans opérateur humain.Il ne fait aucun doute qu'il s'agit d'une menace réelle, cependant, il existe des moyens de 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 sont souvent pas résolubles par l'homme, la plupart d'entre eux sont en réalité inefficaces contre les robots, tous sont inefficaces contre la main d'œuvre bon marché du tiers-monde (selon OWASP, le tarif actuel des ateliers clandestins est de 12 $ pour 500 tests), et certaines implémentations peuvent être techniquement illégales dans certains pays (voir Aide-mémoire d'authentification OWASP).Si vous devez utiliser un CAPTCHA, utilisez celui de Google reCAPTCHA, car il est par définition difficile à OCR (puisqu'il utilise des numérisations de livres déjà mal classées par OCR) et s'efforce d'être convivial.

Personnellement, j'ai tendance à trouver les CAPTCHAS ennuyeux et à les utiliser uniquement en dernier recours lorsqu'un utilisateur n'a pas réussi à se connecter plusieurs fois et que les délais de limitation sont maximisés.Cela se produit assez rarement pour être acceptable, et cela renforce le système dans son ensemble.

Stockage des mots de passe / Vérification des connexions

C'est peut-être enfin de notoriété publique après tous les piratages très médiatisés et les fuites de données utilisateur que nous avons constatés ces dernières années, mais il faut le dire :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, divulguées ou glanées par injection SQL, et si vous stockez des mots de passe bruts en texte clair, la partie est instantanément terminée pour la sécurité de votre connexion.

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 de hacher à l'aide d'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 via un KDF, tel que Argon2, bcrypt, scrypt ou PBKDF2, transformant le mot de passe en clair ("correcthorsebatterystaple") en une longue chaîne d'apparence 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 saisi, en passant cette fois le sel et comparez la chaîne de hachage résultante à la valeur stockée dans votre base de données.Argon2, bcrypt et scrypt stockent déjà le sel avec le hachage.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 devrez ajouter ce qu'on appelle un « sel » pour protéger le hachage contre tables arc-en-ciel.Un sel empêche efficacement que deux mots de passe qui correspondent exactement soient stockés sous la même valeur de hachage, empêchant ainsi l'analyse de l'ensemble de la base de données 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 des mots de passe, car les mots de passe sélectionnés par l'utilisateur ne sont pas assez forts (c'est-à-direne contiennent généralement pas suffisamment d'entropie) et une attaque par devinette de mot de passe pourrait être menée dans un temps relativement court par un attaquant ayant accès aux hachages.C'est pourquoi les KDF sont utilisés - ils sont efficaces "étirer la clé", ce qui signifie que chaque mot de passe deviné par un attaquant entraîne plusieurs répétitions de l'algorithme de hachage, par exemple 10 000 fois, ce qui amène 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é l'identifiant et le mot de passe par rapport à votre base de données d'utilisateurs et trouvé une correspondance, le système a besoin d'un moyen de se rappeler que le navigateur a été authentifié.Ce fait ne doit être stocké que 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 un ensemble de données - les données de session - qui sont stockées sur le serveur.Si vous utilisez un framework MVC, cela est sans doute déjà géré.

Dans la mesure du possible, assurez-vous que le cookie de session possède les indicateurs sécurisé et HTTP uniquement lorsqu'il est envoyé au navigateur.L'indicateur HttpOnly offre une certaine protection contre la lecture du cookie via une attaque XSS.L'indicateur sécurisé garantit que le cookie est renvoyé uniquement via HTTPS et protège donc contre les attaques par 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 éviter séance de fixation.

DEUXIEME PARTIE:Comment rester connecté – La fameuse case à cocher « Se souvenir de moi »

Les cookies de connexion persistants (fonctionnalité « se souvenir de moi ») constituent 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'un autre côté, 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 ni 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 les connexions persistantes en toute bonne conscience.Si ce n'est pas le cas, vous pouvez souscrire à la philosophie selon laquelle les utilisateurs négligents avec leurs identifiants de connexion s'en prennent à eux-mêmes s'ils se font pirater.Ce n'est pas non plus comme si nous allions chez nos utilisateurs et déchirons toutes ces notes Post-It induisant la paume du visage avec les mots de passe qu'ils ont alignés sur le bord de leurs moniteurs.

Bien sûr, certains systèmes ne peuvent pas se permettre d'avoir n'importe lequel comptes piratés ;pour de tels systèmes, vous ne pouvez en aucun cas justifier d’avoir des connexions persistantes.

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

Tout d'abord, prenez le temps de lire Article de Paragon Initiative sur le sujet.Vous devrez bien comprendre un certain nombre d’éléments, et l’article explique très bien chacun d’entre eux.
Et juste pour réitérer l'un des pièges les plus courants, NE STOCKEZ PAS LE COOKIE DE CONNEXION PERSISTANT (JETON) DANS VOTRE BASE DE DONNÉES, SEULEMENT UN HASH DE CELUI-CI ! 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 et de mot de passe en texte clair.Par conséquent, utilisez le hachage (selon https://security.stackexchange.com/a/63438/5002 un hachage faible fera très bien l'affaire) lors du stockage des jetons de connexion persistants.

PARTIE III :Utiliser des questions secrètes

Ne mettez pas en œuvre de « questions secrètes ».La fonctionnalité « questions secrètes » est un anti-modèle de sécurité.Lisez l'article à partir du lien numéro 4 de la liste À LIRE À LIRE.Vous pouvez interroger Sarah Palin à ce sujet, après son compte Yahoo!son 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...« Lycée Wasilla » !

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 préféré
Une simple anecdote que n'importe qui pourrait extraire de son blog, de son profil LinkedIn ou similaire
Toute question à laquelle il est plus facile de répondre que de deviner son mot de passe.Ce qui, pour tout mot de passe décent, correspond à toutes les questions que vous pouvez imaginer

En conclusion, les questions de sécurité sont intrinsèquement non sécurisées sous pratiquement toutes leurs formes et variantes, et ne devraient pour aucune raison être utilisées dans un système d’authentification.

La véritable raison pour laquelle les questions de sécurité existent même dans la nature est qu'elles permettent d'économiser le coût de quelques appels d'assistance 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.Cela en vaut la peine?Probablement pas.

PARTIE IV :Fonctionnalité de mot de passe oublié

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

Ne le faites pas réinitialiser d'un mot de passe oublié à un mot de passe fort généré automatiquement - de tels mots de passe sont notoirement difficiles à retenir, ce qui signifie que l'utilisateur doit soit le modifier, soit l'écrire - par exemple, sur un Post-It jaune vif placé sur le bord de son écran.Au lieu de définir un nouveau mot de passe, laissez simplement les utilisateurs en choisir un nouveau immédiatement - ce qu'ils souhaitent faire de toute façon.(Une exception à cela pourrait être si les utilisateurs utilisent universellement un gestionnaire de mots de passe pour stocker/gérer des mots de passe dont il serait normalement impossible de se souvenir sans les écrire).
Hachez toujours le code/jeton de mot de passe perdu dans la base de données. ENCORE, ce code est un autre exemple d'équivalent de mot de passe, il DOIT donc être haché au cas où un attaquant mettrait la main sur votre base de données.Lorsqu'un code de mot de passe perdu est demandé, envoyez le code en clair à l'adresse e-mail de l'utilisateur, puis hachez-le, enregistrez le hachage dans votre base de données - et jeter l'original.Tout comme un mot de passe ou un jeton de connexion persistant.

Une dernière remarque :assurez-vous toujours que votre interface de saisie du « 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 à la place.S'assurer de générer des « codes de mot de passe perdus » très longs (par exemple, 16 caractères alphanumériques sensibles à la casse) est un bon début, mais envisagez d'ajouter le même schéma de limitation que celui que vous utilisez 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 vérifier la réalité : Les 500 mots de passe les plus courants

D'accord, alors peut-être que la liste n'est pas la canonique liste des mots de passe les plus courants sur n'importe lequel système n'importe où, jamais, mais cela montre à quel point les gens choisissent mal leurs mots de passe lorsqu'aucune politique n'est appliquée.De plus, la liste semble terriblement proche de chez nous lorsque vous la comparez aux analyses accessibles au public sur les mots de passe récemment volés.

Donc:Sans exigence minimale 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 piratable.

Pour contrecarrer 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-63 a un ensemble de très bonnes suggestions.Ceci, combiné à une analyse du dictionnaire et 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.Calculer simplement la force du mot de passe et montrant un indicateur de force visuelle pour un utilisateur, c'est bien, mais insuffisant.À moins qu’elle ne soit appliquée, de nombreux utilisateurs l’ignoreront probablement.

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

Utiliser Troy Hunt Ai-je été connecté à l'API pour 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 encore - Ou :Prévenir les tentatives de connexion Rapid-Fire

Tout d’abord, jetez un œil aux chiffres : Vitesses de récupération de mot de passe – Combien de temps votre mot de passe restera-t-il conservé

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

Ça prend pratiquement pas de temps pour déchiffrer un mot de passe faible, même si vous le déchiffrez avec un boulier
Ça prend pratiquement pas de temps pour déchiffrer un mot de passe alphanumérique à 9 caractères s'il est insensible à la casse
Ça prend pratiquement pas de temps pour déchiffrer un mot de passe complexe, composé de symboles, de lettres et de chiffres, en majuscules et minuscules, s'il est moins de 8 caractères (un ordinateur de bureau peut rechercher l'intégralité de l'espace de touches jusqu'à 7 caractères en quelques jours, voire quelques heures)
Il faudrait cependant énormément de temps pour déchiffrer ne serait-ce qu'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.le Force brute attaque) n'est vraiment pas si difficile.Mais l'empêcher droite n'est pas aussi facile qu'il y paraît.

De manière générale, vous disposez de trois choix, tous efficaces contre les attaques par force brute. (et les attaques par dictionnaire, mais comme vous utilisez déjà une politique de mots de passe stricte, elles ne devraient pas poser de problème):

Présenter un CAPTCHA après N tentatives infructueuses (ennuyeuses à souhait et souvent inefficaces -- mais je me répète ici)
Verrouillage des comptes et exigeant une vérification de l'e-mail après N tentatives infructueuses (il s'agit d'un DoS attaque imminente)
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).

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

1 tentative échouée = pas de délai
2 tentatives infructueuses = 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 infructueuses = délai de 16 secondes
etc.

Une attaque DoS avec ce schéma serait très peu pratique, car le temps de verrouillage qui en résulte est légèrement supérieur à la somme des temps de verrouillage précédents.

Clarifier:Le retard est pas un délai avant de renvoyer la réponse au navigateur.Il s'agit plutôt d'un délai d'attente ou d'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.

Bonne pratique n°2 : Un délai de durée moyenne qui entre en vigueur après N tentatives infructueuses, comme :

1 à 4 tentatives infructueuses = aucun délai
5 tentatives infructueuses = délai de 15 à 30 minutes

Une attaque DoS contre ce schéma serait tout à fait peu pratique, 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.

Bonne pratique n°3 : Combiner 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
Plus de 5 tentatives infructueuses = délai de 20 secondes

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

1 tentative échoué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 bonnes pratiques de l'OWASP (lien 1 de la liste MUST-READ) et doit être considéré comme une bonne pratique, même s'il est certes restrictif.

Mais en règle générale, je dirais :plus votre politique de mot de passe est stricte, 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 retardées avant d'activer la limitation.

DoS attaquant ce système de limitation de connexion final serait très pas pratique.Et comme touche finale, autorisez toujours le passage des connexions persistantes (cookie) (et/ou un formulaire de connexion vérifié par CAPTCHA), afin que les utilisateurs légitimes ne soient même pas retardés. pendant que l'attaque est en cours.De cette façon, l’attaque DoS, très peu pratique, devient une menace. extrêmement attaque peu pratique.

De plus, il est logique d'effectuer une limitation plus agressive sur les comptes d'administrateur, car ce sont les points d'entrée les plus attrayants.

PARTIE VII :Attaques distribuées par force brute

Soit dit en passant, les attaquants plus avancés tenteront de contourner la limitation des connexions en « répartissant leurs activités » :

Répartir 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 faire en raison de notre limitation), ils choisiront LE mot de passe le plus courant et l'essayeront contre 50 000 utilisateurs.De cette façon, non seulement ils contournent les mesures de tentatives maximales telles que les CAPTCHA et la limitation de connexion, mais leurs chances de succès augmentent également, puisque le mot de passe numéro 1 le plus courant est bien plus probable que le numéro 49.995.
Espacer les demandes de connexion pour chaque compte utilisateur, disons, de 30 secondes, pour se faufiler sous le radar

Ici, la meilleure pratique serait enregistrer le nombre d'échecs de connexion, à l'échelle du système, et en utilisant une moyenne mobile de la fréquence des mauvaises connexions de votre site comme base pour une limite supérieure que vous imposez ensuite à tous les utilisateurs.

Trop abstrait ?Permettez-moi de reformuler :

Supposons que votre site ait enregistré en moyenne 120 mauvaises connexions par jour au cours des 3 derniers mois.En utilisant cela (moyenne mobile), votre système peut définir la limite globale à 3 fois cette valeur, 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 une journée (ou mieux encore, 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, ce qui signifie de courts délais pour TOUS les utilisateurs. (toujours, à l'exception des connexions par cookies et/ou des connexions CAPTCHA de sauvegarde).

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

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 dont les clés sont volées ou des utilisateurs se connectant à des sites de phishing.Les connexions peuvent être davantage protégées grâce à une authentification à deux facteurs, qui utilise des facteurs hors bande tels que des codes à usage unique reçus lors d'un appel téléphonique, d'un message SMS, d'une application ou d'un dongle.Plusieurs fournisseurs proposent des services d'authentification à deux facteurs.

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

LIENS À LIRE À LIRE À propos de l'authentification Web

Autres conseils

Article définitif

Envoi des identifiants

La seule façon pratique d'envoyer des informations d'identification de manière 100 % sécurisée est d'utiliser SSL.Utiliser JavaScript pour hacher le mot de passe n'est pas sûr.Pièges courants liés au hachage de mot de passe côté client :

Si la connexion entre le client et le serveur n'est pas crypté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, il pourrait écouter les réponses des clients et se faire passer parfaitement pour les utilisateurs, etc.etc.SSL avec 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 est Moins 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ée PDS, mais c'est breveté (même si c'est licence 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éutilisent 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'applications.OWASP recommande l'utilisation d'Argon2 comme votre premier choix pour les nouvelles applications.Si cela 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, 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, stockez le salé hacher.Un sel 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.Voir ici pour en savoir plus à ce sujet.

Cela signifie que vous ne pouvez pas envoyer à l'utilisateur ses mots de passe oubliés (car vous ne disposez que du hachage).Ne réinitialisez pas le mot de passe de l'utilisateur à moins d'avoir authentifié l'utilisateur (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.Lire PARTIE III :Utiliser des questions secrètes dans @Jens Roland répond ici dans ce wiki.

Cookies de session

Une fois l'utilisateur connecté, le serveur lui envoie 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 sont aussi sécurisés que le reste de la machine du client et les autres communications.Ils peuvent être lus à partir du disque, détectés dans le trafic réseau, interceptés par une attaque de script intersite, hameçonnés à 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 (fermeture du navigateur ou sortie de 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 qu'il doit se connecter réellement pour les opérations sensibles.Ceci est populaire auprès des sites commerciaux 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 sur Amazon, ils vous montrent une page qui semble être connectée, mais lorsque vous passez une commande (ou modifiez votre adresse de livraison, votre carte de crédit, etc.), ils vous demandent de confirmer. votre mot de passe.

En revanche, les sites Web financiers tels que les banques et les cartes de crédit ne contiennent que des données sensibles et ne doivent pas autoriser la connexion automatique ni un mode de sécurité faible.

Liste des ressources externes

À faire et à ne pas faire lors de l'authentification client sur le Web (PDF)
Article académique de 21 pages avec de nombreux bons conseils.
Demandez à YC :Meilleures pratiques pour l'authentification des utilisateurs
Forum de discussion sur le sujet
Vous stockez probablement les mots de passe de manière incorrecte
Article d'introduction sur le stockage des mots de passe
Discussion:Horreur de codage :Vous stockez probablement les mots de passe de manière incorrecte
Discussion sur le forum à propos d'un article sur Coding Horror.
Ne stockez jamais les mots de passe dans une base de données !
Un autre avertissement concernant le stockage des mots de passe dans la base de données.
Craquage de mot de passe
Article Wikipédia sur les faiblesses de plusieurs systèmes de hachage de mots de passe.
Assez avec les tables arc-en-ciel :Ce que vous devez savoir sur les systèmes de mots de passe sécurisés
Discussion sur les tables arc-en-ciel et comment se défendre contre elles et contre d'autres fils de discussion.Comprend une discussion approfondie.

Tout d’abord, une forte mise en garde : cette réponse n’est pas la mieux adaptée à cette question précise.Cela ne devrait certainement pas être la meilleure réponse !

Je vais continuer et mentionner la proposition de Mozilla ID du navigateur (ou peut-être plus précisément, le Protocole de messagerie vérifié) dans le but de trouver une voie de mise à niveau vers de meilleures approches d'authentification à l'avenir.

Je vais le résumer ainsi :

Mozilla est une organisation à but non lucratif avec valeurs qui correspondent bien à la recherche de bonnes solutions à ce problème.
La réalité aujourd'hui est que la plupart des sites Web utilisent l'authentification par formulaire.
L'authentification basée sur les formulaires présente un inconvénient majeur, à savoir un risque accru de Hameç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).
Étant donné que les navigateurs sont implicitement fiables (l’idée même d’un agent utilisateur est d’agir au nom de l’utilisateur), ils peuvent contribuer à améliorer cette situation.
La principale force qui freine le progrès ici est impasse de déploiement.Les solutions doivent être décomposées en étapes qui apportent à elles seules des avantages supplémentaires.
La méthode décentralisée la plus simple pour exprimer une identité intégrée à l’infrastructure Internet est le nom de domaine.
Deuxième niveau d'expression de l'identité, chaque domaine gère son propre ensemble de comptes.
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, universellement reconnu comme étant une adresse e-mail.
Les fournisseurs de messagerie sont déjà de facto les principaux fournisseurs d’identité en ligne.Les flux actuels de réinitialisation de mot de passe 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.
Le protocole de courrier électronique 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 disposez d'un compte sur le domaine A.
Pour les navigateurs qui ne prennent pas en charge le protocole de courrier électronique vérifié (actuellement tous), Mozilla fournit une cale qui implémente le protocole dans le code JavaScript côté client.
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 uniquement destinée à permettre un chemin de mise à niveau, et il est de loin préférable que les services de messagerie fournissent eux-mêmes ces assertions.
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 ou non aux affirmations de Mozilla.Le service de Mozilla vérifie la propriété du compte des utilisateurs en utilisant les moyens conventionnels d'envoi d'un e-mail avec un lien de confirmation.
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.
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 », « professionnelles », « militantisme politique », etc.) qu'il peut utiliser pour s'identifier sur le site.
Un autre grand avantage de l'interface utilisateur recherché dans le cadre de cet effort est aider le navigateur à en savoir plus sur la session de l'utilisateur – avec qui ils sont actuellement connectés, principalement – il peut donc l'afficher dans le chrome du navigateur.
En raison de la nature distribuée de ce système, il évite le verrouillage sur des sites majeurs comme Facebook, Twitter, Google, etc.N'importe quel individu peut posséder son propre domaine et donc agir en tant que son propre fournisseur d'identité.

Il ne s’agit pas strictement d’une « authentification par formulaire pour les sites Web ».Mais il s’agit d’un effort pour passer de la norme actuelle d’authentification basée sur un formulaire à quelque chose de plus sécurisé :authentification prise en charge par le navigateur.

Je pensais juste partager cette solution que j'ai trouvée fonctionner très bien.

Je l'appelle le Champ factice (même si je n'ai pas inventé cela, alors ne me croyez pas).

En bref:il vous suffit d'insérer ceci 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 utilisez déjà un champ appelé e-mail, vous devriez essayer de nommer le champ factice autrement, 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 le input champ en utilisant CSS ou JavaScript/jQuery - selon ce qui vous convient le mieux - juste ne le faites pas définir l'entrée type à hidden sinon le bot ne tombera pas dans le piège.

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

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.Ainsi, 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 quel que soit le nom que vous lui donnez) et tentera logiquement de le remplir avec les données appropriées.Peu importe si vous avez stylisé 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, cela ne nous importe pas tant qu'elle est supérieure à 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 uniquement CAPTCHA, mais finalement, cela aboutissait à environ cinq messages de spam toutes les heures.L'ajout du champ factice dans le formulaire a empêché (au moins jusqu'à présent) l'apparition de tous les spams.

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

Avertissement:Bien entendu, cette méthode n’est pas infaillible à 100 %.Les robots peuvent être programmés pour ignorer les champs de saisie avec le style display:none appliqué à celui-ci.Vous devez également penser aux personnes qui utilisent une forme de saisie semi-automatique (comme la plupart des navigateurs l'ont intégré !) pour remplir automatiquement tous les champs du formulaire à leur place.Ils pourraient tout aussi bien choisir 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!

Je ne pense pas que la réponse ci-dessus soit "fausse", mais de nombreux domaines d'authentification ne sont pas abordés (ou plutôt l'accent est mis sur "comment mettre en œuvre des sessions de cookies", et non sur "quelles options sont disponibles et quels sont les échanges). -offs".

Mes modifications/réponses suggérées sont

Le problème réside davantage dans la configuration du compte que dans la vérification du mot de passe.
L'utilisation de l'authentification à deux facteurs est bien plus sécurisée que des moyens plus intelligents de cryptage de mot de passe.
N'essayez pas d'implémenter votre propre formulaire de connexion ou stockage de base de données de mots de passe, sauf si les données stockées sont sans valeur à la création de compte et auto-générée (c'est-à-dire le style Web 2.0 comme Facebook, Flickr, etc.)
1. L'authentification Digest est une approche basée sur des normes prise en charge par 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 de « sessions » ou de cookies puisque le navigateur lui-même recryptera 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.Il s'agit d'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 créée à la main.Demandez simplement, par demande, si la demande est authentifiée.Tout le reste doit être pris en charge par la configuration et par un logiciel tiers de confiance.

Donc ...

Premièrement, on confond la création initiale d'un compte (avec un mot de passe) avec la revérification ultérieure du mot de passe.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 sur son nom.Si je crée un compte intranet/extranet de l'hôpital, la valeur réside dans tous les dossiers médicaux, et donc je faire se soucier de l’identité (*) du créateur du compte.

C’est la partie la plus difficile.Le seulement une 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 tous 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/le hachage de la photo avec la clé privée de l'hôpital.Nous pouvons désormais échanger des clés et des jetons en toute sécurité.Tout comme quiconque fait 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 parcelle d'une galère, et pas très web 2.0.Cependant, c'est le seul moyen sécurisé de créer de nouveaux comptes ayant accès à des informations précieuses qui n'ont pas été créées par vous-même.

Kerberos et SPNEGO - mécanismes d'authentification unique avec un tiers de confiance - essentiellement, l'utilisateur vérifie auprès d'un tiers de confiance.(NB : ce n'est en aucun cas un moyen de ne pas faire confiance OAuth)
PDS - une sorte d'authentification intelligente par mot de passe sans tiers de confiance.Mais nous entrons ici dans le domaine du « il est plus sûr d’utiliser l’authentification à deux facteurs, même si cela coûte plus cher »
SSL côté client - donnez 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 la mise en œuvre d'approches plus sécurisées.Un jour, nous verrons peut-être un véritable ICP largement accepté et donc plus de formulaires et de bases de données d'authentification laminés.Un jour...

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

Plus vite vous pouvez créer des hachages, plus vite tout 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 peu pratique pour les mots de passe plus longs (8 chiffres +)

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

Blog technique Dropbox » Archives du blog » zxcvbn :estimation réaliste de la force du mot de passe

Ma règle préférée en matière de systèmes d'authentification :utilisez des phrases secrètes, pas des mots de passe.Facile à retenir, difficile à déchiffrer.Plus d'informations: Horreur de codage :Mots de passe vs.Phrases de passe

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 pour les administrateurs que pour 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 très pénibles pour les utilisateurs réguliers.L'une de celles que j'ai utilisées consiste à brouiller l'URL de connexion pour l'accès administrateur et à envoyer à l'administrateur la nouvelle URL.Arrête immédiatement toute attaque par force brute, car votre nouvelle URL peut être arbitrairement difficile (chaîne aléatoire très longue), mais le seul inconvénient de votre utilisateur administrateur est de suivre un lien dans son e-mail.L’attaquant ne sait même plus où poster.

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 poing PARTIE IV :Fonctionnalité de mot de passe oublié dans la première réponse, je ferais un point sur les attaques chronométrées.

Dans le Mémorisez votre mot de passe formulaires, un attaquant pourrait potentiellement vérifier une liste complète d’e-mails et détecter ceux qui sont enregistrés dans le système (voir lien ci-dessous).

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

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

Je voudrais ajouter un commentaire très important :-

"Dans un entreprise, intra- net », la plupart, sinon la totalité, de ce qui précède pourrait 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 ...) ne peut être résolu qu'au sein du « réseau interne de l'entreprise ». (Quel réseau inclut comme par magie tous les « guerriers de la route » connectés à un VPN.)

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

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

De votre point de vue, vous savez simplement ceci :que n'importe qui qui se rend légitimement sur votre site Web doit être accompagné de [une variable de l'environnement contenant comme par magie ...] un «jeton». (c'est à dire. L'absence d'un tel jeton doit constituer un motif immédiat de 404 Not Found.)

La valeur du jeton n'a aucun sens pour vous, mais, si le besoin s'en fait sentir, "des moyens appropriés existent" par lesquels votre site Web peut "interroger [avec autorité] quelqu'un qui connaît (LDAP...etc.)" à propos de tout et chaque (!) question que vous pourriez vous poser.En d'autres termes, vous faites pas profitez-en n'importe lequel "Logique locale." Au lieu de cela, vous vous renseignez sur l'autorité et faites implicitement confiance à son verdict.

Euh hein...c'est assez un changement mental par rapport à « l'Internet sauvage et laineux ».

Utiliser Connexion OpenID ou Accès géré par l'utilisateur.

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

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow