Vue lecture

Journée Rust Paris le 9 juin 2026 pour les devs et utilisateurs

Adeptes de Rust, et aussi ceux qui se demandent s'il faut s'y mettre, bloquez votre 9 juin 2026 la semaine prochaine ! La conférence Rust Paris revient pour sa troisième édition, même jour, même heure et même lieu. Cette journée est toujours dédiée aux développeurs et aux utilisateurs de Rust, avec un mot d’ordre : REX — retour d’expérience. Les intervenants viendront partager leurs succès, mais aussi les défis rencontrés, dans des contextes variés : WebAssembly, systèmes embarqués, critiques & Temps-réel, cybersécurité (fuzzing, audit), vérification formelle & certification, Big Data, HPC, Cloud & Microservices, Réseaux & Infrastructures, IA, recherche académique…

Bannière de la conférence RUST 2026

  • 📅 9 juin 2025
  • ⏰ 9h00 — 19h00
  • 📍 Université de Jussieu – 4, place Jussieu 75005 Paris, amphithéâtre 43, au fond à droite en entrant
  • 🎟️ C'est une conférence payante (120 € HT) mais…
    • 15% de réduction pour les lecteurs de LinuxFr.org si vous utilisez le code LinuxFR_RustParis2026
    • voire gratuite si votre employeur est membre de Systematic (Pôle de compétitivité organisateur via le Hub Open Source)

Programme détaillé

  • 09h00 - 09h30 : Accueil des participants
  • 09h30 - 09h45 : Introduction
  • 09h45 - 10h30 : Keynote - Petite histoire de Rust hors des industries de la Tech
  • 10h35 - 11h05 : Sécuriser du code Rust en pratique : fuzzing, IA et retours terrain
    • 🗣️ Patrick Ventuzelo, CEO & Founder | FuzzingLabs
  • 11h05 - 11h25 : Pause
  • 11h25 - 11h55 : Vérifier formellement des programmes Rust avec Creusot
    • 🗣️ Li-yao Xia, Ingénieur R&D | LMF – Inria
    • 🗣️ Jacques-Henri Jourdan, Chargé de recherche | LMF – CNRS
  • 12h00 - 12h30 : Quand Python ne suffit plus : Transférer des Petaoctets de manière efficace et sûre
    • 🗣️ Florian Lemaitre, HPC expert and Cloud architect | Aneo
    • 🗣️ Dylan Brasseur, HPC expert | Aneo
  • 12h30 - 14h00 : Cocktail déjeunatoire
  • 14h00 - 14h30 : Architecture à composants : coup de neuf avec Rust
    • 🗣️ Thomas Clemenceau, Ingénieur logiciel embarqué et critique | Thales
    • 🗣️ Thomas Emerdjian, Ingénieur Développeur logiciel embarqué | Thales
  • 14h35 - 15h05 : Notre Load Balancer Rust en production : le Bon, la Brute, et l’Async
    • 🗣️ Florian Lemaitre, HPC expert and Cloud architect | Aneo
    • 🗣️ Jérôme Gurhem, HPC expert and Cloud architect | Aneo
  • 15h10 - 15h40 : Optimisation des systèmes logiciels complexes via une migration vers Rust et WebAssembly
    • 🗣️ Gabin Fourcault, Ingénieur Architecte des systèmes et des logiciels | Thales Alenia Space
  • 15h40 - 16h00 : Pause
  • 16h00 - 16h30 : Projet de recherche Fos-R:
    • 🗣️ Pierre-François Gimenez, Chercheur | Inria
  • 16h35 - 17h05 : What’s left to find in Rust code?
    • 🗣️ Rolland Dudemaine, Directeur Solutions Engineering EMEA/APAC | TrustInSoft
  • 17h05 - 17h10 : Conclusion
  • 17h10 - 19h00 : Cocktail networking

Accès

  • Métro : lignes 7 ou 10, station « Jussieu »
  • Bus : lignes 89 ou 67 (arrêt Jussieu ou Institut du Monde Arabe)
  • Amphithéâtre 43, au fond à droite en entrant

À Propos de Rust

Pour rappel, Rust est un langage de programmation multi-paradigme qui met l’accent sur les performances, la sécurité mémoire et la concurrence. Depuis ses débuts chez Mozilla jusqu’à sa large adoption par les géants du numérique et dans le noyau Linux, Rust continue de gagner en crédibilité et en popularité.

Nouvelle anecdote

Après l'origine du nom l'année passée, voici une nouvelle petite anecdote d'actualité pour ceux qui ont lu jusqu'au bout.

Lors de sa récente conférence BUILD, Microsoft a annoncé (source Next.ink) proposer désormais un paquet officiel nommé Coreutils for Windows pour Windows 11 qui intègre les réécritures en Rust de uutils/coreutils (dont le lead est notre ami Sylvestre Ledru, directeur de l’ingénierie chez Mozilla), ainsi que findutils et grep.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Dashlane : la fuite des coffres-forts rappelle l’importance du mot de passe maître

C’est bon, j’ai mis Password123!
Dashlane : la fuite des coffres-forts rappelle l’importance du mot de passe maître

Les gestionnaires de mots de passe permettent d’utiliser des mots de passe différents et complexes pour tous les services. Ils doivent eux aussi être protégés par un mot de passe maître, qui est parfois le dernier rempart contre les pirates. Une fuite de données chez Dashlane l’illustre parfaitement.

Après LastPass fin 2022, c’est au tour de Dashlane d’être victime d’une fuite de données : « Les attaquants ont pu télécharger une copie des coffres-forts chiffrés de moins de 20 utilisateurs sur un forfait personnel », reconnait l’entreprise.

Des coffres-forts chiffrés dans la nature

« À partir du dimanche 31 mai 2026, un pirate a lancé une attaque par force brute contre certains comptes d’utilisateurs de Dashlane », explique l’entreprise. L’attaquant essayait de casser l’authentification à deux facteurs afin d’enregistrer de nouveaux appareils sur des comptes d’utilisateurs, pour ensuite accéder aux données.

Bien évidemment, des protections ont permis de limiter l’attaque – mais pas de la bloquer totalement : « En raison du nombre élevé de tentatives d’accès aux comptes utilisateurs, les contrôles de sécurité de Dashlane ont automatiquement verrouillé les comptes ciblés par l’attaque », explique Dashlane.

Des comptes ont été suspendus de manière temporaire, mais surtout pour une vingtaine de clients le coffre-fort a été dérobé. Ils ont tous été déjà contactés individuellement par Dashlane.

Quels sont les risques ?

Avec les coffres-forts chiffrés, le ou les pirates ne peuvent pas faire grand-chose, sauf à réussir à les ouvrir évidemment. Ils accéderaient alors à l’intégralité des informations qu’ils contiennent : mots de passe, identifiants… une vraie caverne d’Alibaba.

Pour arriver à leurs fins, ils peuvent tenter de faire du phishing afin que vous « donniez » involontairement votre mot de passe maître, mais aussi tenter de passer en force.

Brutale, cette méthode consiste à tester toutes les combinaisons possibles jusqu’à trouver la bonne. En théorie, cela finit toujours par fonctionner. En pratique, il faut un temps quasi infini selon la taille et la complexité de votre mot de passe. On parle aussi d’entropie.

Autant dire que si votre mot de passe est « password123 », il ne tiendra même pas quelques secondes. Avec une copie de votre coffre-fort en sa possession, un pirate peut effectuer autant de tentatives qu’il le souhaite jusqu’à réussir à trouver le bon mot de passe et ainsi percer les protections.

Des années plus tard, la fuite Lastpass fait toujours des victimes

La fuite de Lastpass fin 2022 en est un parfait exemple. Cette fuite avait encore des conséquences en 2025, comme le rapporte BleepingComputer : « Plutôt que le portefeuille [de cryptomonnaie, qui est aussi parfois stocké dans les coffres-forts, ndlr] soit vidé immédiatement après une brèche, les vols se sont multipliés par vagues des mois ou des années plus tard, illustrant comment les attaquants décryptaient progressivement les coffres ».

Une autre manière de le dire : si votre coffre-fort est dans la nature, il est plus que recommandé de changer l’intégralité des secrets et mots de passe qui y sont enregistrés. Un pirate pourrait en forcer la porte maintenant comme dans quelques années quand la puissance de calcul coutera bien moins chère, par exemple.

Votre mot de passe maître doit être fort et robuste !

Dashlane reconnait ne pas avoir « d’exigences spécifiques pour les mots de passe maîtres », mais précise néanmoins s’appuyer sur « l’algorithme zxcvbn [de Daniel Lowe Wheeler chez Dropbox, ndlr] afin d’évaluer la sécurité de votre mot de passe lors de sa création ». L’entreprise prodigue aussi quelques conseils. Next a aussi des dossiers sur le sujet.

