Le guide définitif pour l'authentification d'un site Web basé sur un formulaire

voix
4k

authentification par formulaire pour les sites web

Nous croyons que le débordement de pile ne doit pas être seulement une ressource pour les questions techniques très spécifiques, mais aussi des lignes directrices générales sur la façon de résoudre des variations sur des problèmes communs. « Authentification par formulaire pour les sites web » devrait être un sujet bien pour une telle expérience.

Il devrait inclure des sujets tels que:

  • Comment s'identifier
  • Comment déconnecter
  • Comment rester connecté
  • Gestion des cookies (y compris les paramètres recommandés)
  • SSL / cryptage HTTPS
  • Comment stocker les mots de passe
  • Poser des questions secrètes
  • Oublié le nom d'utilisateur / mot de passe fonctionnalité
  • L' utilisation de nonces pour éviter des falsifications de demande cross-site (CSRF)
  • OpenID
  • case à cocher « Se souvenir de moi »
  • Navigateur autocomplétion des noms d'utilisateur et mots de passe
  • URL secrètes (public URL protégée par digest)
  • Vérification de la force du mot de passe
  • validation E-mail
  • et beaucoup plus sur l' authentification par formulaire ...

Il ne devrait pas inclure des choses comme:

  • Rôles et autorisation
  • l'authentification de base HTTP

S'il vous plaît nous aider:

  1. suggérant sous-rubriques
  2. Envoi de bons articles sur ce sujet
  3. Modification de la réponse officielle
Créé 02/08/2008 à 20:51
source utilisateur
Dans d'autres langues...                            


12 réponses

voix
3k

PARTIE I: comment ouvrir une session

Nous supposons que vous vous savez déjà comment construire un login + mot de passe formulaire HTML qui affiche les valeurs à un script côté serveur pour l'authentification. Les sections ci-dessous traiteront des modèles pour auth pratique son, et comment éviter les pièges de sécurité les plus courantes.

Pour HTTPS ou non HTTPS?

À moins que la connexion est déjà sécurisé (qui est, Tunneled via HTTPS en utilisant SSL / TLS), votre formulaire de connexion valeurs seront envoyées en texte clair, qui permet à toute personne espionnant sur la ligne entre le navigateur et le serveur Web sera en mesure de lire les connexions lors de leur passage par. Ce type de mise sur écoute se fait régulièrement par les gouvernements, mais en général, nous ne traitera pas des fils « propriété » autres que de dire ceci: Si vous protégez quelque chose d'important, utilisez le protocole HTTPS.

Essentiellement, la seule pratique moyen de protection contre les écoutes téléphoniques / reniflage de paquets lors de la connexion est en utilisant le protocole HTTPS ou un autre schéma de chiffrement par certificat (par exemple, TLS ) ou un système défi-réponse éprouvée et testée (par exemple, le Diffie-Hellman SRP à base). Toute autre méthode peut être facilement contournée par un attaquant d'écoute clandestine.

Bien sûr, si vous êtes prêt à obtenir un peu pratique, vous pouvez également utiliser une certaine forme de système d'authentification à deux facteurs (par exemple, l'application Google Authenticator, un livre de code « style de guerre froide » physique, ou un dongle générateur de clé RSA). Si elle est appliquée correctement, cela pourrait fonctionner même avec une connexion non sécurisée, mais il est difficile d'imaginer qu'un dev serait prêt à mettre en œuvre auth à deux facteurs, mais pas le protocole SSL.

(Ne pas) roulées propre cryptage / hachage JavaScript

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 noble pensée, il est essentiellement inutile (et peut être une faille de sécurité ) à moins qu'il soit associé à l' un des plus haut - qui est, soit sécuriser la ligne avec un cryptage fort ou en utilisant un essayé et testé défi-réponse mécanisme (si vous ne savez pas ce qui est, il suffit de savoir qu'il est l' un des plus difficiles à prouver, plus difficile à concevoir, et plus difficiles à mettre en œuvre les concepts de la sécurité numérique).

Il est vrai que hachant le mot de passe peut être efficace contre la divulgation par 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 du JavaScript) ou les attaques par force brute (puisque vous distribuez l'attaquant à la fois le nom d' utilisateur, le sel et le mot de passe haché).

Captchas contre l'humanité

Captchas sont destinés à contrecarrer une catégorie spécifique d'attaque: automatisé dictionnaire / brute d' essai et d'erreur de force sans opérateur humain. Il ne fait aucun doute que c'est une menace réelle, mais il existe des moyens d' y faire face en toute transparence qui ne nécessitent pas un CAPTCHA, spécialement bien conçus les systèmes de limitation de connexion de serverside - nous en parlerons plus loin.

Sachez que les implémentations CAPTCHA ne sont pas créés aussi bien; ils ne sont souvent pas humain résoluble, la plupart d'entre eux sont en fait inefficaces contre les robots, tous sont inefficaces contre le travail du tiers monde pas cher (selon OWASP , le taux de sweatshop actuel est de 12 $ par 500 tests), et certaines implémentations peuvent être techniquement illégale dans certains pays (voir fiche OWASP authentification Cheat ). Si vous devez utiliser un CAPTCHA, utilisez Google reCAPTCHA , car il est difficile OCR par définition (car il utilise déjà OCR-scans de livres mal classés) et essaie très dur pour être facile à utiliser.

Personnellement, je tends à trouver captchas ennuyeux, et les utiliser uniquement en dernier recours lorsqu'un utilisateur n'a pas se connecter plusieurs fois et les retards d'étranglement sont maxxed out. Cela se produira assez rarement pour être acceptable, et il renforce le système dans son ensemble.

