Nos confrères ont été « victime d’une attaque informatique de grande ampleur », permise par l’exploitation d’une faille dans un module tiers pour pénétrer dans l’infrastructure. Le ou les pirates ont pu accéder à la base de données.
L’incident a été découvert après que plusieurs journalistes et développeurs ont été victimes de phishing. L’équipe dit avoir réalisé un audit complet, pris des mesures pour sécuriser davantage son infrastructure et isolé les serveurs atteints.
102 262 comptes ont été compromis. Dans chaque cas, le pseudo et l’email apparaissaient en clair, mais les mots de passe étaient hachés (SHA-512) et salés.
MacGeneration dit ignorer les motivations derrière cette attaque et suppose des conséquences limitées au vu des données volées. Cependant, l’équipe recommande de supprimer votre compte si vous ne l’utilisez plus, ou de changer votre mot de passe dans le cas contraire.
La CNIL a été notifiée et, en plus de l’annonce publique, tout membre disposant d’un compte actif au moins une fois au cours des douze derniers mois a reçu un email. MacGeneration a également notifié le service Have I Been Pwned? et compte déposer plainte dans les jours à venir.
Commentaires (14)
#1
“MacGeneration dit ignorer les motivations derrière cette attaque et suppose des conséquences limitées au vu des données volées”
Sauf pour ceux qui réutilisent la même adresse email partout et pire le même couple @ + mdp.
Le pirate s’en contrefout d’eux, tout ce qui l’intéresse c’est de pouvoir se faire de l’argent soit en vendant les données soit en les exploitant.
#1.1
Les mots de passes sont hachés et salés, donc peu de risque qu’ils soient utiles ailleurs, le salage étant différent pour chaque site.
#1.2
Certes mais on s’en fout un peu dans ce cas la, ya pas d’argent à ce faire avec des achats/ventes frauduleus(es). Ne pas avoir le mdp d’un mec qui ne fait que commenter sur des articles de presses, ça changera pas ta vie
Pas contre ya toujours l’@ mail et il existe déjà des BDD de précédentes fuites où cette même @mail peut être incluse et avec potentiellement un ou des mdp connu associés. Ca permet de savoir qu’elle sert toujours et peut donc être à creuser.
#2
Ce sont les mêmes identifiants pour le site et le forum ?
#3
C’est une bonne chose de hasher les mots de passe, et d’utiliser un salt.
Cela dit, SHA-512 est un algorithme trop rapide pour ça, qui ouvre la porte à des attaques par force brute.
Il vaut mieux utiliser bcrypt ou Argon2.
#3.1
Brut forcer un mot de pass salé ? ça n’a aucun intérêt ! Tu vas trouver une collision (mot de passe dont le hash correspond au vrai mot de passe+ sel) mais tu ne trouveras pas le vrai mot de passe !
La seule solution serait de tester toutes les collisions jusqu’à retrouver une terminant pas le sel employé. (mais même là rien ne dit qu’il n’y en a pas plusieurs qui matchent)
En termes de perf quand on évoque des temps de brut force c’est pour trouver une collision pas toutes !
Au contraire SHA-512 est un excellent choix, c’est supporté en hardware donc consomme peu de ressource serveur, et le sel permet de garantir qu’en cas de fuite seule ce site sera impacté (et pas d’autres sites utilisant le même couple login / mdp).
#3.2
Le salt t’empêchera de brute forcer les mots de passe de plusieurs utilisateurs à la fois, mais ne t’empêchera pas de les faire un par un.
C’est justement parce qu’il consomme peu de ressources que SHA-512 est un mauvais choix pour hasher des mots de passe.
De nos jours, tu peux calculer plusieurs milliards de hashs par seconde (en SHA-512) avec une seule carte graphique :
https://gist.github.com/Chick3nman/bb22b28ec4ddec0cb5f59df97c994db4
#3.3
des milliards par secondes ça fait pas grand-chose : 2^512 = 10^154 possibilités (à coup de 100 milliards par secondes 10^11) : ça fait encore 10^143 secondes, soit 10^135 années :)
Bon y’a un peu plus efficace que brut forcer toutes les possibilités, mais concrètement on est loin d’être dans des temps humains même à 100 GH/s :)
Et surtout ça ne sert à rien, si tu as accès aux hashs, tu as accès au serveur, et avec le sel la collision que tu trouverais ne fonctionnerait que pour un autre site utilisant exactement le même sel (ce qui à moins de copier / coller du code de stackoverflow sans rien comprendre est peu probable)
#3.4
Lorsque tu brutes forces le hash, tu dispose généralement du salt (il est habituellement stocké au même endroit que le hash).
Donc tu pourrais bien trouver des “vrais” mots de passe.
D’ailleurs le but du salt n’est pas d’être plus secret que le hash, mais de s’assurer que 2 utilisateurs qui utilisent le même mot de passe auront un hash différent, et d’empêcher l’utilisation de rainbow tables.
Après c’est sûr que tu ne pourras pas brute forcer tous les mots de passe de cette manière.
Mais tu trouveras les plus faciles :
#3.5
Correction : mon 1er calcul est faux (j’avais dû diviser par 2 millions au lieu de 2 milliards
).
#4
Ils ne savaient peut-être pas que les mdp étaient en sha512.
#4.1
Ben maintenant c’est fait. Sinon, les personnes n’ont pas reçu de mail sur le sujet de la part de ce site web…
#5
Si, ils ont bien envoyé un message.
#6
Si je réagis quand je vois des sites qui stockent (encore) leurs mots de passe en SHA-512 (ou pire, en SHA-1 ou MD5), c’est qu’il est facile aujourd’hui de les stocker correctement :
Par exemple en PHP : https://www.php.net/manual/fr/function.password-hash.php
Par exemple avec Symfony : https://symfony.com/doc/current/security/passwords.html
Dans ces 2 exemples, l’algorithme par défaut est bcrypt.