La GeForce RTX 4090 est capable de merveilles pour craquer facilement des identifiants. C’est ce que révèle un analyste en sécurité. Il a testé la nouvelle carte graphique premium de NVIDIA sur un benchmark, ce qui lui a permis d’estimer son efficacité lorsqu’il s’agit de pirater un mot de passe par force brute.
1 « J'aime »
Après avoir subi les cryptos sur les séries 3000, on maintenant se taper la crise des mots de passe sur les 4000…
6 « J'aime »
OK, mais rajoutez un seul caractère et vous multipliez le temps par 95.
Donc pour un mot de passe de 9 caractères parmi les 95 caractères de l’alphabet utilisé, cela nécessite 24 jours.
Avec 10 caractères on est à plus de 6 ans etc…
Donc la double auth est top, mais avoir un mot de passe robuste de plus de 10 caractères est déjà un bon départ (surtout pour ruiner les hackers qui voudraient investir dans plein de cartes graphiques à 2000€)
13 « J'aime »
A titre de comparaison c’était combien avec un RTX 3090 ?
C’est dit dans l’article : « elle est en la matière deux fois plus efficace que la RTX 3090 avant elle ».
WCCFTech n’a rien compris. Certes, l’auteur de hashcat a testé la vitesse de la RTX 4090 pour casser du bcrypt. Mais avec une vitesse d’à peine 200 kh/s, on est loin d’avoir quelque chose de dangereux, et on peut difficilement dire que la carte peut se mesurer à cet algo de hash…
À 200 kH/s, un bête mot de passe de 8 caractères alpha-numériques avec majuscules (soit 62 caractères possibles) résiste en moyenne… 17 ans.
Alors oui, avec une 3090 il fallait 34 ans. Mais passer de 34 ans à 17 ans sur un bête alnum de 8 caractères, c’est vraiment pas dramatique… (rappel : chaque caractère supplémentaire multiplie cette durée par 62…)
À noter qu’en plus, de par sa conception même, bcrypt est pensé pour avoir une complexité variable, que ses utilisateurs peuvent faire augmenter au fil du temps pour s’adapter à la hausse des performances : bcrypt s’utilise avec un nombre variable d’itérations, de sorte qu’on peut augmenter le nombre d’itérations au fil du temps pour conserver des hash de plus en plus dur à casser. Aujourd’hui, la plupart des libs implémentant bcrypt ont une complexité par défaut de 10 à 12, ce qui implique 1024 à 4096 itérations. Or là, les 200 kH/s, c’est avec une complexité de 5, seulement 32 itérations… Avec toujours 8 caractères alnum et une complexité à 10, on passe à 544 ans, à 12 on atteint 2176 ans… Par exemple, la valeur de complexité par défaut est à 10 dans PHP, c’est donc sans doute la valeur qui est utilisée pour l’écrasante majorité des sites utilisant ce langage.
Bref, encore une information sensationnaliste alors qu’en réalité y a rien de bien nouveau ou de bien surprenant, juste l’évolution logique de la puissance de calcul disponible…
10 « J'aime »
2000€ c’est ridicule comme investissement pour les groupes mafieux ou des hacker pros. a ce prix là on peu coupler des dizaines de cartes si le jeux en vaut la chandelle.
1 « J'aime »
with your password, a brut force need
5 hundred quadrillion années
good luck boys :-))))))))))))))
Article très intéressant. Cela met en perspective la difficulté croissante pour les humains d’utiliser des mots de passe.
Ce qui est à retenir, c’est l’augmentation de la puissance. Le temps peut être très fortement diminué par l’utilisation de rainbow tables, la location de temps de calcul parallèle sur le cloud et d’un tas d’autres joyeusetés comme forcer l’utilisation d’ une majuscule, d’une minuscule et d’un caractère complexe qui diminue fortement l’entropie.
Si on ajoute à ça la réutilisation des meme mots de passe, les transformations basiques de mots courants (o->0 etc), l’utilisation de pass phrase et les patterns communs (terminer ou commencer le mot de passe par . , ; ou !) , l’utilité de MFA est évidente.
Où après 3 tentative il faut attendre x temps etc, ça me rappelle les gens qui s amusait a bloquer les smartphones. Bref le brut force fait pas tout
1 « J'aime »
14 caractères pour spectres ( https://spectre.app/ )
Comme dit précédément soit avec l’OTP sois avec un temps d’attente apres 3 tentatives, et le cassage par brut force est useless
1 « J'aime »
Alors qu’il suffit d’imposer un délais (1s) entre chaque tentative…
1 « J'aime »
Beaucoup d’attaques par bruteforce se font sur des bases de données volées, pas en attaquant le service frontalement (de toute façon comme ça, même sans imposer un délai d’attente, la latence réseau empêche de faire un brute force efficace).
1 « J'aime »
Emmanuel Angulo, alors imaginez ce que ça va être avec la série 5000 !
Et pour 32 caractères, chiffres, lettres (majuscules et minuscules) et caractères spéciaux, il lui faudrait combien de temps ?
Le bruteforce s’attaque à l’algo, il n’agit pas comme un robot RPA
C’est le principe des algos de chiffrement, tester une combinaison coûte pas mal d’opérations logiques. Il est par contre impossible d’y insérer un timer qui n’est pas un objet mathématique.
pas besoin de faire des tentatives en ligne si on connait le hash on a tout son temps hors ligne 
1 « J'aime »
Pour le web pourquoi ne pas mettre en place un truc qui fait que si tu te plante de mot de passe 3 fois tu es bloqué 5 minutes, 5 fois 1/4h et 10 fois blocage infini (et tu dois changer de mot de passe) ?
Pour le moment on a surtout un max de 120 et quelques années. Faut quand même se presser, un peu. 
Parce que ce genre de mesure ne sert à peu près à rien… si ce n’est de permettre à un attaquant de faire chier le monde en bloquant des comptes.
En effet, faire un bruteforce directement sur le site web, c’est quasi impossible : la latence réseau est trop élevée pour que ça soit exploitable pour autre chose qu’une attaque par dictionnaire. Et pour contrer une attaque par dictionnaire, mieux vaut ralentir les calculs de hash et/ou bloquer les accès de l’attaquant (avec des outils « externes » comme fail2ban ou similaire) plutôt que le compte attaqué.
Et face à une attaque sur des données volées, tous les mécanismes d’attente ou de blocage sont de fait inutiles, puisqu’ils ne s’appliquent pas dans ce cas.
La seule solution pour contrer un bruteforce sur les données volées, c’est d’utiliser un algorithme « lent » pour le calcul des hash. Et c’est exactement le rôle de bcrypt.
Parce que en pratique, si le serveur met 10ms à valider le mot de passe d’un utilisateur parce que tu as utilisé un algorithme lent, c’est pas gênant pour l’utilisateur, il ne s’en rendra même pas compte. Mais l’attaquant, qui attaque par dictionnaire via le web, il ne pourra déjà plus que tester 100 mots de passe par seconde (même un peu moins en ajoutant la latence du réseau). Et celui qui a volé les données, même avec une machine 100 000 fois plus rapide, il ne pourra tester qu’un million de mots de passe par seconde, ce qui reste beaucoup trop lent face à des mots de passe non courants (1M par seconde face à simplement 8 caractères alphanumériques, c’est de l’ordre de 3 ans en moyenne pour casser un mot de passe…).
4 « J'aime »