Stockage des mots de passe / Vérification des connexions

Cela peut enfin connaissance commune après tous les hacks très médiatisés et les fuites de données utilisateur que nous avons vu ces dernières années, mais il faut dire: Ne pas stocker les mots de passe en texte clair dans votre base de données. Bases de données utilisateur sont piraté systématiquement, dupliquées ou glanés par injection SQL, et si vous stockez des mots de passe, premières plaintext, qui est jeu instantané sur la sécurité de votre connexion.

Donc , si vous ne pouvez pas stocker le mot de passe, comment voulez - vous vérifier que la combinaison de login + mot de passe POSTé du formulaire de connexion est correcte? La réponse est hachage à l' aide d' une fonction de dérivation de clé . Chaque fois qu'un nouvel utilisateur est créé ou un mot de passe est changé, vous prenez le mot de passe et l' exécuter à travers un KDF, comme Argon2, bcrypt, scrypt ou PBKDF2, tournant le mot de passe en texte clair ( le « correcthorsebatterystaple ») dans une longue chaîne aléatoire prospectifs , ce qui est beaucoup plus sûr de 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é, ce temps qui passe dans le sel et comparer la chaîne de hachage à la valeur stockée dans votre base de données. Argon2, bcrypt et magasin scrypt le sel avec le hachage déjà. Consultez cet article sur sec.stackexchange pour des informations plus détaillées.

La raison pour laquelle on utilise un sel est parce que le hachage en soi ne suffit pas - vous voulez ajouter un soi-disant « sel » pour protéger le hachage contre des tables arc -en - . Un sel empêche efficacement deux mots de passe qui correspondent exactement d'être stocké en tant que la même valeur de hachage, ce qui empêche toute la base de données en cours de numérisation en une seule opération si un attaquant exécute un mot de passe deviner attaque.

Un hachage cryptographique ne doit pas être utilisé pour le stockage de mot de passe , car l' utilisateur des mots de passe sélectionnés ne sont pas assez forts (ne contiennent généralement pas suffisamment d' entropie) et un mot de passe deviner l' attaque pourrait être achevée en un temps relativement court par un attaquant ayant accès aux hash. Voilà pourquoi un KDF est utilisé - ceux - ci efficacement « étirer la clé » ce qui signifie que chaque mot de passe deviner un attaquant fait implique itérer l'algorithme de hachage à plusieurs reprises, par exemple 10.000 fois, ce qui rend le mot de passe de l'attaquant deviner 10.000 fois plus lent.

Les données de session - « Vous êtes connecté en tant Spiderman69 »

Une fois que le serveur a vérifié le login et le mot de passe contre votre base de données utilisateur et trouvé une correspondance, le système a besoin d'un moyen de se rappeler que le navigateur a été authentifié. Ce fait ne doit jamais être stocké côté serveur dans les données de session.

Si vous n'êtes pas familier avec les données de session, voici comment cela fonctionne: Une seule chaîne est stockée dans un cookie expirant et utilisé pour faire référence généré aléatoirement une collecte de données - les données de session - qui est stocké sur le serveur. Si vous utilisez un framework MVC, cela est sans aucun doute déjà traité.

Si possible, assurez - vous que le cookie de session a la sécurité et HTTP Seuls les drapeaux définis lors de l' envoi au navigateur. Le drapeau httponly offre une certaine protection contre le cookie lu par une attaque XSS. Le drapeau sécurisé assure que le cookie n'est renvoyé via HTTPS, et protège donc contre les attaques renifler du réseau. La valeur du cookie ne doit pas être prévisible. Lorsqu'un témoin faisant référence à une session non-existante est présentée, sa valeur doit être remplacée immédiatement pour empêcher la fixation de session .

PARTIE II: Comment rester connecté - The Infamous checkbox "Remember Me"

Les cookies de connexion persistants (fonctionnalité "remember me") sont une zone dangereuse; d'une part, ils sont tout à fait aussi sûr que les connexions classiques lorsque les utilisateurs comprennent comment les gérer; et d'autre part, ils sont un énorme risque de sécurité dans les mains des utilisateurs imprudents, qui peuvent les utiliser sur des ordinateurs publics et oublier de se déconnecter, et qui ne savent pas ce que les cookies sont navigateur ou comment les supprimer.

Personnellement, j'aime les connexions persistantes pour les sites web que je visite sur une base régulière, mais je sais comment les manipuler en toute sécurité. Si vous êtes certain que vos utilisateurs connaissent le même, vous pouvez utiliser les connexions persistantes avec une conscience propre. Sinon - bien, alors vous pouvez vous abonner à la philosophie que les utilisateurs qui négligent avec leurs identifiants de connexion a fait venir sur eux-mêmes si elles se piraté. Il est pas comme nous allons les maisons de nos utilisateurs et arrachons tous ceux facepalm induisant Post-It note avec des mots de passe qu'ils ont alignés sur le bord de leurs moniteurs, soit.

Bien sûr, certains systèmes ne peuvent pas se permettre d'avoir des comptes piraté; pour de tels systèmes, il n'y a aucun moyen que vous pouvez justifier d' avoir des connexions persistantes.

