Vue lecture

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

Pocket ID - L'auth par passkey pour votre homelab

Si vous auto-hébergez déjà des services chez vous, y'a un truc qui revient tout le temps c'est l'authentification. Chaque app a son propre login, ses propres mots de passe, et du coup vous finissez avec une ribambelle de comptes différents pour des trucs qui tournent sur le même serveur. Nextcloud par-ci, Jellyfin par-là, Gitea en prime... C'est con hein, mais c'est comme ça !

Pocket ID , c'est un provider OpenID Connect (OIDC) qui fait UNE chose et qui la fait bien : vous authentifier avec vos passkeys. Pas de mot de passe, pas de TOTP, pas de SMS... juste votre empreinte digitale via Touch ID, Face ID, Windows Hello, ou votre clé physique type YubiKey. Le projet tourne en Go côté serveur (un seul binaire de ~15 Mo) et SvelteKit pour l'interface, le tout sous licence BSD-2-Clause.

Bon, vous allez me dire "y'a déjà Keycloak pour ça". Sauf que Keycloak, c'est un monstre. Genre, vous voulez juste centraliser l'auth de votre Nextcloud et de votre Jellyfin, et vous vous retrouvez à configurer 47 fichiers XML. Pocket ID, c'est donc l'inverse... un simple docker compose up -d et hop, c'est lancé sur localhost:1411 ! En fait l'interface web est tellement propre que vous créez vos clients OIDC en 3 clics, plutôt que de passer 2 heures dans la doc.

D'ailleurs, le truc cool c'est la liste des intégrations. Il y a plus de 80 services compatibles, documentés avec des procédures pas à pas : Nextcloud, Immich, Grafana, Portainer, Proxmox, Vaultwarden, GitLab, Jellyfin... en gros tous les classiques du self-hosting. Si vous avez déjà mis en place Authelia pour protéger vos services derrière un reverse proxy , Pocket ID c'est le complément idéal côté SSO.

Attention par contre, y'a un prérequis : HTTPS obligatoire. C'est pas un caprice hein, c'est une contrainte technique de WebAuthn (le standard derrière les passkeys ). Du coup si votre homelab tourne en HTTP sur le réseau local genre http://192.168.1.x ... faudra d'abord passer par un reverse proxy avec certificat TLS. Caddy fait ça carrément bien avec ses certificats Let's Encrypt auto-gérés sur le port 443, c'est même plutôt facile à déployer. Il y a aussi Nginx Proxy Manager qui est génial pour tout ce qui est reverse proxy facile à implémenter !

Ensuite, côté installation, Pocket-ID vous donne le choix : Docker (le plus simple), standalone, Proxmox, Unraid, Kubernetes ou même NixOS.

Y'a aussi un système de groupes d'utilisateurs et des options de suivi pour savoir qui s'est connecté quand, depuis quelle IP. Pas mal hein, pour un outil qui tient dans un conteneur Docker de 50 Mo !

Bon, c'est pas non plus parfait hein. Le fait de n'accepter QUE les passkeys, ça veut dire que si un de vos utilisateurs n'a pas de device compatible (vieux navigateur, OS ancien), il sera coincé. Et si vous perdez votre YubiKey sans avoir enregistré de passkey de secours sur un iPhone ou un Android... bah bon courage. C'est un choix délibéré des devs, mais faut quand même le savoir avant de migrer toute votre infra dessus.

Bref, simple, efficace, et ça fait pas semblant d'être autre chose. Ah et y'a une démo ici pour tester avant de tout casser sur votre serveur ^^.

On a testé Resident Evil 7, 8 et 9 sur Switch 2 : vous n’avez plus besoin d’une PS5

Lorsque Capcom a annoncé que Resident Evil Requiem allait paraître sur Switch 2, les réactions se partageaient entre scepticisme légitime et immense engouement. On craignait une sous-version, du fait de l'impasse faite par l'éditeur japonais sur la PS4 et la Xbox One pour la première fois en six épisodes développés sur son fameux moteur maison, le RE Engine. Alors, que vaut Resident Evil Requiem, notre énorme coup de cœur de ce début d'année sur Switch 2… mais aussi, que valent ses deux prédécesseurs, portés pour l'occasion ?

QRTape - De la musique en QR codes sur papier

Les bandes de papier perforé, ça vous parle ? C'est les trucs qui sortaient des mainframes dans les années 60... Hé bien, y'a un mec qui a décidé de remettre ça au goût du jour, sauf qu'au lieu de petits trous, lui il utilise des QR codes. Et au lieu d'y stocker des données binaires, il y stocke de la musique.

Le projet (un peu old c’est vrai 😜) s'appelle QRTape et le principe c'est que vous prenez un fichier audio, vous le compressez en Opus à 12 kbps (fichier .opus de quelques Ko), vous découpez le résultat en morceaux de 2 331 octets, et chaque morceau devient un QR code imprimé sur un ruban de papier continu.

Une webcam Logitech C920 branchée en USB lit alors les codes un par un sur /dev/video0 pendant qu'un moteur pas-à-pas fait défiler la bande, et hop, ça joue du son !

Le plus beau dans l'histoire, c'est le côté bricolage total car la structure du "magnétophone" est faite en carton, les bobines sont des rouleaux d'essuie-tout avec des embouts en carton, et l'entraînement c'est un élastique (oui, un élastique !). Le moteur NEMA 17 est piloté par un Arduino Uno qui fait défiler 1 à 2 QR codes par seconde devant la caméra. C'est pas une hi-fi, mais ça marche très bien sur un Raspberry Pi 3 !