Les clients de Dashlane sont les victimes, mais cette affaire rappelle l’importance du mot de passe maître qui sera le dernier rempart en cas de fuite de données. C’est valable quel que soit le gestionnaire utilisé, y compris (et surtout) en autohébergé. Si vous autohébergez un gestionnaire, ne sous-estimez surtout pas le mot de passe maitre.

  •  

Dashlane : la fuite des coffres-forts rappelle l’importance du mot de passe maître

C’est bon, j’ai mis Password123!
Dashlane : la fuite des coffres-forts rappelle l’importance du mot de passe maître

Les gestionnaires de mots de passe permettent d’utiliser des mots de passe différents et complexes pour tous les services. Ils doivent eux aussi être protégés par un mot de passe maître, qui est parfois le dernier rempart contre les pirates. Une fuite de données chez Dashlane l’illustre parfaitement.

Après LastPass fin 2022, c’est au tour de Dashlane d’être victime d’une fuite de données : « Les attaquants ont pu télécharger une copie des coffres-forts chiffrés de moins de 20 utilisateurs sur un forfait personnel », reconnait l’entreprise.

Des coffres-forts chiffrés dans la nature

« À partir du dimanche 31 mai 2026, un pirate a lancé une attaque par force brute contre certains comptes d’utilisateurs de Dashlane », explique l’entreprise. L’attaquant essayait de casser l’authentification à deux facteurs afin d’enregistrer de nouveaux appareils sur des comptes d’utilisateurs, pour ensuite accéder aux données.

Bien évidemment, des protections ont permis de limiter l’attaque – mais pas de la bloquer totalement : « En raison du nombre élevé de tentatives d’accès aux comptes utilisateurs, les contrôles de sécurité de Dashlane ont automatiquement verrouillé les comptes ciblés par l’attaque », explique Dashlane.

Des comptes ont été suspendus de manière temporaire, mais surtout pour une vingtaine de clients le coffre-fort a été dérobé. Ils ont tous été déjà contactés individuellement par Dashlane.

Quels sont les risques ?

Avec les coffres-forts chiffrés, le ou les pirates ne peuvent pas faire grand-chose, sauf à réussir à les ouvrir évidemment. Ils accéderaient alors à l’intégralité des informations qu’ils contiennent : mots de passe, identifiants… une vraie caverne d’Alibaba.

Pour arriver à leurs fins, ils peuvent tenter de faire du phishing afin que vous « donniez » involontairement votre mot de passe maître, mais aussi tenter de passer en force.

Brutale, cette méthode consiste à tester toutes les combinaisons possibles jusqu’à trouver la bonne. En théorie, cela finit toujours par fonctionner. En pratique, il faut un temps quasi infini selon la taille et la complexité de votre mot de passe. On parle aussi d’entropie.

Autant dire que si votre mot de passe est « password123 », il ne tiendra même pas quelques secondes. Avec une copie de votre coffre-fort en sa possession, un pirate peut effectuer autant de tentatives qu’il le souhaite jusqu’à réussir à trouver le bon mot de passe et ainsi percer les protections.

Des années plus tard, la fuite Lastpass fait toujours des victimes

La fuite de Lastpass fin 2022 en est un parfait exemple. Cette fuite avait encore des conséquences en 2025, comme le rapporte BleepingComputer : « Plutôt que le portefeuille [de cryptomonnaie, qui est aussi parfois stocké dans les coffres-forts, ndlr] soit vidé immédiatement après une brèche, les vols se sont multipliés par vagues des mois ou des années plus tard, illustrant comment les attaquants décryptaient progressivement les coffres ».

Une autre manière de le dire : si votre coffre-fort est dans la nature, il est plus que recommandé de changer l’intégralité des secrets et mots de passe qui y sont enregistrés. Un pirate pourrait en forcer la porte maintenant comme dans quelques années quand la puissance de calcul coutera bien moins chère, par exemple.

Votre mot de passe maître doit être fort et robuste !

Dashlane reconnait ne pas avoir « d’exigences spécifiques pour les mots de passe maîtres », mais précise néanmoins s’appuyer sur « l’algorithme zxcvbn [de Daniel Lowe Wheeler chez Dropbox, ndlr] afin d’évaluer la sécurité de votre mot de passe lors de sa création ». L’entreprise prodigue aussi quelques conseils. Next a aussi des dossiers sur le sujet.

Les clients de Dashlane sont les victimes, mais cette affaire rappelle l’importance du mot de passe maître qui sera le dernier rempart en cas de fuite de données. C’est valable quel que soit le gestionnaire utilisé, y compris (et surtout) en autohébergé. Si vous autohébergez un gestionnaire, ne sous-estimez surtout pas le mot de passe maitre.

  •  

CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Hard times
CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Une importante faille de sécurité a été découverte dans Linux par un ingénieur en sécurité de chez SpaceX. Exploitée, elle permet d’obtenir les droits root sur un compte local. Elle résidait dans le noyau depuis 2007.

La faille CIFSwitch fait parler d’elle depuis quelques jours. Découverte par Asim Viladi Oglu Manizada, ingénieur en sécurité chez SpaceX, elle a fait l’objet d’un billet détaillé par ce dernier le 27 mai. On peut notamment y lire qu’elle a été introduite en 2007 et réside à l’intersection du module CIFS (Common Internet File System) dans le noyau et d’un code en espace utilisateur.

Une absence de vérification

L’ingénieur explique que CIFS/SMB est un protocole de fichiers réseau de type Windows et est utilisé pour le montage de ressources distantes. La partie dans le noyau sert ainsi à monter le partage, communiquer avec le serveur, gérer les lectures et écritures, etc. Dans le cas de ressources protégées par Kerberos, le composant noyau fait cependant appel à un assistant (helper) en espace utilisateur fourni par cifs-utils.

C’est là que survient le problème. Quand un partage réseau nécessite une authentification Kerberos, le noyau demande une clé de type cifs.spnego. À ce moment, un composant disposant des droits root, cifs.upcall, est chargé de récupérer les informations d’identification pour que la requête d’une clé se poursuive. Malheureusement, rien n’empêche un utilisateur malintentionné et sans privilège de lancer la même requête avec des informations fabriquées de toutes pièces.

La fausse description peut ainsi introduire un identifiant PID contrôlé par le pirate. Or, le mécanisme de fourniture de la clé ne rejette pas les descriptions fournies par du code en espace utilisateur : elles sont traitées comme si elles venaient du noyau. Résultat, une belle faille de sécurité de type élévation de privilèges. Estampillée CVE-2026-46243, elle échappe de justesse à la qualification « critique » avec un score CVSS de 7,8.

Une dangerosité variable

Sa dangerosité réelle est difficile à exprimer, car elle dépend fortement des configurations. Il faut ainsi un noyau vulnérable, une version vulnérable de cifs-utils, ainsi que, au choix, un espace de noms utilisateur non privilégié ou une politique SELinux/AppArmor ne bloquant pas l’attaque.

Sur les distributions Ubuntu 18.04 à 24.04, Debian 11 à 13, openSUSE Leap 15.6 ou Oracle Linux 8 ou 9 notamment, si cifs-utils est installé, la configuration est vulnérable par défaut. Pour d’autres, comme Linux Mint (21.3 / 22.3), CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux (versions 2021.4 à 2026.1) et SUSE Linux Enterprise Server 15 SP7, cifs-utils est installé par défaut, rendant ces distributions vulnérables.

Les correctifs sont en cours de distribution ou le seront très prochainement. Indépendamment du correctif, il est recommandé de vérifier si le protocole CIFS/SMB est installé et, s’il ne sert pas, de le supprimer. Cela fait plusieurs fois en quelques semaines que des failles d’élévation de privilèges sont détectées dans Linux.

  •  

CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Hard times
CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Une importante faille de sécurité a été découverte dans Linux par un ingénieur en sécurité de chez SpaceX. Exploitée, elle permet d’obtenir les droits root sur un compte local. Elle résidait dans le noyau depuis 2007.

La faille CIFSwitch fait parler d’elle depuis quelques jours. Découverte par Asim Viladi Oglu Manizada, ingénieur en sécurité chez SpaceX, elle a fait l’objet d’un billet détaillé par ce dernier le 27 mai. On peut notamment y lire qu’elle a été introduite en 2007 et réside à l’intersection du module CIFS (Common Internet File System) dans le noyau et d’un code en espace utilisateur.

Une absence de vérification

