Le guide définitif pour former site basé sur l'authentification

Question

Authentification basée sur des formulaires pour les sites web

Nous croyons que le Débordement de la Pile ne doit pas seulement être une ressource pour des cas très particuliers, les questions techniques, mais aussi pour les directives générales sur la façon de résoudre des variations sur des problèmes communs. "Authentification basée sur des formulaires pour les sites web" doit être un excellent sujet pour une telle expérience.

Il devrait inclure des questions telles que:

• Comment ouvrir une session
• Comment rester connecté
• Comment mémoriser des mots de passe
• À l'aide de questions secrètes
• Oublié nom d'utilisateur/mot de passe fonctionnalité
• OpenID
• "Se souvenir de moi" dans la case
• Navigateur autocomplétion des noms d'utilisateur et mots de passe
• Le Secret de l'Url (publique Url protégé par digest)
• Vérification de la force du mot de passe
• E-mail de validation
• et beaucoup plus sur l' authentification basée sur des formulaires ...

Il ne devrait pas inclure des choses comme:

• rôles et d'autorisation
• L'authentification HTTP de base

Merci de nous aider par

1. Ce qui suggère des sous-rubriques
2. La soumission de bons articles sur ce sujet
3. L'édition de la réponse officielle

Answer 1

Définitive De L'Article

L'envoi d'informations d'identification

Le seul moyen pratique d'envoyer des informations d'identification à 100% en toute sécurité en utilisant le protocole SSL. L'utilisation de JavaScript pour hacher le mot de passe n'est pas sûr. (TODO citation nécessaire). Il y a une autre méthode appelée SRP, mais il est breveté (même s'il est sous licence libre) et il y a quelques bonnes implémentations disponibles.

Stockage des mots de passe

Ne jamais stocker les mots de passe en clair dans la base de données. Non, même si vous ne se soucient pas de la sécurité de votre propre site. Supposer que certains de vos utilisateurs de réutiliser le mot de passe de leur compte bancaire en ligne. Donc, stocker le mot de passe haché, et de le jeter loin de l'original. Et assurez-vous que le mot de passe ne s'affiche pas dans les journaux d'accès ou des journaux d'applications. La meilleure fonction de hachage semble être bcrypt.

Hachages par eux-mêmes sont également sécurisés. Par exemple, des mots de passe identiques identiques, les hachages--ce fait hash tables de recherche un moyen efficace de fissuration de beaucoup de mots de passe à la fois. Au lieu de cela, stocker le salé de hachage. Un sel est une chaîne ajoutée au mot de passe avant de hachage - utiliser un autre (aléatoire) de sel par l'utilisateur. Le sel est une valeur publique, de sorte que vous pouvez les stocker avec le hash dans la base de données. Voir ici pour en savoir plus sur cette.

Cela signifie que vous ne pouvez pas envoyer à l'utilisateur le mot de passe oublié (parce que vous avez seulement le hash). Ne pas réinitialiser le mot de passe utilisateur, sauf si l'authentification de l'utilisateur (les utilisateurs doivent prouver qu'ils connaissent la réponse à la question de sécurité, ou sont en mesure de lire les e-mails envoyés à l'stocké (et validé) adresse e-mail.)

Les questions de sécurité

Les questions de sécurité sont précaires - éviter de les utiliser. Pourquoi? Lire PARTIE III: à l'Aide de Questions Secrètes dans @Jens Roland réponse 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 identifiant du cookie, mais personne d'autre ne peut générer un tel cookie (TODO expliquer les mécanismes). Les Cookies peuvent être détournés (TODO vraiment? comment?), donc ne pas envoyer les cookies persistants. Si vous voulez autologin vos utilisateurs, vous pouvez définir un cookie persistant, mais vous devez définir un indicateur que l'utilisateur est automatiquement connecté à la, et les besoins de connexion pour de vrai pour les opérations sensibles (TODO est-ce correct? Je pense que c'est ce qu'Amazon n'.)

Liste de ressources externes

• Dos et Ne pas faire de l'Authentification du Client sur le Web (PDF)
  21 page article académique avec beaucoup de grands conseils.
• Demandez YC: les Meilleures Pratiques pour l'Authentification de l'Utilisateur
  Forum de discussion sur le sujet
• Vous êtes Probablement Stocker les mots de passe de manière Incorrecte
  Article d'introduction sur le stockage des mots de passe
• Discussion: le Codage d'Horreur: Vous êtes Probablement Stocker les mots de passe de manière Incorrecte
  Forum de discussion sur le code de l'Horreur de l'article.
• Ne jamais stocker les mots de passe dans une base de données!
  Un autre avertissement sur le stockage des mots de passe dans la base de données.
• Craquage de mot de passe
  Article de wikipédia sur les faiblesses de plusieurs hachage de mot de passe régimes.
• Assez Avec Les Tables Arc-En-Ciel: Ce Que Vous Devez Savoir Sur Les Régimes De Mot De Passe Sécurisé
  Discussion sur les tables arc-en-ciel et comment se défendre contre eux, et contre les autres threads. Comprend un vaste débat.

Answer 2

