Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Hash MD5 - 60% des mots de passe craqués en moins d'une heure

60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas une étude de Kaspersky publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.

Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?

L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.

Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.

Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.

Source

Apple ajoute le chiffrement bout-en-bout entre iPhone et Android pour les RCS dans iOS 26.5

Avec iOS 26.5, Apple corrige enfin un manque que tout le monde signalait depuis l'arrivée du RCS sur iPhone : les messages échangés entre un iPhone et un Android n'étaient pas chiffrés.

Côté iPhone-vers-iPhone, les iMessage sont protégés de bout en bout depuis des années. Mais sitôt que la conversation passait par Android, la communication redevenait en clair, comme un bon vieux SMS. Plus pour longtemps.

Apple a travaillé avec la GSMA pour finaliser la version 3.0 de l'Universal Profile RCS, qui intègre le chiffrement de bout en bout en s'appuyant sur le protocole MLS (Messaging Layer Security). MLS, c'est ce qu'Apple, Google, Facebook et d'autres ont construit ensemble pour standardiser le chiffrement des messageries de groupe à l'échelle d'Internet.

Les RCS de l'iPhone vers Google Messages (et inversement) profitent maintenant directement de cette nouveauté, avec un petit cadenas dans la conversation pour vous le signaler.

Quelques contraintes quand même. Pour que le chiffrement marche, l'iPhone devra tourner sous iOS 26.5 ou plus récent, et l'Android doit être sur la dernière version de Google Messages. Surtout, l'opérateur télécom des deux côtés doit supporter cette mouture du RCS, ce qui n'est pas garanti partout dans le monde, et certains MVNO (les opérateurs sans réseau, type Sosh ou RED en France) traînent toujours sur les anciennes versions.

Le déploiement va donc se faire petit à petit. Sur le reste, plusieurs limitations de iMessage entre plateformes persistent : pas de message rappel, pas de réponse à un fil précis, pas de réactions emoji.

iOS 26.5 est en bêta depuis fin mars, en release candidate depuis cette semaine, et la sortie publique est attendue dans les jours qui viennent sans qu'Apple ait encore donné de date officielle. Le chiffrement RCS sera activé par défaut, avec un toggle dans les réglages de Messages pour le couper si vraiment vous voulez (ce qui n'a pas un grand sens, mais bon, vous faites ce que vous voulez de votre vie privée).

Bref, Apple boucle enfin la dernière brèche du RCS multiplateforme, presque deux ans après son intégration initiale.

Source : Ghacks

Pedro de Ayala - Sa lettre chiffrée de 1498 enfin décodée

Adrian William Jaime, Valeria Tapia Cruz et Mairi Cowan, 3 chercheurs de l'Université de Toronto, viennent de boucler le déchiffrement complet d'une lettre que personne n'avait jamais réussi à lire en entier depuis sa redécouverte en 1860. C'est Bruce Schneier qui relaye l'info sur son blog , et c'est pil poil une histoire qui prouve que l'infosec ne date pas d'hier.

La lettre fait 11 pages, elle a été écrite à Londres le 25 juillet 1498 par Pedro de Ayala, un noble de Tolède en mission diplomatique en Angleterre pour le compte de Ferdinand d'Aragon et Isabelle de Castille.

Pour empêcher les rivaux de la lire si jamais elle se faisait intercepter en chemin, Ayala a alors chiffré une partie du texte avec un système de symboles maison où, vice ultime du gars, plusieurs symboles différents pouvaient représenter la même lettre.

Première page de la lettre

Par conséquent, la table de fréquences classique, celle qui marche sur les chiffres mono-alphabétiques basiques, ne donnait donc rien de propre. Voilà pourquoi la chose a tenu 165 ans face à des historiens qui s'y cassaient les dents les uns après les autres.

Mais notre petite équipe de Toronto a fini par reconstruire la clé entière, symbole par symbole, et a publié la transcription complète dans Renaissance Studies en libre accès.

Et faut dire qu'une fois le texte en clair, le contenu vaut largement le travail !

En effet, Pedro de Ayala fait à ses souverains un brief politique cash sur l'état de la Grande-Bretagne. Sur Jacques IV d'Écosse, il balance que le mec parle latin, français, allemand, flamand, italien, espagnol et probablement gaélique, qu'il décrit comme « une langue que les sauvages parlent dans une certaine partie de son royaume ». Charmant.

Sur les Écossaises, c'est encore mieux : « Les femmes sont très courtoises à l'extrême. Je dis cela parce qu'elles sont très audacieuses. Elles sont les gouvernantes absolues de leurs maisons. »

Et sur Henri VII d'Angleterre, l'envoyé espagnol ne mâche pas ses mots : « Il n'est pas aimé du tout, la reine en revanche est beaucoup aimée parce qu'elle peut faire peu. ». Avec ce qu'il balance, je comprends que ce diplomate ait bien bossé son chiffrement.