L’ingénieur explique que CIFS/SMB est un protocole de fichiers réseau de type Windows et est utilisé pour le montage de ressources distantes. La partie dans le noyau sert ainsi à monter le partage, communiquer avec le serveur, gérer les lectures et écritures, etc. Dans le cas de ressources protégées par Kerberos, le composant noyau fait cependant appel à un assistant (helper) en espace utilisateur fourni par cifs-utils.

C’est là que survient le problème. Quand un partage réseau nécessite une authentification Kerberos, le noyau demande une clé de type cifs.spnego. À ce moment, un composant disposant des droits root, cifs.upcall, est chargé de récupérer les informations d’identification pour que la requête d’une clé se poursuive. Malheureusement, rien n’empêche un utilisateur malintentionné et sans privilège de lancer la même requête avec des informations fabriquées de toutes pièces.

La fausse description peut ainsi introduire un identifiant PID contrôlé par le pirate. Or, le mécanisme de fourniture de la clé ne rejette pas les descriptions fournies par du code en espace utilisateur : elles sont traitées comme si elles venaient du noyau. Résultat, une belle faille de sécurité de type élévation de privilèges. Estampillée CVE-2026-46243, elle échappe de justesse à la qualification « critique » avec un score CVSS de 7,8.

Une dangerosité variable

Sa dangerosité réelle est difficile à exprimer, car elle dépend fortement des configurations. Il faut ainsi un noyau vulnérable, une version vulnérable de cifs-utils, ainsi que, au choix, un espace de noms utilisateur non privilégié ou une politique SELinux/AppArmor ne bloquant pas l’attaque.

Sur les distributions Ubuntu 18.04 à 24.04, Debian 11 à 13, openSUSE Leap 15.6 ou Oracle Linux 8 ou 9 notamment, si cifs-utils est installé, la configuration est vulnérable par défaut. Pour d’autres, comme Linux Mint (21.3 / 22.3), CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux (versions 2021.4 à 2026.1) et SUSE Linux Enterprise Server 15 SP7, cifs-utils est installé par défaut, rendant ces distributions vulnérables.

Les correctifs sont en cours de distribution ou le seront très prochainement. Indépendamment du correctif, il est recommandé de vérifier si le protocole CIFS/SMB est installé et, s’il ne sert pas, de le supprimer. Cela fait plusieurs fois en quelques semaines que des failles d’élévation de privilèges sont détectées dans Linux.

  •  

☕️ L’assistant IA de Meta permettait de voler des comptes Instagram



L’assistance IA mise en place par Meta pour la gestion des comptes Instagram a autorisé pendant plusieurs semaines n’importe qui d’assez malin à changer l’adresse e-mail associée à un compte. Les propriétaires légitimes se retrouvaient donc « enfermés dehors », incapables de se connecter à leur compte et de reprendre la main.

Depuis le mois de mars, les utilisateurs de Facebook et d’Instagram qui ont besoin d’aide pour gérer leur compte peuvent faire appel à un assistant IA spécialisé, « fiable, rapide, efficace, disponible en tout temps », promettait Meta. Un soutien « axé sur l’action » pour résoudre les problèmes de compte « de A à Z ». Ce qui signifie réaliser des opérations particulièrement sensibles comme la réinitialisation du mot de passe ou le changement de l’e-mail associé au compte.

Capture d’écran : 404media

Depuis la mise en place de ce nouveau mécanisme IA, plusieurs profils Instagram de premier plan, comme un compte appartenant à Barack Obama, celui de la marque Sephora ou du chef des sous-officiers de la Space Force, ont été piratés ces dernières semaines. Les propriétaires légitimes de ces comptes ne pouvaient plus y accéder et pour cause, l’adresse e-mail associée avait changé sans leur autorisation.

Le « nouveau » propriétaire du compte était alors en mesure de publier n’importe quel contenu, contacter les abonnés, diffuser des arnaques, revendre le compte à des tiers… 404media rapporte que Meta aurait corrigé la vulnérabilité qui ouvrait la porte à ces margoulins. C’est la méthode qui est intéressante ici : il ne s’agit pas d’une faille de sécurité à proprement parler, mais d’ingénierie sociale appliquée aux agents IA.

Sur Telegram, des chercheurs en sécurité et des groupes de hackers ont partagé des vidéos et des captures d’écran explicitant le mode opératoire pour voler un compte Instagram. Le scénario est le suivant : l’attaquant connaît le nom d’utilisateur Instagram de la cible ; armé d’un VPN, qui lui permet d’apparaître dans le même pays ou la même région que la victime, il lance une procédure de récupération de compte.

Après avoir ouvert une conversation avec l’assistant IA de Meta, le pirate convainc le bot de remplacer l’adresse e-mail associée au compte par une adresse qu’il contrôle. L’IA envoie alors un code de validation à cette nouvelle adresse. Une fois l’adresse modifiée, l’attaquant peut demander une réinitialisation du mot de passe et prendre le contrôle du compte.

L’IA de Meta aurait accepté une opération extrêmement sensible sans vérifier correctement que l’utilisateur était bien le propriétaire du compte. Cette technique d’injection de prompts contourne les sécurités habituelles liées à un changement d’adresse e-mail, une opération qui ne peut normalement pas être effectuée sans une authentification forte et un délai ou une validation depuis l’ancienne adresse. L’assistance de Meta bénéficiait donc manifestement de privilèges extrêmement élevés, sans qu’aucun garde-fou ne vienne mettre le holà.

En décembre dernier, OpenAI abordait les injections de prompts sur le fond, et admettait qu’il s’agissait d’un problème à long terme. Meta n’est pas le seul acteur IA à y faire face.

  •  

☕️ L’assistant IA de Meta permettait de voler des comptes Instagram



L’assistance IA mise en place par Meta pour la gestion des comptes Instagram a autorisé pendant plusieurs semaines n’importe qui d’assez malin à changer l’adresse e-mail associée à un compte. Les propriétaires légitimes se retrouvaient donc « enfermés dehors », incapables de se connecter à leur compte et de reprendre la main.

Depuis le mois de mars, les utilisateurs de Facebook et d’Instagram qui ont besoin d’aide pour gérer leur compte peuvent faire appel à un assistant IA spécialisé, « fiable, rapide, efficace, disponible en tout temps », promettait Meta. Un soutien « axé sur l’action » pour résoudre les problèmes de compte « de A à Z ». Ce qui signifie réaliser des opérations particulièrement sensibles comme la réinitialisation du mot de passe ou le changement de l’e-mail associé au compte.

Capture d’écran : 404media

Depuis la mise en place de ce nouveau mécanisme IA, plusieurs profils Instagram de premier plan, comme un compte appartenant à Barack Obama, celui de la marque Sephora ou du chef des sous-officiers de la Space Force, ont été piratés ces dernières semaines. Les propriétaires légitimes de ces comptes ne pouvaient plus y accéder et pour cause, l’adresse e-mail associée avait changé sans leur autorisation.

Le « nouveau » propriétaire du compte était alors en mesure de publier n’importe quel contenu, contacter les abonnés, diffuser des arnaques, revendre le compte à des tiers… 404media rapporte que Meta aurait corrigé la vulnérabilité qui ouvrait la porte à ces margoulins. C’est la méthode qui est intéressante ici : il ne s’agit pas d’une faille de sécurité à proprement parler, mais d’ingénierie sociale appliquée aux agents IA.

Sur Telegram, des chercheurs en sécurité et des groupes de hackers ont partagé des vidéos et des captures d’écran explicitant le mode opératoire pour voler un compte Instagram. Le scénario est le suivant : l’attaquant connaît le nom d’utilisateur Instagram de la cible ; armé d’un VPN, qui lui permet d’apparaître dans le même pays ou la même région que la victime, il lance une procédure de récupération de compte.

Après avoir ouvert une conversation avec l’assistant IA de Meta, le pirate convainc le bot de remplacer l’adresse e-mail associée au compte par une adresse qu’il contrôle. L’IA envoie alors un code de validation à cette nouvelle adresse. Une fois l’adresse modifiée, l’attaquant peut demander une réinitialisation du mot de passe et prendre le contrôle du compte.

L’IA de Meta aurait accepté une opération extrêmement sensible sans vérifier correctement que l’utilisateur était bien le propriétaire du compte. Cette technique d’injection de prompts contourne les sécurités habituelles liées à un changement d’adresse e-mail, une opération qui ne peut normalement pas être effectuée sans une authentification forte et un délai ou une validation depuis l’ancienne adresse. L’assistance de Meta bénéficiait donc manifestement de privilèges extrêmement élevés, sans qu’aucun garde-fou ne vienne mettre le holà.

En décembre dernier, OpenAI abordait les injections de prompts sur le fond, et admettait qu’il s’agissait d’un problème à long terme. Meta n’est pas le seul acteur IA à y faire face.

  •  