D'abord, une mise en garde que cette réponse n'est pas la meilleure solution pour cette question exacte. Il ne doit certainement pas être la réponse sommet!

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

Je vais résumer de cette façon:

1. Mozilla est une organisation sans but lucratif avec des valeurs qui correspondent bien à trouver de bonnes solutions à ce problème.
2. La réalité aujourd'hui est que la plupart des sites web en fonction du formulaire d'authentification
3. En fonction du formulaire d'authentification a un gros inconvénient, qui est l'augmentation du risque de phishing. Les utilisateurs sont invités à entrer des informations sensibles dans une zone contrôlée par une télécommande entité, plutôt que d'une zone contrôlée par leur Agent Utilisateur (navigateur).
4. Depuis que les navigateurs sont implicitement confiance (l'idée d'un Agent Utilisateur est d'agir au nom de l'Utilisateur), ils peuvent aider à améliorer cette situation.
5. La principale force freinent le progrès est ici déploiement de blocage. Des Solutions doivent être décomposé en étapes qui fournissent certains avantages supplémentaires sur leur propre.
6. Le plus simple décentralisée méthode pour l'expression de l'identité qui se construit dans l'infrastructure internet est le nom de domaine.
7. Le deuxième niveau d'expression de l'identité, chaque domaine gère son propre ensemble de comptes.
8. Le formulaire "compte@de domaine" est concis et soutenu par un large éventail de protocoles et des modèles d'URI. Une telle identification est, bien sûr, le plus universellement reconnu comme une adresse e-mail.
9. Fournisseurs de services de messagerie sont déjà de facto de la primaire fournisseurs d'identité en ligne. Courant de réinitialisation de mot de passe des flux de habituellement vous permettent de prendre le contrôle d'un compte si vous pouvez prouver que vous avez le contrôle de ce compte est associé adresse e-mail.
10. L'e-Mail Vérifiés Protocole a été proposé de fournir une méthode sécurisée, basée sur la cryptographie à clé publique, de la rationalisation du processus de prouver au domaine B que vous avez un compte sur le domaine A.
11. Pour les navigateurs qui ne supportent pas Vérifiées, le Protocole de Messagerie (actuellement, tous d'entre eux), Mozilla propose une cale qui implémente le protocole dans un code JavaScript côté client.
12. Pour les services de messagerie qui ne prennent pas en charge l'e-Mail Vérifiés Protocole, le protocole permet à des tiers d'agir comme un intermédiaire de confiance, affirmant qu'ils ont vérifié un utilisateur titulaire d'un compte. Il n'est pas souhaitable d'avoir un grand nombre de ces tiers; cette capacité est destiné uniquement à permettre à un chemin de mise à niveau, et il est préférable que les services de messagerie offrent ces affirmations elles-mêmes.
13. Mozilla propose leur propre service à agir de la sorte un tiers de confiance. Les Fournisseurs de services (qui est, en s'Appuyant Parties) la mise en œuvre de l'e-Mail Vérifiés Protocole peut choisir de faire confiance à Mozilla affirmations ou pas. Mozilla service vérifie le compte de l'utilisateur à la propriété en utilisant les moyens conventionnels de l'envoi d'un email avec un lien de confirmation.
14. Les Fournisseurs de services peuvent, bien sûr, offrir ce protocole comme une option en plus de toute autre méthode(s) d'authentification qu'ils voudraient offrir.
15. Une grande interface utilisateur avantage recherché ici est le "sélecteur d'identité". Lorsqu'un utilisateur visite un site et choisit de s'authentifier, de leur navigateur affiche une sélection d'adresses e-mail ("personnel", "travail", "activisme politique", etc.) ils peuvent l'utiliser pour s'identifier sur le site.
16. Un autre grand de l'interface utilisateur de bénéficier 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 connecté en tant qu'actuellement, principalement, de sorte qu'il peut afficher que dans le navigateur chrome.
17. En raison de la nature distribuée de ce système, il évite le blocage des principaux sites comme Facebook, Twitter, Google, etc. Tout individu peut posséder leur propre nom de domaine et donc agir comme leur propre fournisseur d'identité.

Ce n'est pas strictement "en fonction du formulaire d'authentification pour les sites web". Mais c'est un effort pour la transition de la norme actuelle du formulaire d'authentification basée à quelque chose de plus sûr: le navigateur d'authentification pris en charge.

Answer 3

J'ai juste pensé que je devais partager cette solution que j'ai trouvé fonctionne très bien.

Je l'appelle le Mannequin Champ (bien que je n'ai pas inventé ce afin de ne pas les crédit-moi).

En bref: vous avez juste à insérer dans votre <form> et vérifiez qu'il soit vide au moment de la validation:

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

L'astuce est de tromper un bot en pensant que c'est pour insérer des données dans un champ obligatoire, c'est pourquoi j'ai nommé l'entrée "e-mail". Si vous avez déjà un champ appelé e-mail que vous utilisez, vous devriez essayer de nommage le mannequin champ de quelque chose d'autre comme la "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 sonne comme quelque chose que les gens seraient normalement trouver logique à remplir dans un formulaire web. Maintenant masquer l' input champ à l'aide de CSS ou de JavaScript/jQuery - ce que vous convient le mieux - juste ne pas mettre input type de hidden , sinon le bot ne pas tomber pour elle.

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

Exemple:

Dans le cas d'un homme: L'utilisateur ne verra pas le mannequin de champ (dans mon cas appelé "e-mail") et de ne pas tenter de le remplir. Ainsi, la valeur de la tétine champ doit toujours être vide lorsque le formulaire a été envoyé.

Dans le cas d'un bot: Le bot va voir un champ dont le type est - text nom email (ou quoi que ce soit vous l'avez appelé) et seront logiquement tenter de le remplir avec des données appropriées. Il ne se soucie pas si vous le style le formulaire de saisie avec un peu de fantaisie CSS, web-développeurs le font tout le temps. Quelle que soit la valeur de la tétine, le terrain est, on s'en fout, tant que c'est plus grand que 0 caractères.