Si vous décidez de mettre en œuvre les cookies persistants de connexion, voici comment faire:

  1. Tout d' abord, prenez le temps de lire l'article de l' initiative Paragon sur le sujet. Vous aurez besoin d'obtenir un tas d'éléments à droite, et l'article fait un excellent travail d'expliquer chacun.

  2. Et juste pour réitérer l' un des pièges les plus courants, NE PAS CONSERVER LE COOKIE LOGIN Persistants (TOKEN) DANS VOTRE BASE DE DONNÉES, SEULEMENT HASHTABLE DE LUI! Le jeton de connexion est équivalent mot de passe, donc si un attaquant a la main sur votre base de données, ils pourraient utiliser les jetons pour se connecter à un compte, comme si elles étaient des combinaisons login-mot de passe en texte clair. Par conséquent, utiliser le hachage (selon https://security.stackexchange.com/a/63438/5002 un hachage faible fera très bien à cet effet) lors de l' enregistrement des jetons de connexion persistants.

PARTIE III: Utilisation des questions secrètes

Ne pas mettre en œuvre des « questions secrètes » . La fonction «questions secrètes est un anti-modèle de sécurité. Lire le papier du numéro de liaison 4 de la liste incontournable. Vous pouvez demander à Sarah Palin à propos de celui - là, après son Yahoo! compte e - mail piraté lors d' une précédente campagne présidentielle parce que la réponse à sa question de sécurité était ... « Wasilla lycée »!

Même avec des questions définies par l'utilisateur, il est très probable que la plupart des utilisateurs choisiront soit:

  • Un « standard » question secrète comme le nom de jeune fille de la mère ou d'un animal favori

  • Un simple morceau de futilités que quelqu'un pourrait soulever de leur blog, profil LinkedIn, ou similaire

  • Toute question qui est plus facile de répondre que de deviner leur mot de passe. Ce qui, pour un mot de passe décent, est à toutes les questions que vous pouvez imaginer

En conclusion, les questions de sécurité sont par nature précaire dans pratiquement toutes leurs formes et variations, et ne doivent pas être utilisés dans un système d'authentification pour une raison quelconque.

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

PARTIE IV: Mot de passe oublié Fonctionnalité

Je l' ai déjà mentionné pourquoi vous devriez ne jamais utiliser des questions de sécurité pour le traitement oublié / perdu les mots de passe de l' utilisateur; il va sans dire que vous ne devriez jamais les utilisateurs de messagerie leurs mots de passe réels. Il y a au moins deux pièges tout trop communs pour éviter dans ce domaine:

  1. Ne pas réinitialiser un mot de passe oublié un mot de passe fort autogenerated - ces mots de passe sont notoirement difficiles à retenir, ce qui signifie que l'utilisateur doit le modifier ou l' écrire - dire, sur un jaune vif post-it sur le bord de leur moniteur. Au lieu de définir un nouveau mot de passe, il suffit de laisser les utilisateurs choisir un nouveau tout de suite - qui est ce qu'ils veulent faire de toute façon.

  2. Toujours le code de hachage mot de passe perdu / jeton dans la base de données. NOUVEAU , ce code est un autre exemple d'un équivalent de mot de passe, il DOIT être haché dans le cas où un attaquant a la main sur votre base de données. Lorsqu'un code de mot de passe perdu est demandé, envoyer le code à l'adresse plaintext e - mail de l'utilisateur, hachage, enregistrez le hachage dans votre base de données - et jeter l'original . Tout comme un mot de passe ou un jeton de connexion persistante.

Une note finale: assurez-vous toujours que votre interface pour entrer dans le « code de mot de passe perdu » est au moins aussi sûr que votre formulaire de connexion lui-même, ou un attaquant sera tout simplement l'utiliser pour accéder à la place. Faire en sorte que vous générez très longtemps « perdu les codes de mot de passe » (par exemple, 16 cas de caractères alphanumériques sensibles) est un bon début, mais envisager d'ajouter le même schéma d'étranglement que vous faites pour le formulaire de connexion elle-même.

PARTIE V: Vérification de mot de passe Force

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

Ok, alors peut - être la liste n'est pas la canonique liste des mots de passe plus communs sur tout système où jamais , mais il est une bonne indication de la façon dont mal les gens vont choisir leurs mots de passe quand il n'y a pas de politique appliquée en place. De plus, la liste semble effroyablement près de la maison quand on le compare aux analyses accessibles au public des mots de passe récemment volés.

Donc: Sans exigences de résistance minimale de mot de passe, 2% des utilisateurs utilisent l'un des 20 premiers mots de passe les plus courants. Signification: si un attaquant obtient seulement 20 tentatives, 1 à 50 comptes sur votre site seront piratable.

Contrecarrer cela nécessite le calcul de l'entropie d'un mot de passe et l' application d' 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. Ce, lorsqu'il est combiné avec une analyse de la mise en page de dictionnaire et clavier (par exemple, « qwertyuiop » est un mauvais mot de passe), peut rejeter 99% de tous les mots de passe mal choisis à un niveau de 18 bits d'entropie. Il suffit de calculer la force de mot de passe et montrant un appareil de mesure de force visuelle à un utilisateur est bon, mais insuffisant. À moins qu'il soit appliqué, beaucoup d'utilisateurs sera plus ignorer probable qu'il.

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

PARTIE VI: beaucoup plus - Ou: prévenir les tentatives Rapid-Fire Connexion

Tout d' abord, jetez un oeil sur les chiffres: Speeds Password Recovery - Combien de temps votre mot de passe se lever

