Le vol de votre mot de passe est devenu un enjeu de taille pour les hackers. Ce précieux sésame donne accès à vos données personnelles, bancaires et bien plus encore, il représente donc une véritable mine d’or aux yeux d’un pirate informatique.
Avec un MDP de 6 caractères (de a à z) :
« 3,7 semaines pour un hacking en ligne en passant par une application web (1 000 suppositions par seconde) ; »
Je ne trouve pas ça !
Cela fait 26^6/1000/3600/24
soit : 3.57 jours 
t’as oublié les majuscules 
100 trillions ? Non, billions. Vous avez fait presque la même erreur de traduction que l’autre jour … (article d’ailleurs toujours pas corrigé. Et pas le même auteur : c’est donc une épidémie. Portez des masques :D)
4 « J'aime »
Maj et Min, ça fait 288.82 jours 
Et les chiffres Mais on est pas bon aussi car ça fait 657jours.
Après ca doit être un moyen avec des paternes pré-définie qui permet de tomber juste plus rapidement.
Ça dépend aussi de la fonction de hashage utilisée pour hasher le mot de passe…
Les bonnes pratiques actuelles, c’est d’utiliser des fonctions de hashage comme bcrypt, scrypt ou pbkdf avec plusieurs itérations successives, pour augmenter la durée nécessaire à chaque test.
Par exemple, avec un bcrypt configuré pour 10 « tours » (2^10 itérations), le hash d’un mot de passe sur mon PC prend environ 50ms. Ce qui fait que même hors ligne, un attaquant ne pourra pas tester plus de 20 mots de passer par seconde avec un CPU équivalent.
Bien sûr, ça ralenti le temps de connexion pour l’utilisateur, puisque la vérification du mot de passe saisi prendra aussi 50ms. Mais en pratique 50ms de temps de traitement, c’est invisible pour l’utilisateur.
Par contre ça augmente la charge CPU, surtout sur les services où il y a souvent des connexions par mot de passe (par exemple les banques, qui ne permettent pas de conserver l’authentification plusieurs jours ou semaines via un cookie).
Non, pas nécessairement. L’utilisation d’algorithmes lents, comme je le décris juste au-dessus, est sans impact notable pour l’utilisateur, tout en étant très efficace contre le brute force.
Par exemple, si le serveur met 50 ms à valider un mot de passe, l’exemple le plus rapide de la news, qui tombe en 3.7 semaines sur une attaque à distance, il se met à résister 3 ans…
3 « J'aime »
Oui, il faudrait préciser pour un mdp sur une archive ou tout autre truc accessible en direct (base de mots de passes), j’espère que tous les serveur du monde bloquent au moins temporairement après 3 essais, ce qui est en général admis comme la protection la plus élémentaire (même moi je connais, c’est dire! 
).
1 « J'aime »
Le plus «simple» pour un site web, c’est de limiter les tentatives à 1 fois par seconde, puis incrémenter le temps à chaque erreur. Même un NIP à 4 chiffres va prendre près de 3 heures à 1 essai par seconde. Si on double le délai à chaque mauvaise tentative, après 3 heures, le «pirate» n’en sera qu’à son 14e essai sur les 10 000 combinaisons possible !
3 « J'aime »
Le nombre de combinaisons testées par seconde en local me parait largement surévalué… Une RTX 3080 sur du SHA256, c’est de l’ordre de 100 millions de hash par seconde, donc pour taper du 100 milliards par seconde, c’est pas juste « des serveurs ou des ordinateurs de bureau très puissants », c’est déjà un bon gros cluster de quelques centaines de grosses machines pour avoir l’équivalent d’un millier de RTX 3080…
Quand aux 100 billions de hash par seconde, c’est l’équivalent de 1 million de RTX 3080… C’est pas le premier cluster ou grille de calcul venu…
1 « J'aime »
Aujourd’hui, à part pour des trucs nécessitant vraiment une très forte sécurité (données confidentielles d’entreprise, banques…), c’est plutôt considéré comme une mauvaise pratique de limiter le nombre d’essais ou d’accroître exponentiellement le temps de validation.
Car non seulement ça permet à un attaquant de bloquer facilement un utilisateur légitime, puisqu’il suffit de provoquer quelques échecs et l’utilisateur légitime se retrouvera face à un compte bloqué ou un temps d’attente excessivement long, mais en plus ça n’est d’absolument aucune efficacité en cas de vol de la base de données.
La bonne pratique, c’est vraiment de jouer sur le temps de réponse, soit artificiellement, en ajoutant des petits temps d’attente dans le processus de validation (aucun impact sur la charge CPU du serveur, mais par contre ça ne protège que sur une attaque distante, pas en cas de vol de la base de données), soit en jouant sur la complexité de l’algorithme de hash (impact sur la charge CPU, mais augmente la résistance à un vol de données).
Ainsi une attaque est sans impact sur l’utilisateur légitime.
2 « J'aime »
N’importe quoi … il suffit juste de mettre un ban d’ip ou un blocage de compte pendant 24h avec 5 tentatives et il n’y a plus de problème…ça n’existe plus les sites ou tu peux faire des millions de requêtes pour trouver un mot de passe en force brute…c’est pour ça que les hackers sont à fond dans le phising, il demande carrément le mot de passe a l’utilisateur
Sauf en cas de fuite de données…
Et en faisant ça, tu peux aussi te retrouver à bloquer des utilisateurs légitimes :
- ceux qui partagent la même IP publique que l’attaquant (rappel : tous les réseaux mobiles ou presque sont des réseaux privés, l’ensemble des abonnés accèdent à Internet via une poignée de passerelles et partagent donc la même IP publique),
- le propriétaire du compte attaqué se retrouve bloqué (ce qui du coup peut en fait constituer une forme d’attaque pour empêcher quelqu’un d’utiliser son compte)
Bref, c’est vraiment pas une bonne technique…
Une bonne protection, c’est un algo de hash lent + un peu de contraintes sur la taille/complexité du mot de passe (mais pas trop… les sites qui te demande 12 caractères, venant de 6 groupes différents, c’est contre-productif).
1 « J'aime »
Pour aller jusqu’au bout des possibilités. C’est donc le temps maximum pour trouver (modulo le fait qu’ils surestiment largement la puissance des machines, d’un bon facteur 100…).
Statistiquement, si on considère une pure force brute, sans la moindre « intelligence » pour privilégier des combinaisons plus probables que d’autres, le temps minimum est 0 et le temps moyen est la moitié du temps max.
Voilà. Il suffit que le site ne permette qu’une tentative toutes les trois secondes pour qu’il n’y ait aucune chance de trouver le mot de passe comme ça.
J’insite : il faut que l’algorithme de hash prenne du temps.
Si la temporisation n’est que au niveau du site, ça ne vaut rien en cas de fuite des hash.
Via l’interface de connexion, comme dit plus haut, il suffit de bloquer le compte au bout de quelques essais (même pendant juste quelques minutes) et ça devient impossible à bruteforcer. (On peut juste essayer de le deviner sur quelques essais). Si le site ne bloque pas, c’est de la faute du site.
Si les mots de passes sont enregistrés en clair dans la base de données
- Il faut que le hacker ait accès à la base contenant les mots de passe
Si le hacker y a accès, c’est la faute du site. Et peu importe la complexité du mot de passe, le hacker le verra tout de suite.
Si les mots de passes sont enregistrés chiffrés dans la base de données
- Il faut que le hacker ait accès à la base contenant les mots de passe
- Il faut que le hacker ait accès à la configuration.
Si le hacker y a accès, c’est la faute du site. Et peu importe la complexité du mot de passe, le hacker le verra tout de suite.
Si les mots de passes sont salés puis hashés
- Il faut que le hacker ait accès à la base contenant les hash
- Il faut que le hacker ait accès au code pour savoir comment est salé le hash
- Il faut que le hacker ait accès au sel
Si le hacker a accès à ces données, c’est la faute du site. Et ce n’est qu’à partir de ce moment là que la longueur du mot de passe joue. Et même pas les caractères utilisés : le hacker n’a pas moyen de savoir si le mot de passe est composé de chiffres, de lettres, de majuscules et/ou de symboles. Seule la longueur compte.
Si un mot de passe est facilement devinable (« motdepasse », « azerty », « 123456 », sa date de naissance…), la faute est du côté de l’utilisateur. Dans TOUS les autres cas, la faute est du côté du site.
Tout ça c’est bien bullshit désolé. Vous faites un calcul en force brute alors qu’il n’existe aucune plateforme qui laisserait faire de la force brute.
Clairement déjà avec 2/3 tentatives manqué, il bloque ton compte, il brule ta vie et il faut jurer allégeance et obéissance pour espérer pouvoir un jour retrouver le droit de tenter à nouveau de taper un mot de passe, alors 1000 essais, c’est pas gagné
1 « J'aime »