J'ai utilisé cette méthode sur un livre d'or en combinaison avec le CAPTCHA, et je n'ai pas vu un seul spam post depuis. J'avais utilisé un CAPTCHA seule solution avant, mais finalement, il a permis à environ cinq messages de spam à chaque heure. Ajouter le mannequin champ du formulaire est arrêté (au moins jusqu'à maintenant), tous les spam d'apparaître.

Je crois que cela peut aussi être utilisé très bien avec un login/formulaire d'authentification.

Avertissement: bien sûr, cette méthode n'est pas 100% infaillible. Les robots peuvent être programmés pour ignorer les champs de saisie avec le style display:none lui est appliquée. Vous avez aussi penser aux personnes qui utilisent une certaine forme de l'auto-complétion (comme la plupart des navigateurs ont intégré!) pour remplir automatiquement tous les champs du formulaire pour eux. Ils pourraient tout aussi bien choisir un mannequin de champ.

Vous pouvez également varier un peu en laissant le mannequin domaine visible, mais à l'extérieur des limites de l'écran, mais c'est totalement à vous.

Être créatif!

Answer 4

Je ne pense pas que la réponse ci-dessus est "mal" mais il existe de grandes zones d'authentification qui ne sont pas abordés (ou plutôt l'accent est mis sur la façon de mettre en œuvre les cookies de session", pas sur "quelles sont les options disponibles et quels sont les compromis".

Ma suggéré des modifications / réponses sont

• Le problème réside davantage 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 le plus intelligent des moyens de cryptage de mot de passe

• N'essayez PAS de mettre en place votre propre formulaire de connexion ou de stockage de base de données de mots de passe, à moins que les données stockées est sans valeur, à la création de compte et d'auto-généré (qui est, style web 2.0 comme Facebook, Flickr, etc.)

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

Cela permet d'éviter d'avoir des "sessions" ou cookies dans le navigateur lui-même re-chiffrer la communication à chaque fois. Il est le plus "léger" de l'approche du développement.

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

Alors ...

Tout d'abord, nous sommes à confusion lors de la création du compte (avec un mot de passe) avec le re-vérification du mot de passe par la suite. Si je suis Flickr et de la création de votre site pour la première fois, le nouvel utilisateur a accès à la valeur zéro (vide de l'espace web). J'ai vraiment ne se soucient pas si la personne qui crée le compte est couché sur leur nom. Si je suis la création d'un compte de l'hôpital de l'intranet / extranet, la valeur se trouve dans tous les dossiers médicaux, et donc je fais des soins sur l'identité (*) du créateur du compte.

C'est très très dur. La seule solution convenable est un site web de confiance. Par exemple, vous vous joignez à l'hôpital en tant que médecin. Vous créez une page web hébergée quelque part, avec votre photo, votre numéro de passeport et d'une clé publique, et de hachage avec la clé privée. Vous visiterez ensuite l'hôpital et à l'administrateur système regarde votre passeport, voit si la photo correspond à vous, et puis les hachages de la page web / photo de hachage avec l'hôpital de la clé privée. À partir de maintenant nous pouvons en toute sécurité l'échange des clés et des jetons. Comme toute personne qui se fie à l'hôpital (il est le secret de la sauce BTW). L'administrateur système peut également vous donner un RSA dongle ou d'autres authentification à deux facteurs.

Mais c'est un lot de tracas, et pas très web 2.0. Cependant, c'est le seul moyen sûr de créer de nouveaux comptes qui ont accès à de précieuses informations qui n'est pas auto-créé.

1. Kerberos et SPNEGO - authentification unique sur les mécanismes avec un tiers de confiance - fondamentalement, l'utilisateur vérifie à l'encontre d'un tiers de confiance. (NB: ce n'est pas en aucune façon à ne pas être digne de confiance OAuth)

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

3. SSL côté client - donner aux clients un certificat de clé publique (soutien dans tous les principaux navigateurs - mais soulève des questions sur la machine cliente de sécurité).

En fin de compte, il est nécessaire de trouver un compromis - quel est le coût d'une violation de la sécurité vs le coût de la mise en œuvre de sécuriser davantage les approches. Un jour, on peut y voir un bon PKI largement accepté et donc plus propre roulé des formulaires d'authentification et de bases de données. Un jour...