Si vous n'avez pas le temps de regarder à travers les tableaux de ce lien, voici la liste:

  1. Il prend pratiquement pas de temps pour casser un mot de passe faible, même si vous le casser avec un boulier

  2. Il prend pratiquement pas de temps pour casser un mot de passe alphanumérique 9 caractères, si elle est insensible à la casse

  3. Il prend pratiquement pas de temps pour casser un complexe, symboles et lettres-et-numéros, mot de passe supérieur et minuscules, si elle est inférieure à 8 caractères (un PC de bureau peut rechercher l'ensemble keyspace jusqu'à 7 caractères dans un quelques jours , voire quelques heures)

  4. Il serait, cependant, prendre une quantité excessive de temps à se fissurer même un mot de passe de 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 un grand nombre de tentatives de connexion successives à tir rapide (la. Force brute attaque) est vraiment pas difficile. Mais empêcher droit n'est pas aussi facile qu'il semble.

D'une manière générale, vous avez trois choix qui sont tous efficaces contre les attaques par la force brute (et les attaques de dictionnaire, mais puisque vous employez déjà une forte politique de mots de passe, ils ne devraient pas être un problème) :

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

  • Comptes de verrouillage et nécessitant une vérification de courriel après N tentatives ratées (ce qui est une DoS attaque en attente de se produire)

  • Et enfin, la limitation de connexion : qui est, la fixation d' un délai entre les tentatives après N tentatives ratées (oui, les attaques DoS sont encore possibles, mais au moins ils sont beaucoup moins susceptibles et beaucoup plus compliqué à enlever).

Les meilleures pratiques # 1: Un court délai qui augmente avec le nombre de tentatives, comme forfait:

  • 1 tentative échouée = pas de retard
  • 2 tentatives ratées = retard de 2 sec
  • 3 tentatives infructueuses = retard 4 s
  • 4 tentatives infructueuses = 8 sec retard
  • 5 tentatives infructueuses = retard de 16 sec
  • etc.

DoS attaquer ce système serait très peu pratique, car le temps de verrouillage résultant est légèrement plus grand que la somme des temps de lock-out précédent.

Pour clarifier: Le retard est pas un délai avant de retourner la réponse au navigateur. Il est plus comme une période de temps mort ou réfractaire au cours de laquelle les tentatives de connexion à un compte spécifique ou d'une adresse IP spécifique ne sera pas acceptée ou évalué à tous. Cela est, les informations d' identification correctes ne reviendra pas dans une connexion réussie, et des informations d' identification incorrectes ne déclenchera pas une augmentation de retard.

Les meilleures pratiques # 2: Une temporisation de longueur moyenne qui entrera en vigueur après N tentatives ratées, comme:

  • 1-4 tentatives ratées = pas de retard
  • 5 tentatives ratées = retard min 15-30

DoS attaquer ce système serait tout à fait irréaliste, mais certainement faisable. , Il pourrait être pertinent de noter également qu'un tel retard peut être très gênant pour un utilisateur légitime. les utilisateurs oublieux vous détestera.

Les meilleures pratiques # 3: En combinant les deux approches - soit un fixe, court délai qui entre en vigueur après N tentatives ratées, comme:

  • 1-4 tentatives ratées = pas de retard
  • 5+ tentatives échouées = retard de 20 sec

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

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

Ce schéma final a été prise à partir des meilleures pratiques OWASP suggestions (lien 1 de la liste INCONTOURNABLE) LIRE, et devrait être considérée comme la meilleure pratique, même si elle est certes du côté restrictif.

En règle générale cependant, je dirais: la politique de votre mot de passe plus est, moins vous avez aux utilisateurs de bugs avec des retards. Si vous avez besoin forts (caractères alphanumériques sensibles à la casse + numéros requis et symboles) 9+ mots de passe de caractères, vous pouvez donner aux utilisateurs 2-4 tentatives de mot de passe non-retardé avant d'activer l'étranglement.

DoS attaquer ce système de limitation de connexion final serait très peu pratique. Et comme une touche finale, toujours autoriser les connexions persistantes (cookie) (et / ou un formulaire de connexion vérifié CAPTCHA) pour passer à travers, afin que les utilisateurs légitimes ne seront même pas être retardée alors que l'attaque est en cours . De cette façon, la très pratique attaque DoS devient une très attaque peu pratique.

De plus, il est logique de faire plus agressif sur la limitation des comptes d'administration, puisque ce sont les points d'entrée les plus attrayants

PARTIE VII: Distribué Brute Force Attacks

En passant, les attaquants les plus avancés vont essayer de contourner la limitation de connexion par « la diffusion de leurs activités »:

  • Les tentatives sur la distribution d'un botnet pour empêcher l'adresse IP de signalisation

  • Plutôt que de choisir un utilisateur et d'essayer les mots de passe les plus courants 50000 (qu'ils ne peuvent pas, à cause de notre étranglement), ils saisiront le mot de passe le plus commun et essayer contre les utilisateurs au lieu de 50.000. De cette façon, non seulement ils contournent les mesures maximales-tentatives comme CAPTCHAs et la limitation de connexion, leurs chances de succès augmente aussi, puisque le numéro 1 mot de passe le plus commun est beaucoup plus probable que le nombre 49,995

  • Espacer les demandes de connexion pour chaque compte utilisateur, par exemple, 30 secondes d'intervalle, de se faufiler sous le radar

Ici, la meilleure pratique serait l' exploitation forestière le nombre d'échecs de connexion, l' ensemble du système , et en utilisant une moyenne mobile de mauvaise connexion de la fréquence de votre site comme base pour une limite supérieure que vous imposez alors sur tous les utilisateurs.

Trop abstrait? Permettez-moi de reformuler:

Supposons que votre site a eu une moyenne de 120 par jour mauvaises connexions au cours des 3 derniers mois. L'utilisation que (moyenne mobile), votre système peut définir la limite globale de 3 fois que - à savoir. 360 tentatives échouées sur une période de 24 heures. Ensuite, si le nombre total de tentatives infructueuses pour tous les comptes dépasse ce nombre en un jour (ou mieux encore, surveiller le taux d'accélération et de déclenchement sur un seuil calculé), il active la limitation de connexion système à l'échelle - ce qui signifie des délais très courts pour tous les utilisateurs (encore, à l'exception des connexions de cookies et / ou de sauvegarde des connexions CAPTCHA).

J'ai aussi posté une question avec plus de détails et une très bonne discussion sur la façon d'éviter pitfals difficiles à repousser distribués attaques par force brute

PARTIE VIII: authentification à deux facteurs et les fournisseurs d'authentification

Vérification des pouvoirs peuvent être compromis, que ce soit par les exploits, les mots de passe d'être écrits et perdus, les ordinateurs portables avec des clés volées ou les utilisateurs d'entrer des connexions dans des sites de phishing. Logins peuvent encore être protégés par une authentification à deux facteurs, qui utilisent hors bande des facteurs tels que les codes à usage unique reçu d'un appel téléphonique, un message SMS, application ou dongle. Plusieurs fournisseurs offrent des services d'authentification à deux facteurs.

L'authentification peut être complètement déléguée à un service d'authentification unique sur, où un autre fournisseur gère la collecte des informations d'identification. Cela pousse le problème à un tiers de confiance. Google et Twitter à la fois fournir des services de l'authentification unique basée sur les normes, alors que Facebook offre une solution propriétaire similaire.

MUST-READ À propos des liens d'authentification Web

  1. Guide OWASP Pour l' authentification / OWASP authentification Cheat Sheet
  2. Décalogue de l'authentification du client sur le Web (document de recherche du MIT très lisible)
  3. Wikipedia: HTTP cookies
  4. questions de connaissances personnelles pour l'authentification Repli: Les questions de sécurité à l'ère de Facebook (très lisible document de recherche Berkeley)
Créé 25/01/2009 à 12:27
source utilisateur

voix
382

article définitif

Envoi des informations d'identification

La seule façon pratique d'envoyer des informations d' identification est 100% en toute sécurité en utilisant SSL . Utilisation de JavaScript pour hachage le mot de passe n'est pas sûr. Les pièges courants pour le hachage de mot de passe du côté client:

  • Si la connexion entre le client et le serveur est non chiffré, tout ce que vous faites est vulnérable aux attaques man-in-the-middle . Un attaquant pourrait remplacer le javascript entrant pour briser le hachage ou envoyer toutes les informations d' identification à leur serveur, ils pourraient écouter les réponses du client et usurper l' identité des utilisateurs parfaitement, etc. , etc. SSL avec les autorités de certification de confiance est conçu pour prévenir les attaques MitM.
  • Le mot de passe haché reçu par le serveur est moins sûr si vous ne faites pas du travail supplémentaire, 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 sous licence ) et il y a quelques bonnes implémentations disponibles.

Le stockage des mots de passe

Ne jamais stocker les mots de passe en texte clair dans la base de données. Même si vous ne se soucient pas de la sécurité de votre propre site. On suppose que certains de vos utilisateurs réutilisent le mot de passe de leur compte bancaire en ligne. Donc, stocker le mot de passe haché et jeter l'original. Et assurez - vous que le mot de passe ne se présente pas dans les journaux d'accès ou des journaux d'application. OWASP recommande l'utilisation de Argon2 comme premier choix pour les nouvelles applications. Si ce n'est pas disponible, ou PBKDF2 scrypt doivent être utilisés à la place. Et enfin , si aucune de ces disponibles, utilisez bcrypt.

Hash par eux - mêmes sont aussi précaires. Par exemple, les mots de passe identiques signifient hash identiques - ce qui rend les tables de recherche de hachage un moyen efficace de fissuration beaucoup de mots de passe à la fois. Au lieu de cela, stocker le Salted hachage. Un sel est une chaîne annexé au mot de passe avant de hachage - utiliser un autre sel (aléatoire) par l' utilisateur. Le sel est une valeur publique, de sorte que vous pouvez les stocker avec le hachage dans la base de données. Voir ici pour plus de détails.

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

Questions de sécurité

Les questions de sécurité ne sont pas sûrs - éviter de les utiliser. Pourquoi? Tout ce une question de sécurité fait, un mot de passe fait mieux. Lire PARTIE III: Utilisation des questions secrètes dans @Jens Roland répondre ici dans ce wiki.

Les cookies de session

Après que l'utilisateur se connecte, le serveur envoie à l'utilisateur un cookie de session. Le serveur peut récupérer le nom d'utilisateur ou l'identifiant du cookie, mais personne ne peut générer un tel cookie (TODO expliquer les mécanismes).

Les cookies peuvent être détournés : ils sont aussi sûr que le reste de la machine et d' autres communications du client. Ils peuvent être lus à partir du disque, renifler le trafic réseau, soulevé par une attaque de scriptage intersite, d'un DNS escroquées empoisonné de sorte que le client envoie leurs cookies aux serveurs mal. Ne pas envoyer des cookies persistants. Les cookies expirent à la fin de la session du client (près du navigateur ou de quitter votre domaine).