Riches, mais pas que : pourquoi les fans de F1 sont-ils des cibles parfaites pour les hackers ?

La popularité de la Formule 1 ne profite pas qu'aux écuries et aux diffuseurs. Dans l'ombre, une autre industrie tourne à plein régime : la cybercriminalité. Rencontre avec Bogdan Botezatu, directeur de la recherche sur les menaces chez Bitdefender, qui a cartographié les risques cyber auxquels s'exposent les fans du sport automobile.

  •  

SelfRecover — protocole AGPL de récupération de compte sans email

Je suis agriculteur en Creuse et je code sur mon temps libre. J'ai commencé à m'intéresser à la question de la récupération de compte en développant ARC PVE Hub, un site destiné à fédérer une communauté de joueurs. Je n'ai jamais compris pourquoi il fallait transmettre son email pour régénérer un mot de passe — ça déplace la sécurité du compte vers un fournisseur SMTP tiers, qui n'est pas contrôlé par l'utilisateur.

J'ai donc imaginé un protocole de récupération sans email, sans SMS et sans tiers. Le travail s'est étoffé en partenariat avec un assistant IA (Claude), comme outil de réflexion et de mise en forme — j'y reviens en fin de dépêche dans une note de transparence.

L'incident de sécurité ANTS du 15 avril 2026 a publiquement illustré le problème. J'en ai eu connaissance après avoir développé SelfRecover, ce qui m'a confirmé la pertinence d'un protocole sans dépendance à l'email. SelfRecover est publié sous AGPL-3.0-or-later sur GitHub.