Côté logiciel, c'est la bibliothèque ZBar (libzbar0 sous Linux) qui décode les QR codes en temps réel. Chaque code contient un identifiant de séquence sur 2 octets, la taille du chunk, les données audio et un checksum CRC16 pour détecter les erreurs. Du coup si un code est illisible (froissé, mal imprimé), le système le skippe et passe au suivant sans couper la lecture.

D'ailleurs, le format choisi c'est du QR version 40, le plus gros possible, avec correction d'erreur moyenne. Ça donne 2 331 octets exploitables par code (le reste étant de la correction d'erreur). Attention par contre, si votre bande de papier se froisse ou prend l'humidité, c'est mort... le CRC16 détecte l'erreur mais ne corrige rien.

Et une fois imprimé, il obtient un morceau de 4 minutes 21 qui tient sur 157 QR codes, soit une bande de papier de quelques mètres.

Si vous aimez ce genre de projets rétro-futuristes, je vous invite à jeter aussi un oeil à QArt Coder qui génère des QR codes artistiques ou encore aux boîtiers Raspberry Pi en cassette audio recyclée . Y'a clairement une communauté de gens qui kiffent mélanger le vintage et le numérique et vous en faites peut-être partie ? !

Après on va pas se mentir, la qualité audio à 12 kbps mono c'est pas non plus du FLAC mais ça reste écoutable. Et le simple fait d'entendre de la musique sortir d'une bande de papier qui défile dans un truc en carton... c'est quand même la classe !

Du coup si vous avez une imprimante à étiquettes et un Arduino qui traîne, vous savez quoi faire ce dimanche.

Claude d'Anthropic a trouvé 22 failles dans Firefox en deux semaines

Anthropic et Mozilla viennent de publier les résultats d'une collaboration menée en février. En deux semaines, le modèle Claude Opus 4.6 a analysé près de 6 000 fichiers C++ du code source de Firefox et découvert 22 vulnérabilités de sécurité, dont 14 classées haute gravité. Toutes sont déjà corrigées dans Firefox 148.

Un chasseur de bugs d'un nouveau genre

C'est l'équipe de red team d'Anthropic qui a contacté Mozilla pour tester son système de détection de failles par IA sur le code source de Firefox. Le modèle Claude Opus 4.6 a d'abord été lâché sur le moteur JavaScript du navigateur, avant d'être étendu au reste de la base de code.

Vingt minutes après le début de l'analyse, il avait déjà identifié sa première faille : un Use After Free, un type de vulnérabilité mémoire qui peut permettre à un attaquant d'écraser des données avec du contenu malveillant. Les ingénieurs de Mozilla ont commencé à appliquer des correctifs dans les heures qui ont suivi.

Au total, Anthropic a soumis 112 rapports de bugs sur la période. Mozilla a souligné que la qualité des rapports a fait la différence : chaque soumission incluait un cas de test minimal, une preuve de concept et un correctif candidat. Claude a même proposé ses propres patchs pour corriger les failles qu'il trouvait.

22 failles dont 14 haute gravité

Sur les 112 rapports, 22 ont donné lieu à des CVE (des identifiants de failles de sécurité officiels), dont 14 classées haute gravité par Mozilla. Pour donner un ordre d'idée, ces 14 failles représentent quasiment un cinquième de toutes les vulnérabilités haute gravité corrigées dans Firefox sur l'ensemble de l'année 2025. Les 90 bugs restants sont de moindre gravité, mais la plupart sont désormais corrigés. Tout est intégré dans Firefox 148, disponible depuis le 24 février.

Firefox n'est pas le seul projet concerné. Anthropic indique avoir utilisé Claude Opus 4.6 pour repérer des vulnérabilités dans d'autres logiciels open source, dont le noyau Linux.

Trouver les failles, mais pas les exploiter

Côté offensif, le constat est quand même rassurant. Anthropic a aussi testé la capacité de Claude à exploiter les failles qu'il trouvait, pas seulement les détecter. L'équipe a dépensé environ 4 000 dollars en crédits API pour tenter de produire des exploits fonctionnels. Sur plusieurs centaines d'essais, seuls deux ont abouti, et encore : uniquement dans un environnement de test où la sandbox de Firefox avait été désactivée. Le modèle est bien meilleur pour trouver les bugs que pour les exploiter, et le coût de détection est dix fois inférieur à celui de l'exploitation.

C’est le genre de résultat qui change un peu la perception de l'IA dans la cybersécurité. On a beaucoup parlé du risque que des modèles comme Claude ou GPT servent à créer des attaques. Et là, c'est l'inverse : l'IA trouve les failles plus vite et pour moins cher que n'importe quel audit traditionnel, mais elle a encore du mal à les exploiter. 

L'avantage est clairement du côté des défenseurs, pour l'instant en tous cas. Mozilla a d'ailleurs annoncé avoir déjà intégré l'analyse assistée par IA dans ses processus de sécurité internes. En tout cas, quand une IA trouve en deux semaines autant de failles critiques qu'un an de recherches classiques, on comprend assez vite que le métier de la cybersécurité va changer.

Sources : Anthropic , Mozilla

❌