Si vous voulez autologin vos utilisateurs, vous pouvez définir un cookie persistant, mais il devrait être distinct d'un cookie de session complète. Vous pouvez définir un indicateur supplémentaire que l'utilisateur a connecté automatiquement dans et doit se connecter pour de vrai pour les opérations sensibles. Ceci est populaire avec des sites commerciaux qui veulent vous fournir une expérience de magasinage transparente, personnalisé mais toujours protéger vos données financières. Par exemple, lorsque vous revenez à visiter Amazon, ils vous montrent une page qui ressemble vous êtes connecté, mais quand vous allez passer une commande (ou modifier votre adresse de livraison, carte de crédit, etc.), ils vous demandent de confirmer votre mot de passe.

sites Web financiers tels que les banques et les cartes de crédit, d'autre part, ne sont données sensibles et ne doivent pas permettre la connexion automatique ou un mode de faible sécurité.

Liste des ressources externes

Créé 02/08/2008 à 21:40
source utilisateur

voix
146

Tout d'abord, une forte mise en garde que cette réponse n'est pas la meilleure solution pour cette question précise. Il ne doit certainement pas être la réponse top!

Je vais aller de l' avant et parler proposé de Mozilla BrowserID (ou peut - être plus précisément, le protocole Email Vérifié ) dans l'esprit de trouver un chemin de mise à niveau vers de meilleures approches pour l' authentification à l'avenir.

Je vais le résumer ainsi:

  1. Mozilla est un but non lucratif avec des valeurs qui correspondent bien à trouver de bonnes solutions à ce problème.
  2. Aujourd'hui, la réalité est que la plupart des sites Web utilisent l'authentification par formulaire
  3. Authentification par formulaire a un gros inconvénient, ce qui est un risque accru de phishing . Les utilisateurs sont invités à entrer des informations sensibles dans une zone contrôlée par une entité distante, plutôt que d' une zone contrôlée par son agent utilisateur (navigateur).
  4. Étant donné que les navigateurs sont implicitement confiance (l'idée d'un agent utilisateur est d'agir au nom de l'utilisateur), ils peuvent contribuer à améliorer cette situation.
  5. La principale force de freiner le progrès est ici impasse de déploiement . Les solutions doivent être décomposées en étapes qui offrent un certain avantage supplémentaire de leur propre chef.
  6. La méthode décentralisée plus simple pour exprimer l'identité qui est intégrée dans l'infrastructure Internet est le nom de domaine.
  7. En tant que second niveau d'expression de l'identité, chaque domaine gère son propre ensemble de comptes.
  8. La forme « compte @domaine » est concis et soutenu par un large éventail de protocoles et 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é primaire de facto en ligne. Les flux de réinitialisation de mot de passe actuel permettent généralement vous prenez le contrôle d'un compte si vous pouvez prouver que vous contrôlez l'adresse e-mail associée de ce compte.
  10. Vérifié Protocole Email a été proposé de fournir une méthode sécurisée, basée sur la cryptographie à clé publique, pour rationaliser le processus de prouver au domaine B que vous avez un compte sur le domaine A.
  11. Pour les navigateurs qui ne prennent pas en charge le protocole Vérifié Email (actuellement tous), Mozilla fournit une cale 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 Vérifié Email, le protocole permet à des tiers d'agir à titre d'intermédiaire de confiance, affirmant qu'ils ont vérifié la propriété d'un utilisateur d'un compte. Il n'est pas souhaitable d'avoir un grand nombre de ces tiers; cette capacité est destinée uniquement pour permettre une mise à niveau, et il est beaucoup préférable que les services de messagerie fournissent ces affirmations elles-mêmes.
  13. Mozilla offre leur propre service d'agir comme un tiers de confiance. Les fournisseurs de services (qui est, en se fondant Parties) mettant en œuvre le Protocole Verified Email peuvent choisir de faire confiance aux affirmations de Mozilla ou non. Le service de Mozilla vérifie la propriété du compte des utilisateurs en utilisant les moyens conventionnels d'envoyer un e-mail avec un lien de confirmation.
  14. Les fournisseurs de services peuvent, bien sûr, offrir ce protocole en option, en plus de toute autre méthode (s) d'authentification qu'ils souhaiteraient offrir.
  15. Un grand avantage de l'interface utilisateur recherché ici est le « sélecteur d'identité ». Lorsqu'un utilisateur visite un site et choisit d'authentifier, leur navigateur leur montre une sélection d'adresses e-mail ( « personnel », « travail », « l'activisme politique », etc.), ils peuvent utiliser pour s'identifier sur le site.
  16. Un autre grand avantage de l' interface utilisateur recherchée dans le cadre de cet effort est d' aider le navigateur en savoir plus sur la session de l'utilisateur - qui ils sont signés en tant que actuellement, principalement - il peut afficher que dans le navigateur Chrome.
  17. En raison de la nature distribuée de ce système, il évite l'enfermement dans les grands sites comme Facebook, Twitter, Google, etc. Toute personne peut posséder leur propre domaine et donc agir comme leur propre fournisseur d'identité.

Ce n'est pas strictement « authentification basée sur des formulaires pour les sites web ». Mais il est un effort de transition de la norme actuelle d'authentification basée sur un formulaire à quelque chose de plus sûr: l'authentification par navigateur pris en charge.

Créé 08/08/2011 à 16:32
source utilisateur

voix
120

Je pensais juste que je partage cette solution que je trouvais fonctionner très bien.

Je l' appelle le champ factice (bien que je ne l' ai pas inventé cela pour ne pas me créditer).

En bref: il vous suffit d'insérer ce dernier dans votre <form>et vérifiez qu'elle soit vide au moment de la validation:

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

