J'écris un système d'authentification complet pour une application et je prévois de la journalisation des tentatives d'authentification échouées afin de mettre en œuvre une meilleure sécurité. J'aimerais vérifier les mots de passe échoués pour les attaques de force brute et de dictionnaires, mais la seule méthode que je pouvais penser à ce que cela se consiste en stockant le mot de passe brut.
J'ai des sentiments mitigés sur le faire. Bien que je sache que les tentatives de connexion échouées seront effacées de temps en temps, je n'aime pas l'idée des mots de passe bruts stockés dans une base de données. Je sais que j'ai mal des mots de passe très souvent, très similaires à mon mot de passe réel, ou pire encore, je vais taper un mot de passe incorrect pour un identifiant particulier qui est en fait un mot de passe actif pour un autre site Web.
Il serait toutefois impossible de mettre en œuvre une sécurité avancée sans stocker certains mots de passe bruts, alors j'essaie de penser à la meilleure façon de le faire.
Voici quelques solutions possibles que j'ai pensées à:
Quelqu'un a-t-il une entrée à ce sujet? Est-ce une bonne / mauvaise idée? Devrais-je utiliser un cryptage à deux voies?
9 Réponses :
Il y a une grande différence entre un utilisateur qui fait des erreurs et une attaque de force brute / dictionnaire: Quelque chose d'autre, et votre «sécurité avancée» commence à ressembler à des «possibilités de vecteur d'attaque avancées».
J'avais l'intention de limiter les tentatives de connexion et de le faire, cependant après avoir lu la réponse, j'ai décidé que je suis tout simplement trop paranoïaque. Merci à tous pour avoir répondu, très apprécié.
Logging Les mots de passe bruts ressemblent à une très mauvaise idée, comme vous l'avez signalé vous-même.
Pourriez-vous simplement enregistrer le nom d'utilisateur et les périodes de connexion en panne, sans enregistrer réellement les mots de passe? Il serait assez évident que s'il y avait une attaque bruteforce s'il y avait des centaines de tentatives de connexion en peu de temps. Vous pouvez également enregistrer l'adresse IP.
Je prévois déjà de limiter le nombre de tentatives de connexion par heure à un nombre indiquant 15 (à déterminer). Je suppose que je suis juste trop paranoïaque.
Je ne sais pas si vous êtes trop paranoïaque. Une attaque d'un dictionnaire peut réussir éventuellement si certains de vos utilisateurs ont des mots de passe faibles et ne les changent pas pendant une longue période. L'attaque pourrait passer inaperçue pendant plusieurs mois, de brulguer tranquillement à travers son dictionnaire. La journalisation autant que vous pouvez est toujours une bonne idée, tout simplement pas les mots de passe bruts, et si vous repérez une activité suspecte, vous pouvez interdire l'adresse IP avant qu'elle ne soit cassée des mots de passe.
Selon le protocole d'authentification, vous sélectionnez, par exemple, dans le cas de Kerberos , vous n'avez peut-être même pas accès au mot de passe saisi.
Je ne suis pas sûr de ce que vous voulez dire lorsque vous mentionnez de stocker des mots de passe bruts - Vous ne voulez probablement stocker que les tentatives de mot de passe échouées dans un texte brut à analyser pour les modèles (attaques de dictionnaires) et le volume (force brute).
Dans mon expérience Limited , vous preniez le mot de passe saisi de l'utilisateur, le hachage (avec un sel, le même sel utilisé pour hacher le mot de passe stocké) et comparer avec la valeur hachée stockée. Si la validation échoue (les valeurs hachées ne sont pas égales), connectez-vous la version texte simple du mot de passe utilisé pour la tentative.
Je conseillerais également de mettre en œuvre le verrouillage d'un compte après un certain nombre de tentatives infructueuses et éventuellement avoir une fenêtre exponentielle de délai d'attente lorsqu'une tentative de connexion peut être essayée à nouveau. Si un utilisateur entre un mot de passe pour commencer correctement, mais passe correctement un mot de passe, vous pouvez envisager de supprimer le mot de passe capturé pour la connexion échouée pour cette session particulière.
Cela semble être trop ingénierie. Je voudrais simplement garder une trace des tentatives de connexion échouées et après la quantité de $ x de tentatives de connexion échouées, vous bloquez ensuite la propriété intellectuelle de tenter une autre connexion pendant 1 à 24 heures environ.
Si vous craignez que quelqu'un ciblait un compte spécifique, vous pouvez noter le nombre de tentatives infructueuses sur un nom d'utilisateur spécifique et ensuite prendre des mesures appropriées, telles que la limitation des connexions infructueuses sur ce nom d'utilisateur à 2 ou 3 par période de 24 heures sur une période IP. Adresse.
Je peux penser à des moyens de détecter les attaques de dictionnaire / brutales via une comparaison, mais vous allez devoir collecter les entrées de l'utilisateur et la comparer aux tentatives précédentes, cela pourrait être un problème de sécurité si vous stockez légèrement mots de passe légitimes mal orthographiés dans une base de données. De plus, cela va prendre un peu de puissance de la CPU pour se désabonner pour chaque connexion.
L'objectif devrait être de le rendre lent intensif pour les attaquants brut-force, mais pas ennuyeux ou compromettant pour les utilisateurs légitimes.
Bien que maintenant que je pense à cela un peu plus, la méthode de prévention pourrait également être un moyen de déni de service en verrouillant des utilisateurs hors de pouvoir se connecter, alors prenez ma suggestion avec cela à l'esprit.
Avez-vous pensé à une quantité définie de login puis un bloc chronométré? Si la connexion échoue 3x / 5x / 10x si vous le souhaitez, verrouillez complètement le compte pendant une période de temps spécifiée.
En faisant cela, vous le rendez si minutieux pour une utilisation brute à utiliser, qu'ils ne seront probablement pas pris mal à essayer. Enregistrement de toutes les tentatives infructueuses, et plus, même même la pensée de mots de passe en texte brut est une mauvaise idée. Utilisez plutôt l'analogie suivante:
Faites de la vie difficile pour les forceurs brute et ils ne se dérangeront pas.
Une autre option est après une quantité définie de connexions en panne, ajoutez un hth,
kyle "Si je fais ma maison si difficile d'entrer dans la maison, ils essaieront les voisins d'abord."
captcha . Encore une fois, si le CAPTCHA est bon, empêche considérablement leurs progrès.
Comme d'autres l'ont dit, les mots de passe de la journalisation sont une mauvaise idée.
Une bien meilleure idée est de tentatives de connexion de papillon .
Si cela est fait correctement, le logement peut réduire considérablement le risque d'attaques de mot de passe ainsi que de limiter le déni des attaques de service.
Vous pouvez stocker des hachages de mots de passe échoués, si vous souhaitez vraiment conserver des informations sur eux. Cela ne vous permettrait pas d'analyser tomantine, mais permettrait de comparer les tentatives infructueuses les unes avec les autres.
Cela dit, je ne pense pas que l'analyse des mots de passe donnerait des informations utiles.
Comme d'autres ont souligné, c'est une mauvaise idée très très de stocker des mots de passe en clairexuant et des tentatives de connexion / limitation de la limitation de la limitation est la bonne façon de partir.
Si vous êtes préoccupé par la sécurité des mots de passe, vous devriez alors Mettre en œuvre des stratégies de mot de passe lorsque des mots de passe sont créés , pas au moment de l'authentification. Vous pouvez ensuite vérifier la mémoire pour les mots de dictionnaire et avoir des stratégies typiques telles que la longueur minimale, doivent contenir un numéro, une lettre majuscule, etc.
Bien entendu, les stratégies de mot de passe peuvent être ennuyeuses pour les utilisateurs, mais elles peuvent théoriquement, améliorer vos préoccupations concernant les mots de passe faibles.
La vérité laid est que les mots de passe sont un moyen médiocre de prouver l'identité, mais les alternatives sont plus chères et lourdes.