Pedro, à fond dans le chiffrement !

Le bonus historique, c'est que la lettre confirme aussi le voyage transatlantique de Jean Cabot l'année précédente, avec une remarque assez piquante adressée à Ferdinand et Isabelle : « ce qu'ils ont trouvé ou cherchent est ce que Vos Altesses possèdent. » Traduction polie : les Anglais sont en train de venir mettre les pieds dans votre pré carré américain.

La lettre originale, numérisée, est consultable directement dans les archives espagnoles si vous voulez voir à quoi ressemble du chiffrement diplomatique fait main au XVe siècle.

Le truc qui me fait marrer dans cette affaire, c'est de réaliser que les principes du chiffrement par homophones, le fait d'utiliser plusieurs symboles pour la même lettre afin d'aplatir la fréquence d'apparition, ce sont exactement les bases sur lesquelles ont été pensées plus tard les machines comme Enigma.

Pedro de Ayala, en 1498, faisait déjà sans le savoir un peu de cryptanalyse-resistant design. Et 5 siècles plus tard, il aura fallu trois universitaires et probablement des outils informatique que lui n'aurait jamais pu imaginer pour casser sa petite combine.

Trop fort Pedro !!

Source : Medievalists.net

Nullroom - Un chat P2P qui s'efface en 15 minutes

Utiliser une conversation WhatsApp pour partager un mot de passe à un pote, c'est un peu comme écrire son code de carte bleue au marker dans des chiottes publics. Sauf que les messages, eux, restent des années dans l'historique car y'a personne qui viendra nettoyer ça. Heureusement, Nullroom vient régler ce genre de bricole en mode radical, avec un chat P2P chiffré qui s'autodétruit au bout d'un quart d'heure, sans avoir à vous créer de compte et sans laisser de trace côté serveur.

Alors comment ça fonctionne ? Hé bien vous cliquez sur "CREATE SECURE ROOM", un lien apparaît, vous le balancez à votre correspondant par le canal de votre choix (Signal, SMS, pigeon voyageur...etc), et hop, une session chiffrée s'ouvre entre vos deux navigateurs. Vous pouvez alors discuter, échanger éventuellement des fichier (jusqu'à 16 Mo max en beta), et après 15 minutes, la room s'évaporera. Purement et simplement et aucun serveur n'aura vu passer vos échanges (mis à par quelques bouts de métadonnées pour établir la connexion).

Sous le capot, y'a un truc crypto assez chouette qui est une clé de chiffrement AES-GCM 256 bits, générée côté client via l'API Web Crypto du navigateur, qui vit dans le fragment de l'URL (c'est la partie qui vient après le #). Et comme les navigateurs n'envoient JAMAIS ce fragment au serveur, vu que c'est un standard HTTP, vous êtes tranquille.

Et voilà comment votre clé de session n'existe que chez vous et chez votre correspondant. Le serveur de Nullroom ne la voit pas, même pas une microseconde. C'est le même trick que celui qu'utilise PrivateBin pour les snippets chiffrés, mais appliqué à du chat en direct.

Le flux de données, lui, passe en direct d'un navigateur à l'autre via WebRTC et le serveur ne sert comme je vous le disais plus haut, qu'à la poignée de main initiale.

Ensuite, les messages et les fichiers circulent en peer-to-peer, relayés via les serveurs TURN de Cloudflare quand votre NAT coince. Donc au pire, Cloudflare voit passer du trafic 100% chiffré, et pas le contenu en clair. Les logs serveur sont également désactivés sur les chemins des rooms, et les UUIDs de sessions vivent dans un Redis totalement volatile qui est nettoyé au bout de ces fameuses 15 minutes.

Niveau limites, une room c'est deux personnes max donc si vous cherchiez un remplaçant à Signal ou à Briar, ce n'est pas le bon outil. C'est juste une messagerie pour un échange ponctuel entre 2 personnes.

Et l'équipe ou l'entreprise derrière n'est pas affichée côté site (pas de mentions légales, pas de juridiction précisée), donc attention ! Ça reste du "faites-vous votre opinion" mais comme le code est open source (licence MIT) sur GitHub vous pouvez quand même l'analyser et monter votre propre infra Nullroom.

Pour le quotidien, c'est un service qui est bien foutu, que ce soit pour un mot de passe à filer à un collègue en télétravail, un lien temporaire à partager pendant une réu, une confidence à un pote qui n'a rien à faire dans les archives iMessage, ou encore un numéro de compte à transmettre vite fait avant que l'autre ne parte en vacances... Tous ces cas d'usage existent et la friction est quasi nulle donc c'est plutôt une bonne approche je trouve.

Voilà, si vous voulez tester le concept d'une conversation qui n'aura jamais eu lieu, filez sur nullroom.io.

❌