L'astuce consiste à tromper un bot en pensant qu'il doit insérer des données dans un champ obligatoire, c'est pourquoi je l'entrée nommé « e - mail ». Si vous avez déjà un champ appelé e - mail que vous utilisez , vous devriez essayer de nommer le champ factice comme quelque chose d' autre « société », « téléphone » ou « emailaddress ». Il suffit de choisir quelque chose que vous savez que vous n'avez pas besoin et ce qui ressemble à quelque chose de gens normalement trouver logique de remplir dans un formulaire web. Maintenant cacher le inputchamp à l' aide CSS ou JavaScript / jQuery - tout ce que vous convient le mieux - il suffit de ne pas mettre l'entrée typeà hiddenou bien le bot ne tombera pas pour elle.

Lorsque vous validez le formulaire (client ou côté serveur) vérifier si votre champ factice a été rempli pour déterminer si elle a été envoyée par un être humain ou d'un robot.

Exemple:

Dans le cas d'un être humain: L'utilisateur ne verra pas le champ factice (dans mon cas nommé « e - mail ») et ne tentera pas de le remplir. Ainsi , la valeur du champ factice doit encore être vide lorsque le formulaire a été envoyé.

Dans le cas d'un bot: Le bot verra un champ dont le type est textet un nom email(ou quoi que ce soit vous l' avez appelé) et tenterez logiquement de le remplir avec des données appropriées. Il ne se soucie pas si vous redécorées la forme d'entrée avec un peu de fantaisie CSS, développeurs web le font tout le temps. Quelle que soit la valeur dans le champ factice est, nous ne nous soucions aussi longtemps qu'il est plus grand que les 0caractères.

J'ai utilisé cette méthode sur un livre d' or en combinaison avec CAPTCHA , et je ne l' ai pas vu un message de spam unique depuis. Je l' avais utilisé une solution CAPTCHA seulement avant, mais finalement il donné lieu à environ cinq messages de spam toutes les heures. Ajout du champ factice sous forme est arrêté (au moins jusqu'à présent) tous les spams d'apparaître.

Je crois que cela peut aussi être utilisé très bien avec une forme de connexion / authentification.

Attention : Bien sûr cette méthode n'est pas 100% infaillible. Bots peuvent être programmés pour ignorer les champs d'entrée avec le style display:noneappliqué. Vous devez également penser à des gens qui utilisent une certaine forme d'auto-complétion (comme la plupart des navigateurs ont intégré!) Pour remplir automatiquement les champs de formulaire pour eux. Ils pourraient tout aussi bien choisir un champ factice.

Vous pouvez aussi varier ce un peu en laissant le champ factice visible mais en dehors des limites de l'écran, mais cela est totalement à vous.

Sois créatif!

Créé 22/05/2012 à 13:11
source utilisateur

voix
71

Je ne pense pas que la réponse ci-dessus est « mauvais », mais il y a de grandes zones d'authentification qui ne sont pas touchés sur (ou plutôt l'accent est mis sur « la façon de mettre en œuvre des sessions de cookies », pas « quelles options sont disponibles et quels sont le commerce offs ».

Mes modifications / réponses proposées sont

  • Le problème réside plus dans la configuration de compte que dans la vérification de mot de passe.
  • L'utilisation de deux facteurs authenitication est beaucoup plus sûr que des moyens plus intelligents de cryptage de mot de passe
  • Ne pas essayer de mettre en œuvre votre propre stockage sous forme de connexion ou la base de données de mots de passe, à moins que les données stockées est à la création de toute valeur et compte autogénérés (qui est, le style Web 2.0 comme Facebook, Flickr , etc.)

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

Cela évite tout besoin d'avoir des « sessions » ou les cookies que le navigateur lui-même re-chiffrer la communication à chaque fois. Il est l'approche la plus de développement « léger ».

Cependant, je ne recommande pas, sauf pour les services à faible valeur publique. Ceci est un problème avec quelques-unes des autres réponses ci-dessus - ne pas essayer un re-mettre en œuvre des mécanismes de authetication côté serveur - ce problème a été résolu et est pris en charge par la plupart des principaux navigateurs. Ne pas utiliser les cookies. Ne pas stocker quoi que ce soit dans votre propre base de données roulées à la main. Il suffit de demander, par demande, si la demande est autheticated. Tout le reste doit être pris en charge par la configuration et les logiciels tiers de confiance.

Alors ...

Tout d' abord, nous confondons la création initiale d'un compte (avec un mot de passe) avec la nouvelle vérification du mot de passe par la suite. Si je suis Flickr et la création de votre site pour la première fois, le nouvel utilisateur a accès à la valeur zéro (espace web vierge). Je me fous si la personne qui crée le compte est couché sur leur nom. Si je crée un compte de l'intranet de l' hôpital / extranet, la valeur est dans tous les dossiers médicaux, et donc je ne se soucient de l'identité (*) du créateur de compte.

Ceci est la partie très très difficile. La seule solution décente est un web 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 les hash tous avec la clé privée. Vous pouvez ensuite visiter l'hôpital et l'administrateur système regarde votre passeport, Vérifie si la photo correspond, et HASHES alors le hachage page Web / photo avec la clé privée de l' hôpital. Désormais , nous pouvons échanger en toute sécurité les clés et jetons. Comme quelqu'un peut - il qui fait confiance à l'hôpital (il y a la sauce secrète BTW). L'administrateur système peut aussi vous donner un RSA dongle ou une autre authentification à deux facteurs.

Mais cela est beaucoup de tracas, et pas très web 2.0. Cependant, il est le seul moyen sûr de créer de nouveaux comptes qui ont accès à des informations précieuses qui ne sont pas auto-créé.

  1. Kerberos et SPNEGO - connexion unique sur les mécanismes avec un tiers de confiance - essentiellement l'utilisateur vérifie contre un tiers de confiance. (NB ce n'est pas en aucune façon le pas digne de confiance OAuth )

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

  3. SSL côté client - donner 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 client).