Cette dépêche présente le protocole, ses choix de conception, ses limites assumées, et la comparaison avec les approches existantes (Keycloak Recovery Codes en particulier, qui m'a été suggéré en relecture). Audit communautaire bienvenu.

Sommaire

Le contexte

Depuis l'essor du web, la réponse standard à « l'utilisateur a oublié son mot de passe » est « on lui envoie un lien de réinitialisation par email ». C'est devenu si universel qu'on oublie ce que ça implique :

  • La sécurité du compte est déléguée au fournisseur de la boîte mail (Gmail, Outlook, ProtonMail). Si la boîte mail tombe, le compte aussi.
  • Le canal email est régulièrement exploité par phishing : campagnes imitant des mails de réinitialisation légitimes pour capturer les mots de passe.
  • Les bases de données qui stockent les emails des utilisateurs deviennent une cible massive : leur fuite expose à la fois l'identité et les vecteurs de récupération.

L'incident de sécurité ANTS illustre une autre facette du problème de gestion des données d'authentification dans les services en ligne. Détecté le 15 avril 2026 et rendu public le 20 avril, il a touché 11,7 millions de comptes selon les communiqués officiels. La cause technique identifiée est une faille d'énumération de type IDOR (Insecure Direct Object Reference) : il était possible d'accéder aux données d'un autre compte en modifiant un identifiant dans une URL. La fuite ne concerne ni les mots de passe, ni les pièces justificatives, mais les données personnelles associées aux demandes de titres.

Devant ces limites structurelles autour de l'authentification web, SelfRecover propose une inversion : conserver le secret de récupération chez l'utilisateur, et utiliser le navigateur pour faire les calculs cryptographiques nécessaires à la vérification. Le serveur ne détient plus que des dérivés, jamais les secrets bruts.

Le protocole en deux phrases

Côté navigateur, on calcule HMAC-SHA256(secret, domaine) : une fonction cryptographique standard qui combine le secret de l'utilisateur avec le nom de domaine du site, et produit une empreinte impossible à inverser. Côté serveur, on ne stocke que cette empreinte, en plus protégée par un hash adaptatif et memory-hard : Argon2id, qui est le standard moderne recommandé contre les attaques par brute force.

Deux propriétés découlent de cette construction :

  • Le secret brut ne quitte jamais le poste de l'utilisateur.
  • Un secret capturé sur un site A (par exemple via phishing) est mathématiquement inutilisable sur un site B : la dérivation HMAC produit des empreintes différentes pour des domaines différents. C'est de l'anti-phishing par construction, pas par convention.

Note conceptuelle : l'inspiration vient des machines à rotors historiques type Enigma. Le principe partagé est qu'une même configuration secrète, présente des deux côtés (émetteur et récepteur), permet de produire et vérifier un message dérivé. La cryptographie moderne (HMAC-SHA256 ici) repose sur des fondations mathématiques différentes, mais ce principe de dérivation contrôlée par un secret commun est resté.

Deux modes d'adoption

SelfRecover propose deux modes selon le contexte de déploiement.

Mode Full — Sans email

L'application abandonne entièrement le flow de réinitialisation par email. L'utilisateur génère une passphrase diceware à l'inscription (liste EFF de 7 776 mots, 4 à 7 mots par défaut), qu'il mémorise ou stocke dans son gestionnaire de mots de passe. Cette passphrase, combinée au nom de domaine du site via HMAC-SHA256, permet de réinitialiser le mot de passe sans aucune dépendance externe.

Pour qui : nouveaux projets qui veulent s'affranchir de SMTP dès la conception, ou services qui adoptent un modèle de menace post-fuite (l'email n'est plus considéré comme un canal de confiance).

Mode Lite — Avec email + mot mémorisé

L'application conserve le flow de réinitialisation par email habituel, mais y ajoute une étape supplémentaire : l'utilisateur saisit un mot mémorisé (choisi à l'inscription) qui est dérivé HMAC-SHA256 côté navigateur. Le mot brut n'est jamais transmis au serveur. La validation combine donc deux facteurs :

  1. La possession de la boîte mail (lien reset reçu)
  2. La connaissance du mot mémorisé (dérivé HMAC côté client)

Pour qui : applications existantes qui ne peuvent abandonner SMTP du jour au lendemain, mais veulent durcir progressivement leur flow de récupération. Conséquence : un email intercepté seul ne suffit plus à compromettre un compte — il faut aussi connaître le mot mémorisé.

Synthèse

Mode Canal email Crypto utilisateur Cible
Full Aucun Passphrase diceware EFF + HMAC Nouveaux projets
Lite Conservé Mot mémorisé + HMAC Applications existantes

SelfRecover vs Keycloak Recovery Codes

Lors de la relecture de cette dépêche, devnewton a soulevé une question importante : quelle est la différence avec les Recovery Codes de Keycloak ?

Keycloak est l'IAM (Identity and Access Management) open-source de référence, maintenu par Red Hat sous licence Apache 2.0, déployé dans de nombreuses organisations depuis plus d'une décennie. Son mécanisme de Recovery Codes est un fallback d'authentification à deux facteurs : si l'utilisateur perd son téléphone TOTP, il peut saisir un code de secours préalablement généré côté serveur.

Note importante de positionnement : les Recovery Codes Keycloak adressent le cas « j'ai perdu mon 2FA mais je connais toujours mon mot de passe principal ». Le password reset principal de Keycloak utilise, lui, le canal email standard (configuration SMTP dans l'onglet Email de l'admin console).

SelfRecover s'attaque à un cas différent : « j'ai oublié mon mot de passe principal et je ne veux pas dépendre de l'email pour le récupérer ». Concrètement :

Aspect Keycloak Recovery Codes SelfRecover
Cible Fallback 2FA Password recovery sans email
Architecture Serveur IAM standalone (Java + BDD + admin) Bibliothèque à intégrer dans le code de l'application
Source du secret Serveur génère, utilisateur sauvegarde Utilisateur génère/mémorise (diceware ou mot mémorisé)
Stockage utilisateur Codes à sauvegarder physiquement Passphrase mémorisable (mode Full) ou mot mémorisé (mode Lite)
Email reset principal Reste nécessaire (SMTP configuré dans l'admin) Aucun (mode Full) ou en complément (mode Lite)
Anti-phishing crypto Pas spécifique au mécanisme Dérivation HMAC par domaine : un secret capturé sur un site est mathématiquement inutilisable ailleurs
Licence Apache 2.0 AGPL-3.0-or-later
Maturité 10+ ans, audité, déployé largement Récent, audit communautaire bienvenu

Pour la majorité des projets qui acceptent l'email comme canal de récupération, Keycloak (et son écosystème) reste le bon choix. SelfRecover s'adresse aux applications qui veulent réduire ou supprimer leur dépendance à SMTP, et qui n'ont pas besoin de la richesse d'un IAM complet (multi-realm, OIDC/SAML, fédération d'identité, etc.).

Que se passe-t-il si l'utilisateur perd son secret ?

C'est la question critique d'un protocole de récupération. SelfRecover y répond par escalade progressive sur trois niveaux, complétée par un système de litiges et un chat administrateur pour les cas extrêmes.

Niveau 1 — Passphrase oubliée

L'utilisateur saisit son username + sa passphrase diceware (match exact). Sur succès, un nouveau mot de passe est généré et affiché une seule fois. Anti-brute force : 3 tentatives par 15 minutes, 3 blocages successifs → éjection vers L2.

Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus

L'utilisateur saisit son identifiant public (numéro client, identifiant métier — fourni par le site) et son mot de récupération dérivé HMAC-SHA256 côté navigateur. 3 tentatives maximum avec compteur visible. Sur 3 échecs → redirection vers L3. Un litige est automatiquement créé (LIT-XXXX), tracé en base, admin notifié. Les litiges auto-résolus sont purgés après 24 heures.

Niveau 3 — Accès complètement perdu

Entrée par un lien discret « accès perdu » sur la page de connexion. L'utilisateur saisit son identifiant public en premier (anti-timing : délai forcé de 2 à 3 secondes), puis remplit un formulaire de scoring multi-facteur :

Catégorie Champs Points
Identifiant public 4 20
Mot de récupération (dérivé HMAC) 5 25
Username 3 30
Passphrase (fragments) 3 25

Bonus passifs : IP connue (+5), fingerprint connu (+5).

  • Score ≥ 60/100 → compte récupéré, nouveau mot de passe généré
  • Score < 60/100 après 3 tentatives → le compte passe en mode restreint : l'utilisateur n'a plus accès qu'au chat administrateur, le compte n'est ni utilisable ni écrasable tant que l'admin n'a pas validé
  • Cooldown : 1 heure entre tentatives

Chat administrateur humain en mode restreint — état actuel

Dans l'implémentation actuelle (déployée en production sur ARC PVE Hub), le chat L3 est un canal direct entre l'utilisateur en mode restreint et un administrateur humain du site. Pas d'intermédiaire automatisé, pas de bot.

Le canal de chat est bidirectionnel et fonctionne en polling (pas WebSocket temps réel, pour rester simple). L'admin vérifie l'identité par l'échange et décide manuellement :

Accorder la récupération : mot de passe régénéré, compteurs réinitialisés, litige clôturé, mode restreint levé.

Refuser la récupération : ban temporaire de 24 heures, pas de nouveau litige possible pendant cette fenêtre, compteur de refus incrémenté (1/3, 2/3, 3/3). À chaque clic, l'interface admin rappelle explicitement les conséquences via une modale de confirmation (ban 24h aux refus 1 et 2, suppression définitive au 3e refus).

Au 3e refus, le compte est définitivement supprimé : décision exclusivement humaine, prise en pleine connaissance de cause par l'admin via la modale d'avertissement explicite. La suppression libère l'identifiant public pour une nouvelle inscription.

Principe de design MySelf : aucune destruction de données utilisateur n'est déclenchée sans validation humaine consciente. L'interface admin explicite systématiquement les conséquences avant chaque action irréversible. Une IA peut se tromper ou être manipulée ; lui déléguer la décision de supprimer un compte créerait une surface d'attaque.

Ce mécanisme empêche un attaquant de spammer les litiges indéfiniment : chaque refus lui coûte 24 h, et trois échecs effacent toute trace. Un propriétaire légitime bloqué par erreur peut retenter après chaque fenêtre de ban, ou se réinscrire depuis zéro si totalement verrouillé.

Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local

En complément du chat admin humain (qui resterait toujours disponible), une couche de pré-traitement par un agent conversationnel local (Ollama auto-hébergé) est en cours de design. Le chatbot poserait les questions initiales de vérification d'identité et estimerait si la demande est légitime. Sur estimation positive, le mot de passe serait régénéré directement ; sur doute, l'admin humain reprendrait la main.

Cette option serait configurable par site qui déploie (activable ou non), et le chatbot ne se substituerait jamais à l'admin pour les décisions destructives (suppression de compte) — ces décisions resteraient exclusivement humaines, conformément au principe MySelf énoncé plus haut.

L'enjeu principal en cours de réflexion : calibrer le seuil de confiance du chatbot pour ne pas créer un nouveau vecteur d'attaque par social engineering (un attaquant pourrait essayer de manipuler le LLM par prompts).

Démo standalone vs implémentation de référence

La démo publique (bi-self.my-self.fr/selfrecover/) ne couvre que les niveaux L1 et L2, car L3 nécessite une interface admin, un système de disputes et un dashboard — trop pour une démo à page unique.

L'implémentation de référence en production se trouve sur ARC PVE Hub, un site communautaire de joueurs ARC RAIDERS qui sert de terrain de test à l'écosystème MySelf. L1 + L2 + L3 + mode restreint + chat admin + dispute system y sont fonctionnels.

Pourquoi assumer cette friction

Dans la vie réelle, si l'on perd sa carte bancaire, son code, sa pièce d'identité, son adresse et sa date de naissance, on ne récupère pas son compte bancaire par email. On passe en agence avec preuve d'identité.

SelfRecover applique la même logique en ligne : la sécurité réelle nécessite parfois un passage par l'humain ou un processus d'identification rigoureux. Cette friction est assumée comme un trade-off conscient, pas comme une limitation à compenser.

Pour quel public

Adapté :
- Applications avec un administrateur actif et disponible pour traiter les litiges (forum communautaire, association, e-commerce indépendant, boutique en ligne militante)
- Sites où la sécurité prime sur la fluidité de récupération (services manipulant des données sensibles)
- Communautés à taille humaine (du forum de 50 membres au service de quelques milliers d'utilisateurs)

Non adapté :
- Plateformes à très grande échelle sans admin individuel (réseaux sociaux massifs, services publics avec millions d'utilisateurs) — le volume de litiges dépasse les capacités d'un humain réactif
- Services où une friction de récupération est inacceptable (gaming compétitif, services temps-réel)
- Projets sans maintenance active (l'admin doit pouvoir répondre aux litiges dans des délais raisonnables)

Pour ces cas, un IAM mature comme Keycloak avec ses mécanismes éprouvés reste plus adapté.

Modèle de menace assumé

Pour la transparence, voici les classes d'adversaires explicitement hors périmètre du protocole :

  • Compromission du poste utilisateur (logiciels malveillants, RAT, keyloggers) — un attaquant qui contrôle le poste peut capturer la passphrase à la saisie, indépendamment du protocole.
  • Compromission du navigateur (extensions malveillantes, exploits 0-day) — même cause, même effet : si le moteur JS qui calcule HMAC est compromis, la sortie l'est aussi.
  • Coercition physique — SelfRecover n'offre pas de plausible deniability (pas de second compte caché ou décoy).
  • Cryptanalyse théorique de SHA-256 / HMAC / Argon2id — un cassage mathématique de ces primitives mettrait à mal la quasi-totalité des systèmes cryptographiques modernes, pas seulement SelfRecover.

Ces limitations sont le périmètre normal d'un protocole côté navigateur. Pour les usages à plus haute exigence (cérémonies cryptographiques sensibles, génération initiale de clé maître), MySelf-Live est annoncé dans la roadmap V0.2 : une distribution Linux Live USB minimale, RAM-only, signée GPG, qui isolerait les opérations sensibles du système hôte. Pour les usages courants à fort enjeu, Tails ou Qubes OS offrent déjà ce niveau d'isolation et sont recommandés.

Démos en ligne

Aucune inscription préalable n'est requise. Les données sont éphémères côté serveur.

Code et image Docker

docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1

La démo de référence tourne sur PHP 8.0+ et SQLite (~600 lignes auditables, zéro dépendance externe). Tag GPG-signé v0.1.1, release datée du 5 mai 2026.

Licence et philosophie

AGPL-3.0-or-later. Toute version déployée publiquement doit publier ses modifications sous la même licence. Pas de capture SaaS possible.

SelfRecover est une brique du méta-projet MySelf, un écosystème de modules auto-hébergés qui couvre l'identité, la modération communautaire, le droit, et l'agriculture.

Un module complémentaire répond de manière directe à la problématique illustrée par l'incident ANTS : SelfDataGuard chiffre les données utilisateur côté client de telle sorte qu'une fuite de base de données ne livre que des blobs inexploitables. Le code est public, AGPL, en v0.1.0-beta — une dépêche dédiée pourra suivre quand le module aura plus de maturité (audit communautaire, retours d'intégration).

Note de transparence

Conception en partenariat avec un assistant IA

Ce protocole a été conçu et codé en partenariat avec un assistant IA (Claude), comme outil de réflexion, de revue critique, et d'écriture de code.

Pour être totalement transparent : je ne suis pas développeur de formation. Mon expérience technique vient du dev web amateur (ARC PVE Hub, un site destiné à fédérer une communauté de joueurs ; un outil de gestion de stock pour mon entreprise ; quelques sites perso). Pour SelfRecover, l'écriture des primitives cryptographiques et la mise en œuvre du protocole ont été largement assistées par l'IA, sur la base de mes choix architecturaux et de ma vision.

Ce qui vient de moi (humain) :
- La vision (souveraineté numérique, refus du SMTP comme canal de récupération)
- Les choix philosophiques (AGPL-3.0-or-later, fallback humain assumé, aucune destruction de données sans validation humaine consciente)
- Le contexte initial (besoin né en développant ARC PVE Hub)
- Chaque décision de trade-off d'architecture
- La responsabilité juridique et morale du code publié sous mon nom et signé GPG

Ce qui vient de l'IA :
- L'écriture des primitives cryptographiques (HMAC, dérivations, vérifications)
- L'agencement du code, la structure des fichiers
- La formalisation des paragraphes du whitepaper et de cette dépêche
- La génération de tests unitaires
- La vérification de cohérence interne

Plan d'audit

  • Auto-audit interne : en cours et continu (chaque modification est relue critiquement)
  • Audit communautaire : ouvert dès maintenant, je réponds aux remarques techniques avec sérieux (cette dépêche en est l'illustration directe)
  • Audit tiers certifié : envisagé à moyen terme via un cabinet agréé CESTI ANSSI (Synacktiv, Quarkslab, Wavestone, ou équivalent), sous réserve de financement

Statut du projet

SelfRecover en est à la version 0.1.1, taguée GPG et signée. C'est un état PoC fonctionnel + déployé en production sur un site réel (ARC PVE Hub), mais pas encore mature pour une adoption massive dans des contextes à fort enjeu. La roadmap V0.2 (MySelf-Live, finalisation du chatbot L3, audit tiers) précisera ce périmètre.

Engagement communauté LinuxFr et culture du libre

Mon compte LinuxFr est récent, mais mon ancrage dans la culture du libre ne l'est pas : utilisateur exclusif de distributions Linux depuis quinze ans (principalement Debian), j'ai aidé plusieurs proches à migrer des PC anciens vers Debian pour leur donner une seconde vie au lieu de la déchèterie. J'arrive sur LinuxFr depuis le monde agricole/permaculture et le jeu vidéo (ARC PVE Hub), pas du milieu dev historique.

Je suis salarié couvreur dans une PME et installé en agriculture à temps partiel — mon temps libre pour le développement et la participation communautaire est compté. Je m'engage à répondre aux retours techniques sur cette dépêche et à suivre les disputes sur l'état du projet. Pour le reste (commentaires réguliers, dépêches futures sur d'autres modules MySelf — en particulier SelfDataGuard quand il sera plus mature), ce sera au gré du temps disponible, sans promesse.

Toute critique technique constructive est bienvenue. Pour les critiques sur la légitimité du projet ou la nature humain/IA de la collaboration, j'invite à juger sur les choix concrets, le code public, et la qualité des réponses à vos questions.

Pour aller plus loin

SelfRecover est un module de l'écosystème MySelf, expérimentation citoyenne sur la souveraineté numérique sous licence AGPL-3.0-or-later.

Les retours techniques, audits communautaires, propositions d'intégration et questions de fond sont les bienvenus — en commentaire de cette dépêche ou en issue sur le repo GitHub.

Si une administration ou une organisation souhaite tester le protocole en environnement isolé, l'image Docker et le Dockerfile sont à disposition. Aucune démarche commerciale n'est associée à cette publication.

Merci aux modérateurs et contributeurs de LinuxFr — Pierre Jarillon, devnewton, Florent Zara, bobble bubble — dont les retours pendant la phase de rédaction ont substantiellement amélioré cette dépêche.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Sur le front, les militaires états-uniens ciblés grâce aux données de tracking commercial

À malin, malin ennemi ?
Sur le front, les militaires états-uniens ciblés grâce aux données de tracking commercial

Le département de la Défense états-unien l’a confirmé : des militaires de son armée ont bien été ciblés en utilisant des données de géolocalisation obtenues via des courtiers de données.

Ça devait arriver. Sur le front, les militaires peuvent être ciblés avec l’utilisation de données obtenues par des courtiers en données qui les revendent sans se soucier de leur utilisation.

Le Commandement central des États-Unis (USCENTCOM), qui dépend du département de la Défense états-unien (DoD), a confirmé au sénateur démocrate de l’Oregon, Ron Wyden, qu’il « a reçu plusieurs signalements de menaces concernant l’exploitation par des adversaires de données de localisation commerciales afin de cibler ou de surveiller le personnel américain sur le terrain », révèle Reuters.

Dans cette lettre [PDF], l’USCENTCOM assure enjoindre « au personnel de désactiver la fonctionnalité de géolocalisation lorsqu’elle n’est pas nécessaire, de vérifier régulièrement les paramètres de confidentialité des appareils et des applications, et de limiter le partage public d’informations ».

Elle ajoute que « ces directives soulignent que la désactivation des fonctions de géolocalisation ne les rend pas toujours totalement inopérantes sur les produits commerciaux, ce qui oblige le personnel à mettre en œuvre des mesures de sécurité complètes pour les appareils, notamment la vérification des paramètres de confidentialité » et qu’elle impose « les contrôles de géolocalisation les plus restrictifs » à ses troupes engagées au Moyen-Orient depuis le 28 février dernier.

La question du tracking des militaires américains soulevée par des élus

Dans un courrier [PDF] envoyé au DoD, Ron Wyden et 13 autres sénateurs et membres du Congrès des États-Unis s’inquiètent qu’il « n’ait pas pris les mesures élémentaires nécessaires pour protéger le personnel militaire américain contre la grave menace que représentent, en matière de contre-espionnage et de protection des forces, la collecte et la vente de données personnelles, notamment les données de localisation des téléphones portables, par des courtiers en données » et l’accusent de ne pas avoir « mis en place les mesures de cyberdéfense de bon sens recommandées par les agences fédérales ».

« Les données de localisation à des fins commerciales peuvent servir à identifier les lieux où se rassemblent les troupes américaines ainsi que leurs habitudes de vie, informations que des adversaires pourraient exploiter pour mener des attaques ciblées, notamment à l’aide de missiles, de drones et de bombes placées en bord de route, ou à des fins de contre-espionnage », détaillent-ils. À Reuters, Ron Wyden a déclaré qu’il était temps de « commencer à considérer le secteur des technologies publicitaires comme une menace pour la sécurité nationale ».

Un tracking utilisé par les États-Unis depuis 2016

On sait pourtant depuis quelques années que les données des applications commerciales peuvent être utilisées pour localiser des personnes, et donc que l’identifiant publicitaire est une information très sensible qui doit être cachée au maximum d’éventuels ennemis. Ainsi, les données laissées par l’utilisation de Strava permettent de remonter la piste de personnes comme des agents des renseignements.

Les États-Unis ne sont pas en reste pour la récolte de ce genre de données qui sont, au départ, utilisées pour le tracking publicitaire. On sait que l’ICE, leur service de l’immigration et des douanes, s’est confectionné un vaste jeu de données publiques et privées, achetées aussi bien auprès des géants numériques, de courtiers comme Thomson Reuters ou LexisNexis, que du gouvernement américain. Et les systèmes d’analyse et données collectées par Palantir sont utilisées par l’armée américaine, l’armée israélienne, l’OTAN ou encore la DGSI française pour améliorer leur ciblage sur le terrain.

Dans un article publié ce mardi 26 mai, le Wall Street Journal explique que le DoD a été informé par son sous-traitant PlanetRisk dès 2016 que ses employés avaient découvert qu’ils pouvaient suivre les opérations militaires américaines grâce à ce genre de données venant des smartphones des soldats américains.

Selon les sources de nos confrères, PlanetRisk était à l’époque en train de mettre au point un outil de surveillance pour suivre les réfugiés syriens qui fuyaient vers l’Europe et les États-Unis dans l’espoir de le vendre aux gouvernements de ces pays.

Pour cela, elle utilisait notamment des données de tracking provenant d’applications de météo, de jeux ou de rencontres. Dans les données collectées, l’entreprise a remarqué des données faisant le lien entre des bases militaires et une cimenterie syrienne, qui jusque-là n’était pas connue pour servir de zone de rassemblement des forces états-uniennes et leurs alliés.

PlanetRisk a ensuite aidé le Pentagone à utiliser les données de tracking jusqu’à lui permettre de surveiller les téléphones des membres de l’entourage du président russe Vladimir Poutine, comme le racontait Wired.

  •  

Sur le front, les militaires états-uniens ciblés grâce aux données de tracking commercial

À malin, malin ennemi ?
Sur le front, les militaires états-uniens ciblés grâce aux données de tracking commercial

Le département de la Défense états-unien l’a confirmé : des militaires de son armée ont bien été ciblés en utilisant des données de géolocalisation obtenues via des courtiers de données.

Ça devait arriver. Sur le front, les militaires peuvent être ciblés avec l’utilisation de données obtenues par des courtiers en données qui les revendent sans se soucier de leur utilisation.

Le Commandement central des États-Unis (USCENTCOM), qui dépend du département de la Défense états-unien (DoD), a confirmé au sénateur démocrate de l’Oregon, Ron Wyden, qu’il « a reçu plusieurs signalements de menaces concernant l’exploitation par des adversaires de données de localisation commerciales afin de cibler ou de surveiller le personnel américain sur le terrain », révèle Reuters.

Dans cette lettre [PDF], l’USCENTCOM assure enjoindre « au personnel de désactiver la fonctionnalité de géolocalisation lorsqu’elle n’est pas nécessaire, de vérifier régulièrement les paramètres de confidentialité des appareils et des applications, et de limiter le partage public d’informations ».

Elle ajoute que « ces directives soulignent que la désactivation des fonctions de géolocalisation ne les rend pas toujours totalement inopérantes sur les produits commerciaux, ce qui oblige le personnel à mettre en œuvre des mesures de sécurité complètes pour les appareils, notamment la vérification des paramètres de confidentialité » et qu’elle impose « les contrôles de géolocalisation les plus restrictifs » à ses troupes engagées au Moyen-Orient depuis le 28 février dernier.

La question du tracking des militaires américains soulevée par des élus

Dans un courrier [PDF] envoyé au DoD, Ron Wyden et 13 autres sénateurs et membres du Congrès des États-Unis s’inquiètent qu’il « n’ait pas pris les mesures élémentaires nécessaires pour protéger le personnel militaire américain contre la grave menace que représentent, en matière de contre-espionnage et de protection des forces, la collecte et la vente de données personnelles, notamment les données de localisation des téléphones portables, par des courtiers en données » et l’accusent de ne pas avoir « mis en place les mesures de cyberdéfense de bon sens recommandées par les agences fédérales ».

« Les données de localisation à des fins commerciales peuvent servir à identifier les lieux où se rassemblent les troupes américaines ainsi que leurs habitudes de vie, informations que des adversaires pourraient exploiter pour mener des attaques ciblées, notamment à l’aide de missiles, de drones et de bombes placées en bord de route, ou à des fins de contre-espionnage », détaillent-ils. À Reuters, Ron Wyden a déclaré qu’il était temps de « commencer à considérer le secteur des technologies publicitaires comme une menace pour la sécurité nationale ».

Un tracking utilisé par les États-Unis depuis 2016

On sait pourtant depuis quelques années que les données des applications commerciales peuvent être utilisées pour localiser des personnes, et donc que l’identifiant publicitaire est une information très sensible qui doit être cachée au maximum d’éventuels ennemis. Ainsi, les données laissées par l’utilisation de Strava permettent de remonter la piste de personnes comme des agents des renseignements.

Les États-Unis ne sont pas en reste pour la récolte de ce genre de données qui sont, au départ, utilisées pour le tracking publicitaire. On sait que l’ICE, leur service de l’immigration et des douanes, s’est confectionné un vaste jeu de données publiques et privées, achetées aussi bien auprès des géants numériques, de courtiers comme Thomson Reuters ou LexisNexis, que du gouvernement américain. Et les systèmes d’analyse et données collectées par Palantir sont utilisées par l’armée américaine, l’armée israélienne, l’OTAN ou encore la DGSI française pour améliorer leur ciblage sur le terrain.

Dans un article publié ce mardi 26 mai, le Wall Street Journal explique que le DoD a été informé par son sous-traitant PlanetRisk dès 2016 que ses employés avaient découvert qu’ils pouvaient suivre les opérations militaires américaines grâce à ce genre de données venant des smartphones des soldats américains.

Selon les sources de nos confrères, PlanetRisk était à l’époque en train de mettre au point un outil de surveillance pour suivre les réfugiés syriens qui fuyaient vers l’Europe et les États-Unis dans l’espoir de le vendre aux gouvernements de ces pays.

Pour cela, elle utilisait notamment des données de tracking provenant d’applications de météo, de jeux ou de rencontres. Dans les données collectées, l’entreprise a remarqué des données faisant le lien entre des bases militaires et une cimenterie syrienne, qui jusque-là n’était pas connue pour servir de zone de rassemblement des forces états-uniennes et leurs alliés.

PlanetRisk a ensuite aidé le Pentagone à utiliser les données de tracking jusqu’à lui permettre de surveiller les téléphones des membres de l’entourage du président russe Vladimir Poutine, comme le racontait Wired.

  •  

#Nextquick : 500 cyberattaques ou 55 milliards, c’est parfois la même chose, pourquoi ?

Selon la police vs selon les pirates
#Nextquick : 500 cyberattaques ou 55 milliards, c’est parfois la même chose, pourquoi ?

500 cyberattaques pendant les Jeux olympiques selon l’ANSSI, 55 milliards selon le CIO : les chiffres n’ont rien à voir, et pourtant ils comptent bien la même chose. Cela parait absurde, mais non : c’est une question de référentiel (et de message à faire passer). On retrouve le même problème avec les fuites de données.

Depuis maintenant des années, la France est régulièrement victime de cyberattaques, que ce soit sur ses institutions ou ses entreprises. Il en résulte parfois des fuites de données, avec plus ou moins d’écho dans la presse et sur les réseaux sociaux.

Une question revient assez souvent : la France est-elle plus attaquée que les autres pays ? Pour Vincent Strubel, patron de l’ANSSI, auditionné par la Commission de la défense de l’Assemblée nationale, la réponse est simple : « On n’en sait rien » car « personne ne sait compter de manière fiable et homogène les cyberattaques ». Partant de là, difficile en effet d’établir un classement.

500 ou 55 000 000 000 cyberattaques ? c’est pareil !

Il cite un exemple récent avec le cas des Jeux olympiques de Paris en 2024. L’ANSSI avait compté à peu près 500 cyberattaques pendant cette période. Le Comité international olympique (CIO), en charge d’organiser les jeux, en avait compté 55 milliards. Un rapport de 1 à 100 000 000 (100 millions), excusez du peu !


Il reste 71% de l'article à découvrir.
Vous devez être abonné•e pour lire la suite de cet article.
Déjà abonné•e ? Générez une clé RSS dans votre profil.

  •  

« Bad Host » : comment un outil méconnu a exposé des millions d’agents IA à des accès non autorisés

Une faille dans Starlette, un framework Python que la plupart des développeurs n'ont jamais installé consciemment, a exposé des millions de serveurs d'agents IA à des accès non autorisés. Des boîtes mail, des bases de données médicales et des équipements industriels étaient accessibles sans mot de passe.

  •  

☕️ Face aux vols à l’arraché, Apple prépare un nouvel antivol pour l’iPhone



Face à des voleurs à la tire toujours mieux organisés, les constructeurs de smartphones multiplient les systèmes de protection. Apple planche ainsi sur une nouvelle fonction antivol qui combine plusieurs signaux de l’iPhone et met à contribution l’Apple Watch.

Selon du code analysé par le site 9to5Mac, une nouvelle fonctionnalité antivol pourrait apparaître sous peu pour les iPhone. Elle se base sur plusieurs signaux, à commencer par l’analyse de l’accéléromètre : un smartphone arraché des mains de son propriétaire provoque des mouvements inattendus du capteur. L’appareil pourrait alors se verrouiller automatiquement.

L’antivol pourra aussi prendre en compte la distance entre l’iPhone et l’Apple Watch associée. La fonction vérifiera également si le smartphone est connecté à un réseau Wi-Fi connu, comme à la maison ou au bureau. Si les informations renvoyés par ces signaux sont suspects, elles pourront provoquer le verrouillage de l’iPhone. On ignore quand la fonctionnalité sera activée, mais elle est en développement.

Tout cela n’est pas inédit. Google propose un système de verrouillage en cas de détection de vol très similaire pour les smartphones Android : « si quelqu’un vous arrache le téléphone des mains et s’en va en courant, à vélo ou en voiture, le verrouillage en cas de détection de vol peut s’activer. » Personne ne s’offusquera que dans le domaine des antivols, Apple et Google s’inspirent l’un l’autre.

Un iPhone peut exiger un délai pour modifier les réglages de sécurité quand l’appareil ne se trouve pas dans un lieu connu.

Au fil des années, les deux constructeurs ont mis au point de nombreux systèmes de protection des données en cas de vol (ici chez Apple, chez Google). Tous ces dispositifs rendent très difficile la revente de smartphones verrouillés. Si les margoulins peuvent toujours les démonter pour récupérer des composants, plusieurs d’entre eux sont liés matériellement ou logiciellement à l’appareil, ce qui en réduit fortement la valeur sur le marché parallèle.

C’est pourquoi les smartphones déverrouillés sont devenus une prise de choix pour les voleurs. D’où la nécessité de trouver des mécanismes antivol dans ce cas précis.

Le New York Times rapportait récemment la nouvelle tactique extrêmement agressive des voleurs de smartphones à Londres. Les victimes ou leurs proches reçoivent des messages de plus en plus menaçants pour les pousser à désactiver les iPhone volés de leur compte Apple. Des escrocs envoient même des vidéos d’hommes armés et des menaces de mort (!) pour tenter d’obtenir le déverrouillage complet de l’appareil.

  •  

☕️ Face aux vols à l’arraché, Apple prépare un nouvel antivol pour l’iPhone



Face à des voleurs à la tire toujours mieux organisés, les constructeurs de smartphones multiplient les systèmes de protection. Apple planche ainsi sur une nouvelle fonction antivol qui combine plusieurs signaux de l’iPhone et met à contribution l’Apple Watch.

Selon du code analysé par le site 9to5Mac, une nouvelle fonctionnalité antivol pourrait apparaître sous peu pour les iPhone. Elle se base sur plusieurs signaux, à commencer par l’analyse de l’accéléromètre : un smartphone arraché des mains de son propriétaire provoque des mouvements inattendus du capteur. L’appareil pourrait alors se verrouiller automatiquement.

L’antivol pourra aussi prendre en compte la distance entre l’iPhone et l’Apple Watch associée. La fonction vérifiera également si le smartphone est connecté à un réseau Wi-Fi connu, comme à la maison ou au bureau. Si les informations renvoyés par ces signaux sont suspects, elles pourront provoquer le verrouillage de l’iPhone. On ignore quand la fonctionnalité sera activée, mais elle est en développement.

Tout cela n’est pas inédit. Google propose un système de verrouillage en cas de détection de vol très similaire pour les smartphones Android : « si quelqu’un vous arrache le téléphone des mains et s’en va en courant, à vélo ou en voiture, le verrouillage en cas de détection de vol peut s’activer. » Personne ne s’offusquera que dans le domaine des antivols, Apple et Google s’inspirent l’un l’autre.

Un iPhone peut exiger un délai pour modifier les réglages de sécurité quand l’appareil ne se trouve pas dans un lieu connu.

Au fil des années, les deux constructeurs ont mis au point de nombreux systèmes de protection des données en cas de vol (ici chez Apple, chez Google). Tous ces dispositifs rendent très difficile la revente de smartphones verrouillés. Si les margoulins peuvent toujours les démonter pour récupérer des composants, plusieurs d’entre eux sont liés matériellement ou logiciellement à l’appareil, ce qui en réduit fortement la valeur sur le marché parallèle.

C’est pourquoi les smartphones déverrouillés sont devenus une prise de choix pour les voleurs. D’où la nécessité de trouver des mécanismes antivol dans ce cas précis.

Le New York Times rapportait récemment la nouvelle tactique extrêmement agressive des voleurs de smartphones à Londres. Les victimes ou leurs proches reçoivent des messages de plus en plus menaçants pour les pousser à désactiver les iPhone volés de leur compte Apple. Des escrocs envoient même des vidéos d’hommes armés et des menaces de mort (!) pour tenter d’obtenir le déverrouillage complet de l’appareil.

  •  

L’Union européenne verrouille ses fréquences satellites face à Starlink et Amazon

La bataille en basse orbite
L’Union européenne verrouille ses fréquences satellites face à Starlink et Amazon

Nouvelle bataille en vue pour la domination des cieux européens. La Commission a officiellement confirmé sa volonté de prendre la main sur une partie importante des fréquences satellites, avec un objectif politique assumé : celui de la souveraineté technologique face à la Chine et surtout aux États-Unis.

Bruxelles entend gérer les attributions de la bande 2 GHz MSS, qui correspond aux fréquences utilisées par les services de satellites mobiles. Comme le rappelle Euronews, ces fréquences ont été attribuées en 2009 à deux opérateurs européens, Viasat et EchoStar. Leur usage est limité (notamment aux appels d’urgence dans une zone blanche), mais la Commission veut les exploiter pour autoriser la connexion directe entre un satellite et un smartphone (« Direct to Device », D2D). Cette bande a aussi des utilisations militaires et gouvernementales.

En attendant IRIS²

La Commission a adopté une proposition qui lui permettra, au renouvellement des fréquences de cette bande (à partir de mai 2027), d’attribuer au niveau européen des autorisations de licence jusque-là largement gérées par les États membres. Ce qui pouvait poser un problème d’harmonisation entre pays. Les opérateurs pourront ainsi lancer leurs services à l’échelle de l’Union européenne, sans devoir négocier avec chaque capitale… même si les États conservent une certaine marge de manœuvre en imposant leurs obligations techniques et des règles de sécurité.

La législation sur les réseaux numériques (ADN), qui repose sur le Code des communications électroniques de l’UE de 2018, a été adoptée le 21 janvier dernier. Elle contient, entre autres, un volet sur « l’harmonisation juridique maximale » visant à faciliter les opérations et la fourniture de services paneuropéens. Parmi les mesures : une autorisation de spectre satellitaire au niveau de l’UE.

Dans le détail, la Commission a décidé de couper en trois la poire de la bande. Le premier tiers est réservé aux usages gouvernementaux et militaires européens, pour les communications critiques et pour s’assurer de la sécurité de ces communications. Ce morceau de fréquences devra être exploité par un opérateur européen et intégré au programme IRIS², la constellation de satellites de l’UE.

À l’origine, le « Starlink » européen devait être opérationnel d’ici 2027. Même si le programme recycle des infrastructures existantes, IRIS² sera plus long à s’élever dans les airs : aux dernières nouvelles (qui remontent au mois de février), ce projet en est toujours dans sa phase de conception et de développement, et cela jusqu’en 2028. Le déploiement est programmé de 2029 à 2030, et l’exploitation entre 2030 et 2037. La pleine capacité opérationnelle est désormais prévue d’ici 2030.

La menace américaine

Voilà pour le premier tiers. Les deux autres tiers seront dévolus aux usages commerciaux : connectivité satellite pour smartphones, objets connectés et services d’urgence. Mais Bruxelles a une idée assez claire des opérateurs qui pourront candidater : la moitié des fréquences est ainsi réservée aux acteurs européens, l’autre moitié est ouverte aux entreprises européennes et non européennes.

On l’aura compris, il s’agit de favoriser l’émergence de fournisseurs européens, tandis que les champions américains (SpaceX, Amazon Leo) auront la portion congrue au nom de la souveraineté. « Plus que jamais, une connectivité satellitaire à haute capacité et largement disponible est essentielle pour renforcer la résilience des réseaux de communication de l’Union européenne », explique Henna Virkkunen, vice-présidente de la Commission chargée de la souveraineté technologique.

Ces infrastructures satellitaires, considérées comme critiques par Bruxelles, sont devenues un enjeu de sécurité pour l’Europe. Le poids lourd américain Starlink, avec sa constellation d’environ 10 000 satellites en basse orbite et ses services d’accès internet et de téléphonie D2D, est devenu essentiel à l’effort de guerre en Ukraine… mais l’entreprise d’Elon Musk reste soumise aux lois américaines sur l’exploitation des données de ses utilisateurs (Cloud Act, FISA).

C’est le cas aussi d’Amazon Leo (anciennement Kuiper), qui s’est d’ailleurs offert récemment Globalstar. Ces deux sociétés doivent aussi composer avec la pression, toujours possible, de la Maison Blanche, dans un contexte de très fortes tensions transatlantiques.

Brendan Carr, le très trumpiste président de la Commission aux communications fédérales (FCC), avait mis en garde l’UE lors de sa visite au salon MWC de Barcelone, au mois de mars. « L’Europe dispose de fournisseurs satellitaires nationaux champions qui réalisent une activité importante aux États-Unis », menaçait-il. « Si l’Europe persiste à suivre une voie de souveraineté satellitaire excluant les fournisseurs qui ne sont pas basés sur le continent, alors les États-Unis devront en tenir compte concernant le traitement réciproque que nous accordons. » Ambiance.

Cette décision de la Commission devrait en tout cas booster les acteurs européens, à l’image d’Eutelsat et de sa constellation OneWeb LEO (600 satellites en basse orbite) combinée à des satellites géostationnaires. Eutelsat fait également partie du consortium SpaceRISE chargé de la mise en œuvre d’IRIS².

  •  
❌