dois-je limiter les tentatives de connexion des rails?

Question

Je pense à la construction d'un système de connexion pour Ruby on Rails, un peu comme celui

http://visionmasterdesigns.com/tutorial-create-a-login-system-in-ruby-on-rails/

En termes de sécurité, dois-je limiter les tentatives d'un utilisateur peut se connecter s'ils obtiennent leur nom d'utilisateur faux?

En outre, les étapes de base de connexions semblent être:

• authentification nom d'utilisateur et mot de passe contre ceux dans la base
• si authentique nom d'utilisateur et mot de passe, créer une variable de session
• avant filtre de sorte que les pages exiger la connexion sont protégés.

Y a-t-il autre chose que je devrais considérer?

Answer 1

Le fait de limiter le nombre de tentatives de connexion par adresse IP (et non par session) augmente la sécurité. Savez-vous qu'il existe déjà plusieurs systèmes d'authentification avec Rails?

Il n'y a pas besoin de réinventer la roue.
Voici une liste non exhaustive.

• Clearance
• AuthLogic
• Restful Authentication

Si vous ne souhaitez pas utiliser tout, vous pouvez prendre exemple sur ce qu'ils font.

Modifier 2013
Les bibliothèques fournies ci-dessus ne sont pas à jour plus, et je ne pouvais pas recommand les utiliser dans une nouvelle application. Jetez un oeil à devise.

Answer 2

Une autre considération devrait être l'attaque par déni de service. Limiter le nombre de requêtes aux pages dynamiques à un taux raisonnable devrait rendre plus difficile pour qu'un utilisateur malveillant puisse supprimer votre site. Tout en contribuant à la résolution des problèmes de mot de passe, cela empêchera également les utilisateurs de manipuler les données du site de manière non intentionnelle, ce qui pourrait représenter un risque pour la sécurité (peut-être à cause de la corruption des données).

Si vous décidez d'utiliser cette approche, vous devriez essayer de trouver un module bien supporté pour vous aider (au lieu de rouler le vôtre).

Answer 3

Une autre façon de le faire est avec rack. Vous pouvez suivre le nombre de fois qu'une IP visite la page de connexion pendant un certain temps stockant les tentatives de connexion sur la base de données, memcached, redis, tokyo cabinet, etc. Puis refuser à l'utilisateur l'accès à la page s'ils ont dépassé un ensemble quota pour un intervalle de temps défini.

Damien a suggéré Authlogic. Authlogic est mon système d'authentification préféré pour Rails. C'est très complet et adaptable. Il y a beaucoup de modules existants pour Authlogic, et je suis sûr que vous pourriez en tirer parti pour qu'Authlogic fonctionne pour vous.

Answer 4

D'abord, limiter la vitesse de la page de connexion par IP.Utilisez un invisible captcha system sur la page de connexion. Vous devez ensuite définir des limites de connexion par adresse IP, mais vous devez également définir des limites de connexion par utilisateur en dernier recours pour empêcher les botnets de forcer la brutalité à partir de plusieurs adresses IP. Envoyer un e-mail à l'utilisateur si une tentative de force brute leur mot de passe est détectée. N'envoyez pas d'hordes d'e-mails répétés si quelqu'un essaie d'un tas d'adresses IP différentes. Dans le cas contraire, un botnet pourrait faire du spamming, et pire, un message important finirait dans le dossier spam. Assurez-vous de mentionner qu'ils pourraient vouloir changer leur mot de passe, et/ou améliorer sa force.

Si vous définissez des limites de connexion IP, augmentez les limites. Beaucoup d'endroits utilisent trois grèves et vous êtes absent. C'est fou et user-hostile. Il devrait être au moins dix ou plus réaliste, et quand vous le frappez, vous devriez obtenir une interdiction basée sur le temps plutôt que d'une interdiction de "Call Customer Support". Personne ne va forcer un mot de passe en dix tentatives. Je recommande donc une limite de connexion par IP de 10 et une limite de connexion par utilisateur comprise entre 1 000 et 10 000 (assez élevée pour contrecarrer les attaques par déni de service, mais suffisamment faible pour qu'un botnet ait probablement déjà piraté le mot de passe) . Vous devriez avoir une certaine forme d'alerte sur le pagette sysadmin/on-call qu'il y a un botnet au travail qui se déclenche bien avant que vous n'atteigniez ce seuil. (Notez le nombre de tentatives d'ouverture de session échouées pour tous les utilisateurs et utilisateurs individuels, faites une moyenne mobile et alertez si l'un des seuils franchit l'un des seuils.) N'oubliez pas que si une personne possède une liste d'utilisateurs suffisamment importante, base d'utilisateurs est à peu près la même que la probabilité de réussir en attaquant un seul compte.)

Bloquez les attaquants évidents sur le pare-feu. Expirer les interdictions après un certain temps. Assurez-vous de faire en sorte que le soutien à la clientèle puisse libérer quelqu'un, mais assurez-vous que l'interdiction est en quelque sorte liée à l'infraction. Vous ne devriez pas désarmer quelqu'un qui a tenté de casser vingt connexions d'utilisateur différentes ou quelque chose. Jugement ici bien sûr, parce que les script kiddies avec les membres de la famille et les grand-mères qui n'ont pas été en faute qui ont été pris en charge par les botnets peuvent certainement réussir à se faire interdire la propriété intellectuelle.

Si vous avez réellement le temps de faire tout cela, vous aurez un formulaire de connexion de premier ordre. Je doute que tu aies besoin de ça.