En fin de compte est un compromis entre - quel est le coût d'une atteinte à la sécurité contre le coût de la mise en œuvre des approches plus sûres. Un jour, nous pouvons voir une bonne infrastructure à clé publique largement acceptée et donc plus propres formes d'authentification et bases de données laminé. Un jour...

Créé 08/08/2011 à 17:29
source utilisateur

voix
48

Lorsque hachant, ne pas utiliser des 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, hash plus lentes sont meilleures.

Plus vite vous pouvez créer hash, plus vite tout vérificateur de la force brute peut fonctionner. Le ralentissement hachages donc ralentir force brute. Un algorithme de hachage lent fera forcer brute peu pratique pour les mots de passe plus longs (8 chiffres +)

Créé 09/08/2011 à 00:07
source utilisateur

voix
46

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

Dropbox Tech Blog »Blog Archive» zxcvbn: estimation de la force du mot de passe réaliste

Créé 08/11/2012 à 12:15
source utilisateur

voix
41

Ma règle préférée en ce qui concerne les systèmes d' authentification: utiliser les mots de passe, mots de passe. Facile à retenir, difficile à craquer. Plus d' info: Coding Horror: les mots de passe par rapport à des phrases clés

Créé 24/11/2012 à 22:15
source utilisateur

voix
20

Je voudrais ajouter une suggestion que je l'ai utilisé, basé sur la défense en profondeur. Vous n'avez pas besoin d'avoir le même système auth & auth pour les administrateurs que les utilisateurs réguliers. Vous pouvez avoir un formulaire de connexion séparé sur une URL distincte exécution d'un code distinct pour les demandes qui accordera des privilèges élevés. Celui-ci peut faire des choix qui serait une douleur totale aux utilisateurs réguliers. Un tel que je l'ai utilisé est de brouiller réellement l'URL de connexion pour l'accès admin et admin envoyer la nouvelle URL. Arrête toute attaque de force brute tout de suite que votre nouvelle URL peut être arbitrairement difficile (très longue chaîne aléatoire), mais seul inconvénient de votre utilisateur admin suit un lien dans leur e-mail. L'attaquant ne sait plus où même POST à.

Créé 18/07/2015 à 01:18
source utilisateur

voix
12

Je Dont't savoir s'il était préférable de répondre à cela comme une réponse ou un commentaire. J'ai opté pour la première option.

En ce qui concerne la Poing PARTIE IV: fonction Mot de passe oublié dans la première réponse, je voudrais faire un point sur les attaques coordonnées .

Dans le souvenir de votre mot de passe des formes, un attaquant pourrait vérifier une liste complète des e - mails et de détecter qui sont enregistrés au système (voir le lien ci - dessous).

En ce qui concerne le formulaire de mot de passe oublié, je voudrais ajouter qu'il est une bonne idée à l'égalité entre les temps des requêtes réussies et unsucessful avec une fonction de retard.

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

Créé 16/08/2015 à 17:31
source utilisateur

voix
10

Je voudrais ajouter un commentaire très importante:

  • « Dans une entreprise, intra- cadre net, » la plupart , sinon la totalité de ce qui précède pourrait ne pas appliquer!

De nombreuses entreprises déploient « usage interne » sites qui sont, effectivement, « les applications d' entreprise » qui se trouvent ont été mises en œuvre par les URL. Ces URL peuvent (soi - disant ...) être uniquement résolus dans « réseau interne de l'entreprise. » (Réseau qui comprend par magie tous connectés VPN « guerriers de la route. »)

Lorsqu'un utilisateur est connecté à docilement-ce réseau, qui leur identité ( « authentification ») est « concluante connue, » [déjà ...] comme leur autorisation ( « autorisation ») pour faire certaines choses ... comme. .. « pour accéder à ce site. »

Ce service « d'authentification + autorisation » peut être fournie par plusieurs technologies différentes, telles que LDAP (Microsoft OpenDirectory) ou Kerberos.

De votre point de vue, vous savez simplement ceci: que tous ceux qui WINDS-up légitimement à votre site Web doit être accompagné par [une variable d'environnement contenant comme par magie ...] un « jeton ». ( À savoir l'absence d'un tel jeton doit être un motif immédiat pour 404 Not Found.)

La valeur du jeton n'a pas de sens pour vous, mais, en cas de besoin, « les moyens appropriés existent » par lequel votre site web peut « [autoritairement] demander à quelqu'un qui sait (LDAP ... etc.) » à propos de tout et de tous les ( !) question que vous pourriez avoir. En d' autres termes, vous ne pas vous prévaloir d' une « logique de chez nous . » Au lieu de cela, vous enquérir auprès de l'autorité et de confiance implicitement son verdict.

Euh hein ... il est tout à fait un interrupteur mental du « Internet sauvage et laineux. »

Créé 29/04/2015 à 01:06
source utilisateur

voix
5

Utilisez OpenID Connect ou accès gérées par les utilisateurs .

Comme rien est plus efficace que de ne pas le faire du tout.

Créé 10/08/2016 à 13:27
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more