Je viens de lire une analyse à propos de mots de passe réels. On y trouve confirmation à grande échelle de ce que chaque utilisation de Jack The Ripper montre: la plupart des mots de passe, c'est du basique.
http://www.troyhunt.com/2011/07/science-of-password-selection.html
Beaucoup dissertent au sujet des mots de passe super solides. Alors que je trouve, c'est un point de vue personnel, qu'un mot de passe relativement simple suffit. A partir du moment où il n'est pas possible de faire des millions de tentatives.
L'exemple courant est la carte bancaire. Il n'y a que 10.000 combinaisons, ce qui est très peu. Mais elle se verrouille à la 3ème erreur de suite. Soit une chance sur 3333 de passer au pif, ce qui est bien pour une combinaison aussi simple.
Avec un mot de passe libre, l'expérience montre que très peu de combinaisons sont utilisées par la plupart des gens. Peut-être 100.000 combinaisons à tout casser. Dont 10.000 courantes.
Avec un système de verrouillage au bout de 3 tentatives, cela semble bien assez la plupart du temps. En entreprise, qui va tenter de casser le code du patron pour le logiciel de comptabilité ? Sur le grand ternet, qui va tenter de trouver votre code de webmail ?
Malheureusement le problème n'est pas de protéger UN compte, mais des millions.
Le code de compta du patron est protégé de manière suffisante. Ok. Enfin admettons, car je ne connais pas de logiciel de compta qui limite les tentatives.
Le code webmail de Monsieur Machin est également protégé de manière suffisante. Toujours en admettant que le webmail en question limite les tentatives. Pas gagné.
Mais dans ces deux cas, c'est protégé uniquement contre une attaque ciblée. L'attaquant veux le code d'une personne bien définie.
Lorsque l'attaquant veut simplement un code d'accès, n'importe lequel, alors il a une surface d'attaque bien plus importante.
Ca ne fonctionne que pour les services de grande envergure. Si c'est le webmail du magasin de déco du coin, ça devrait aller. Si c'est celui du conseil général d'un gros département, c'est peut-être autre chose. Et si c'est eBay ou Gmail, il y a vraiment une surface bien plus grande.
Mon constat personnel: "éduquer" l'utilisateur ne fonctionne qu'avec de rares personnes
Tout comme les sauvegardes ne sont jamais faites, les mots de passe sont pourris, point.
C'est un fait qu'il faut accepter et dont il faut tenir compte.
Quelles sont les méthodes pour améliorer la situation ?
Tout d'abord, il est impératif de limiter les tentatives. L'inconvénient est que ça permet de bloquer le compte. Dans un environnement d'entreprise ça passe car il n'y a presque jamais de tentatives. Mais pour un service ouverts à tous c'est une autre histoire.
Je ne connais pas de solution miracle pour ce dernier point. Il y a des astuces comme par exemple envoyer un email indiquant que le compte a été "verrouillé". Pour le déverrouiller il faut entrer le mot de passe habituel, suivi du mot de passe indiqué dans l'email. Si l'attaquant peu lire l'email, c'est que les carottes sont cuites depuis longtemps.
Ensuite je pense qu'envoyer automatiquement un email d'avertissement en cas de tentative est une bonne chose. Monsieur Machin, il y a eu une tentative de connexion à votre compte truc. Suivi d'un éventuel message informatif (complexité, phising, etc) qui ne sera lu que par 1% des destinataires.
Je crois que c'est une très bonne solution. Ca permet d'adapter le mot de passe à la situation. Si le mec reçoit un avertissement par an, c'est que le danger est faible. S'il en a 10 par jour, bon, il va peut-être réfléchir à sa protection.
Et enfin ma méthode "pédagogique" perso: une fois par mois je fais un tour dans la base de données de notre ERP. Les mots de passe sont stockés en clair. Ne riez pas, ce n'est pas du tout amusant. D'autant plus que la base de données est accessible à toute personne un peu au courant. Bon bref.
Une fois par mois donc, je regarde les mots de passe faibles. Et je fais un email comme s'il venait d'un robot pour prévenir la personne que son mot de passe a été trouvé automatiquement. Je lui donne le premier et le dernier caractère du mot de passe.
La plupart du temps ça les dessoule.
Il faudrait peut-être faire la même chose avec John The Ripper sur les comptes Windows et Unix.
Quelles sont les méthodes pour trouver les mots de passe ?
- extorsion (ciblé)
- lire le post-it (ciblé)
- tout le monde connaît déjà le code (ciblé, très courant)
- phishing (de masse)
Pour ces méthodes, et dans le cadre de mots de passe pour des choses "ordinaires", il n'y a pas vraiment de parade.
La sécurité vraiment basse des mots de passe n'est peut-être pas la racine du problème.
# Temporiser le temps entre 2 essais ?
Posté par nemrod . Évalué à 10.
On peut aussi ne pas verrouiller forcément le compte au bout de 3 essais, mais temporiser le temps entre 2 essais possibles en fonction du nombre d'essais ratés depuis le dernier login réussi.
Ainsi les attaques par "forces" brutes sont "ralenties" : Plus on essaye de mauvais mots de passe plus il faut attendre pour le prochain essai.
Je ne sais pas si je suis très clair....
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Olivier Esver (site web personnel) . Évalué à 6.
Comme avec fail2ban par exemple.
Je trouve que c'est un bon complément pour les accès ssh, htaccess et autres, ça ralentit grandement les attaques.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Kerro . Évalué à 4.
Yep, j'aime bien fail2ban. Les miens ont une temporisation de 24h après 3 essais ratés. Déverrouillage avec du port knocking. Clairement, ce n'est pas exploitable pour les services courants.
L'avantage de la temporisation est d'éviter le recours à un administrateur pour déverrouiller.
Dans les astuces que j'aime bien, il y a le fait qu'au bout de 3 tentatives le compte est verrouillé mais sans que ce soit apparent. Donc les tentatives peuvent continuer sans alerter celui qui veut casser le code.
Inconvénient: ça ne fonctionne que si on ne sait pas que c'est en place. Pour du libre c'est raté.
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par mickabouille . Évalué à 2.
Y compris pour l'utilisateur réel qui essaie de se connecter ? (Juste pour préciser, je connais pas l'outil).
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par mickabouille . Évalué à 3.
J'ai ma réponse, c'est basé sur l'IP, faut juste pas que l'utilisateur réel et l'attaquant soient sur la même IP.
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Guillaume Rossignol . Évalué à 1.
Et puis l'utilisateur lorsqu'il est bloqué après dix essais, normalement, il appel le SI, alors que le bot...
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par zebra3 . Évalué à 10.
« allo le service informatique ? Bonjour, c'est pour pirater un compte… »
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par DLFP est mort . Évalué à 4.
C'est ce que font pas mal d'outils nativement (je sais pas si c'est PAM ou SSH ou les deux ou autre chose) mais quand je me trompe de mot de passe il y a souvent une pause obligatoire d'une ou deux secondes. C'est simple et extrêmement efficace contre les attaques par force brute qui tablent plutôt sur des milliers de tentatives par seconde.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par palm123 (site web personnel) . Évalué à 5.
exemple sous OpenVMS
http://h71000.www7.hp.com/doc/73final/6346/6346pro_017.html
voir les tables 7-6 et 7-7
Il peut être pratique de modifier ces paramètres pour la nuit/le week-end, afin d'être plus sévère.
ウィズコロナ
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par ZeroHeure . Évalué à 9.
On peut aussi, contre toutes les attaques à distance, changer les ports par défaut et ne pas utiliser de login correspondant à un prénom ou un mot du dictionnaire, mais plutôt un surnom, un anagramme ou je forge un nom amusant. Ça bloque la plupart des robots et des utilisateurs de dictionnaires.
Méthode très très efficace si j'en crois mes logs.
Il y a quelques années, j'ai pu en vérifier également l'efficacité sur une attaque "sociale". L'attaquant faisait une démonstration de vulnérabilité, incapable de trouver le login d'une personne précise, il n'a pu deviner ni lui extorquer son mot de passe.
Attention, ça ne remplace pas fail2ban, un firewall et d'autres outils! Mais c'est tellement simple, rapide et facile à mettre en oeuvre...
NB: j'ajoute parfois un compte "pot de miel" avec un login facile à trouver. Personne n'étant censé l'utiliser, toute tentative d'entrer sur ce compte est une attaque.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par DLFP est mort . Évalué à 4.
Ou pas. J'ai déjà vu un serveur se faire hacker de façon automatisée (phpmyadmin pas à jour) et le mec se pensait en sécurité parce qu'il était sur le port 81.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par zebra3 . Évalué à 7.
C'est surtout très con. Tu as beau lancer des services Apache sur des ports différents, un coup de nmap -sV te les liste avec leurs versions (et ça marche avec d'autres services, bien sûr).
En plus, les seuls types qui utilisent le 81 sont justement ceux qui ne veulent pas laisser leur Apache sur le 80 (et c'est pareil pour le 8181).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Alex . Évalué à 9.
Ça bloque surtout ceux (je soupçonne des bots ou des pré-pubères) qui lancent des attaques de manière automatique. Mets n'importe quoi sur le port 80 tu vas voir de GET arriver de partout, met n'importe quoi sur le port 22, et t'as des tentatives de connections à la pelle.
Donc oui ce n'est pas une mesure de sécurité, un véritable attaquant ne sera même pas ralenti par ça, c'est juste une mesure sanitaire pour tes logs ;)
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par ZeroHeure . Évalué à 3.
Tout à fait. C'est une mesure utile pour la charge système aussi, ça évite de devoir bloquer des attaques de robots idiots :-)
Comme je l'ai dit, ça n'empêche pas d'avoir un firewal, un fail2ban ,etc.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Kerro . Évalué à 3.
Je confirme que changer de port écrème beaucoup.
Mes ssh ne sont jamais sur le port 22. En fait je mets un ssh bidon sur le port 22 avec un fail2ban réglé à une tentative. Je fais cela depuis 4 ans je crois. Depuis je n'ai pas le souvenir d'avoir vu une seule tentative de connexion sur le "vrai" port ssh.
Donc ça écrème bien.
C'est plus délicat pour un service accessible à tous. Le ssh bricolé ne pose pas de problème aux admins, mais lorsqu'il s'agit d'indiquer aux utilisateurs de se connecter sur le webmail en port trucmuche, pas pareil. Ca limite les robots qui tapent à l'aveugle, mais ça emmerde les utilisateurs légitimes, et le service d'assistance téléphonique :-)
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Adrien . Évalué à 5.
perso j'utilise SSH sur le port 22… mais sans mot de passe, uniquement avec des passphrases. Pas de problème d'attaques pour le moment, sans fail2ban.
J'ai pas poussé le vice à restreindre les adresses IP…
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par Kerro . Évalué à 3.
Tu veux dire avec des certificats ?
Le pépin avec les solutions non protégées est qu'en cas de faille, ça passe. D'autant plus si on est sur le port habituel (mais cet argument ne tient que pour de rares cas, dont ssh. Inutile avec un site web).
Par exemple en cas de générateur de certificat pourri :-)
Ou en cas de faille plus classique.
Un fail2ban ou autre permet de réduire les problèmes. Si la faille n'est pas exploitable en un coup, comme dans l'exemple des certificats moisi de chez Debian. Même avec ces certificats faciles à trouver, fail2ban protège très bien et laisse largement le temps de rustiner.
Si la faille est exploitable en un coup, bon, aucune parade c'est clair.
[^] # Re: Temporiser le temps entre 2 essais ?
Posté par gUI (Mastodon) . Évalué à 3.
Oui, c'est ce que faisais mon autoradio précédent !
A chaque tentative il rallonge le temps entre chaque essai. Première tentative, tu te trompes, tu peux réessayer de suite. Si tu te retrompes, tu dois attendre 10s, puis 20s pour la suivante et ainsi de suite.
Ca dissuade sacrément l'attaque par force brute.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Jack the ripper
Posté par Xaapyks . Évalué à 10.
J'en connais un qui a abusé du Jack...
[^] # Re: Jack the ripper
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 8.
Daniel peut-être?
[^] # Re: Jack the ripper
Posté par toof . Évalué à -1.
non Lang !
[^] # Re: Jack the ripper
Posté par Juke (site web personnel) . Évalué à -1.
Pour brute forcer les petits marocains ?
[^] # Re: Jack the ripper
Posté par Charles-Victor DUCOLLET . Évalué à 0.
C'était une erreur ...
# GPU
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Voici un article sur le cassage de code pour les fichiers d'archives
http://www.presence-pc.com/tests/password-recovery-gpu-23381/
C'est instructif. ( http://www.presence-pc.com/tests/password-recovery-gpu-23381/4/ )
"La première sécurité est la liberté"
# DoS
Posté par suJeSelS . Évalué à 10.
ça va faire mal au DoS. Imaginez un script qui va volontairement verrouiller des millions de comptes en quelques instants x)
[^] # Re: DoS
Posté par Katyucha (site web personnel) . Évalué à 6.
C'est exactement ce que j'ai pensé.
Ce genre de script existe sous forme de virus pour fermer tout les comptes admin d'un AD windows. Je l'ai déjà vu en action, ca fait très mal !
Alors j'imagine pas sur un service webmail complet tel que yahoo ou gmail. Nos adresses mails trainent déjà assez souvent dans les listes des spammeurs. L'anti spam nous sauve (ou presque).
Donc faire un script qui verrouille tout les comptes, ca risque d'être très facile... un nouvel enfer serait né
# Mot de passe dur.
Posté par 2PetitsVerres . Évalué à 10.
Quand on m'a demandé de choisir un mot de passe dur, j'ai choisi "diamant". Y a pas plus dur à casser.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mot de passe dur.
Posté par windu.2b . Évalué à 9.
Et l'adamantium, alors ?!?
[^] # Re: Mot de passe dur.
Posté par JGO . Évalué à 6.
Et quand on me demande un nombre aléatoire, je choisis toujours 4.
http://www.xkcd.org/221/
[^] # Re: Mot de passe dur.
Posté par phxonx . Évalué à 10.
Ca me rappelle la personne à qui on avait dit (en anglais) qu'un mot de passe fort devait comporter
"at least 8 characters and a capital"
La personne avait donc choisi :
MickeyMinnieDonaldDaisyPicsouRiriFifiLoulouWashington
C'est un mot de passe fort.
[^] # Re: Mot de passe dur.
Posté par Lebas Sébastien . Évalué à 3.
Raté.
Un diamant n'est pas très dur à casser, par rapport à d'autres matériaux (Diamond sur le wikipedia anglais, dernier paragraphe de la section "Hardness"). C'est pas parce que le français est ambigu sur le mot "Dur" qu'il faut confondre ...
[^] # Re: Mot de passe dur.
Posté par JGO . Évalué à 6.
Le diamant a une grande dureté mais une faible résilience (physique) et une ténacité relativement faible.
Sinon pour lever l'abigüité on peut dire « difficile à casser ».
# Mouais ...
Posté par Sébastien B. . Évalué à 3.
C'est bien beau, mais bon, imaginons, tous les services demandant un mot de passe se bloquent à la troisième tentative, soit, Mme Uhcim (marque non déposée ?) avec "rex", le prénom de son chien comme mot de passe, elle est relativement en sécurité. Maintenant, le jour où un seul de ces services est compromis et que la base de donnée des mots de passe fuite, bruteforcer les mots de passe (oui, on va considérer qu'ils ne sont pas stockés en clair) sera un jeu d'enfant ! Et à partir de là, le coup des trois tentatives ne te sera d'aucune utilité sur tous les autres services (oui, l'utilisateur qui a un mot de passe faible, bien souvent c'est parce que c'est plus simple à retenir, donc il réutilise ce mot de passe)
Enfin bon, il n'y a pas de solutions miracle, malheureusement.
# Réponse de masse
Posté par kowalsky . Évalué à 8.
Je répond ici au plusieurs personne dans le journal qui préconise (à raison) fail2ban et etc.
Mais les mots de passes forts servent aussi pour les cas ou le méchant a réussit à avoir la base de donnée ou se trouve les hashs des mots de passe.
Dans ce cas la, un mot de passe faible se fait retrouver vite avec des rainbows tables ou alors bêtement du brute force.
Il faut des mots de passe fort dans tout les cas !
ps : Moi je ne mets pas de mot de passe, personne ne pense à le tester et zou, je suis en sécurité !
[^] # Re: Réponse de masse
Posté par DLFP est mort . Évalué à 10.
Mon mot de passe est ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ car le bruteforce se fait souvent de manière alphabétique.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Réponse de masse
Posté par Kerro . Évalué à 6.
Avec la bonne taille de sel, les tables arc-en-ciel ne servent à rien.
Bon c'est vrai que la majorité du parc ont un OS moisi de ce côté. C'est vrai aussi que la majorité des logiciels n'ont pas de sel. Et les autres n'ont souvent un sel que très court.
Oui voilà, c'est juste un détail: on connaît depuis des années une bonne solution contre les attaques brutes, mais presque personne ne l'implémente.
[^] # Re: Réponse de masse
Posté par NanoTech . Évalué à 2.
Même si le sel protège contre les tables arc-en-ciel, ça ne protège pas contre la force brute.
Un mot de passe parmi les 100 000 combinaisons les plus fréquentes se casse toujours en une seconde si on a le haché salé.
[^] # Re: Réponse de masse
Posté par BFG . Évalué à 8.
À point, s'il vous plait.
[^] # Re: Réponse de masse
Posté par pasBill pasGates . Évalué à 5.
C'est peut-etre bon pour la securite, mais c'est pas bon pour la retention d'eau tout ce sel quand meme
[^] # Re: Réponse de masse
Posté par Kerro . Évalué à 2.
C'est vrai qu'il manque une astuce pour que les neuneus puissent avoir un mot de passe d'un seul caractère sans se le faire casser en force brute.
Mais là je crois que c'est par définition impossible.
Les astuces courantes sont:
- nécessiter un gros nombre de cycles processeur pour chaque tentative
- nécessiter le recours à une entité extérieure
- authentification multi-facteurs
Que des choses lourdes. Mais l'entité extérieure est peut-être plus facile à implémenter que je ne l'imagine. Le principe est généralement qu'une partie du sel provienne d'une autre machine. Cela évite qu'une seule machine partiellement compromise ne rende les hashes exploitables.
[^] # Re: Réponse de masse
Posté par j_kerviel . Évalué à 9.
Ça dépend. Si c'est un caractère en UTF-32, ça risque d'être difficile à casser déjà.
[^] # Re: Réponse de masse
Posté par Thomas Douillard . Évalué à 2.
Déja rien qu'à taper ça risque d'être pas évident, alors à casser !
[^] # Re: Réponse de masse
Posté par DLFP est mort . Évalué à 3.
Il y a des caractères facilement accessibles avec la touche Compose, comme ♥, ‽, ☭…
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Réponse de masse
Posté par Thomas Douillard . Évalué à 6.
t'en a probablement pas autant que de caractère en UTF-32 :)
[^] # Re: Réponse de masse
Posté par BFG . Évalué à 1.
Pourquoi donc ? Si le caractère est "a", que l'utilisateur tape "a", que la personne qui tente tout les mots de passe donne "a" à l'interface de login, l'encodage de la base de données de mot de passe ne change strictement rien.
[^] # Re: Réponse de masse
Posté par j_kerviel . Évalué à 3.
Il n' s'agit pas de changer le codage de caractère pour les mêmes lettres, mais d'étendre l'univers des possibilités.
En l’occurrence, pour les mots de passes classiques à un caractère usuels, on passe de quelques dizaines de possibilités à plusieurs milliards.
(Ah et puis ce n'était pas supposé être pris au premier degré).
[^] # Re: Réponse de masse
Posté par BFG . Évalué à 1.
Il n'est donc pas possible d'encoder des caractères exotiques en UTF-8 ?
Soit.
[^] # Re: Réponse de masse
Posté par j_kerviel . Évalué à 2.
Si, mais beaucoup moins.
[^] # Re: Réponse de masse
Posté par Larry Cow . Évalué à 4.
Non, tout autant, mais de manière moins efficace en termes de mémoire.
[^] # Re: Réponse de masse
Posté par j_kerviel . Évalué à 5.
Pour un Japonais probablement, mais certainement pas pour quelqu'un qui n'utilise quasi exclusivement des caractères latins.
# OpenWRT - Fail2Ban - Accès NAS
Posté par sifu . Évalué à 3.
J'ai un routeur WRT54G avec OpenWRT installé dessus. J'ai un daemon ssh qui tourne sur un autre port que le 22 et qui n'accepte que l'authentification par certificat.
J'ai cherché un peu et il ne semble qu'il n'existe pas de package sur OpenWRT pour Fail2ban.
Est-ce que quelqu'un aurait une solution équivalente à proposer ?
Idéalement, j'aimerais mettre en place du "port knocking" pour ouvrir le port uniquement à la demande. Cependant, les règles iptables et moi, ça fait deux ...
Alors si jamais quelqu'un a des conseils, je suis preneur ...
J'ai un NAS chez moi et à terme, j'aimerais bien accéder à son contenu quand j'en ai besoin mais ne pas avoir les ports ouverts en permanence, genre:
- port knocking
- ssh
- wake on line NAS
- ouverture port
- accès FTP par ex.
- fermeture
- extinction NAS
- fermeture
Voilà.
[^] # Re: OpenWRT - Fail2Ban - Accès NAS
Posté par eric gerbier (site web personnel) . Évalué à 2.
fail2ban, c'est "juste" un bout de code python. Si tu peux installer l'interpréteur sur ton routeur, ça a des chances de marcher quand même (à tester).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.