Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source

Contrairement à ce que dit Yann Barthès, on n'est pas tous égaux face à la canicule. Et l'autre truc face auquel on n'est pas tous égaux non plus, c'est le déverrouillage biométrique de son ordi. On les connaît les Linuxiens qui regardent avec jalousie leur collègue sous Windows qui déverrouille sa machine d'un simple coup d'œil à la webcam. Eux, ils sont obligés de taper leur mot de passe de 56 caractères et ça leur fout la rage, alors ils vont sur Reddit pour dire du mal de tous ceux qui n'ont pas de restes de frites collés dans la barbe.

Mais je vais apaiser cette haine en vous parlant aujourd'hui de BioPass , un projet open source signé thaitran24 et phucvinh57, deux devs réunis sous la bannière TickLabVN.

Ce qu'ils veulent faire, c'est amener enfin sous Linux l'équivalent de Windows Hello. BioPass vous connecte à votre session, à un sudo ou à tout service qui passe par PAM avec votre visage ET votre empreinte digitale.

Jusqu'ici la référence sur Linux c'était Howdy , qui fait du visage uniquement, en ligne de commande, et que les développeurs eux-mêmes décrivent comme un peu à l'abandon (sur openSUSE le paquet n'est carrément plus maintenu). C'était chiant à configurer en plus, alors que BioPass lui, propose une vraie interface graphique pour gérer tout ça.

Le module qui parle à PAM est écrit en C++17 et fait tourner trois modèles en local via ONNX Runtime : YOLO pour détecter le visage, EdgeFace pour le reconnaître, et MobileNetV3 pour l'anti-spoofing. Les devs ont d'ailleurs viré les grosses dépendances type PyTorch et OpenCV au profit d'ONNX, histoire de garder un truc léger.

Au moment où votre OS réclame une authentification, BioPass le voit et démarre un processus isolé nommé biopass-helper qui s'occupe de la capture de votre minois et de l'inférence derrière pour vous reconnaître.

Et puis surtout, le point qui compte vraiment quand on parle biométrie c'est que tout reste en local. Y'a vraiment aucune empreinte de votre doigt ou cartographie de nos tronches de cakes qui partent faire du tourisme chez AWS ou Azure.

BioPass gère bien la détection de fausse présence avec une caméra infrarouge (supportée depuis la version 1.1), et la dernière mouture exige même que toutes les méthodes anti-spoofing activées valident, mais sans caméra IR, en se reposant sur le seul modèle d'IA, un visage peut potentiellement se laisser amadouer par une photo bien placée.

Ça reste le talon d'Achille classique de la biométrie, et on a déjà vu pire ailleurs, genre Windows Hello dont le visage devenait copiable sur une clé USB , ou ce laptop Dell qu'on déverrouillait avec un oignon , donc prenez-le plutôt comme un outil de confort plutôt que pour quelque chose qui renforce la sécu de votre Linux.

Pour tester, il y a des paquets .deb et .rpm sur les releases GitHub, et un paquet AUR biopass-bin pour les gens sous Arch. Ah et il vous faudra un capteur d'empreintes pour la partie doigt. Une webcam classique suffit pour la reconnaissance faciale, mais sans caméra infrarouge l'anti-spoofing reste encore une fois, fragile donc gardez ça en tête.

Le projet est sous licence MIT, et la prochaine grosse étape annoncée c'est carrément l'authentification vocale.

Vous pensez que les méthodes d’authentification modernes comme FIDO2 vous protègent efficacement contre le vol de cookies et les attaques de l’homme du milieu (MITM) ? Détrompez-vous ! Une équipe de chercheurs vient de démontrer qu’il est possible de contourner ces protections en s’emparant des précieux sésames que sont les jetons de session.

Vous vous connectez tranquillement à votre appli préférée, en scannant votre empreinte digitale ou en insérant votre clé de sécurité dernier cri, vous vous sentez en sécurité, comme un petit bébé dans les bras de sa maman ou de son papa, protégé par la magie de FIDO2 (et de son absence de mots de passe).

Sauf que dans l’ombre, un vilain pirate que nous appellerons Vladimitch, a réussi à s’immiscer entre vous et le serveur, tel un cyber-ninja. Et là, c’est le drame : il intercepte le fameux jeton de session qui vous permet de rester connecté sans avoir à retaper vos identifiants à chaque clic. Ni vu ni connu, il peut alors se faire passer pour vous et accéder à votre compte !

Mais comment est-ce possible avec une authentification si robuste ? Eh bien figurez-vous que le problème ne vient pas de FIDO2 en lui-même, mais plutôt de la façon dont les applications gèrent les sessions après la phase d’authentification. Une fois que vous êtes connecté, c’est open bar, et votre jeton se balade joyeusement sur le réseau, sans trop de protection.

Les chercheurs ont mis en lumière cette faille en testant plusieurs implémentations de FIDO2, comme le bac à sable Yubico Playground, le système d’authentification unique (SSO) Entra ID de Microsoft ou encore l’adaptateur PingFederate. Et dans chaque cas, ils ont pu démontrer qu’un attaquant pouvait intercepter et réutiliser un jeton de session valide sans posséder la clé d’authentification FIDO2 associée.

Mais rassurez-vous, tout n’est pas perdu. Il existe une parade pour éviter de se faire dérober son précieux jeton : la « liaison de jeton » (ou token binding pour les anglophones). Concrètement, ça consiste à créer un lien indéfectible entre votre jeton de session et la connexion sécurisée (TLS) que vous utilisez. Comme ça, il devient impossible pour l’attaquant d’utiliser votre jeton sur une autre connexion. Malin !

Le hic, c’est que cette protection est encore peu répandue. Et à part Microsoft qui l’a intégrée sur Edge, les autres navigateurs et applications web traînent des pieds. Google a même fini par jeter l’éponge sur Chrome, faute d’adoption. Pourtant, cela pourrait éviter bien des déboires aux utilisateurs et des migraines aux administrateurs système mais que voulez-vous, entre la sécurité et la facilité, le cœur des développeurs balance !

Bref, restez vigilant car même une sécurisation FIDO2 n’est pas infaillible face à une attaque MITM bien pensée. Microsoft a réagi de son côté en introduisant une fonctionnalité de protection des jetons basée sur les modules de plateforme sécurisée (TPM) dans Windows, une variante de la « liaison de jeton ». Mais pour une adoption massive, il faudra que tous les acteurs jouent le jeu.

En attendant, les experts recommandent aux développeurs d’applications d’exiger la « liaison de jeton » sur les authentifications FIDO2 lorsque c’est possible, de limiter l’usage des jetons OIDC et SAML à une seule fois par authentification réussie, et surtout de bien comprendre les menaces pour concevoir des mécanismes d’authentification adaptés.

Et vous, en tant qu’utilisateur, c’est toujours la même chanson, à savoir, évitez de vous connecter à des hotspots Wi-Fi publics douteux, ne cliquez pas sur les liens louches, et méfiez-vous des plugins de navigateur exotiques.

Bref, un peu de jugeotte, comme toujours… Sur ce, bon développement à tous et may the force (4th) be with you ! (On l’a passé, c’était le 4 mai…)

Source

Si vous cherchez une application pour gérer tous vos codes de double authentification, je vous propose aujourd’hui qu’on se penche sur le cas de 2FAS.

Il s’agit d’une application disponible en français sous iOS et Android qui est totalement libre et qui supporte les codes TOTP (time-based one-time passwords) et HOTP.

Pour rappel, le 2FA (Two-Factor Authentication) est une méthode d’authentification qui fournit une couche supplémentaire de sécurité pour les comptes en ligne. Ainsi en plus du nom d’utilisateur et du mot de passe, le 2FA utilise un deuxième facteur, qui n’est ni plus ni moins qu’un mot de passe à usage unique (OTP) affiché sur le téléphone de l’utilisateur, pour vérifier l’identité de ce dernier. Cela permet d’empêcher l’accès non autorisé aux comptes, même si le mot de passe est compromis.

Le fonctionnement de 2FAS est assez similaire à celui d’Authy ou de Google Authenticator. Sauf que 2FAS propose de la synchronisation sur votre compte iCloud / Google si vous le désirez et la possibilité d’importer des codes existants depuis d’autres outils comme Aegis, Raivo OTP, Lastpass, Google Authenticator, andOTP ou encore Authenticator Pro. Pour ceux qui sont coincés avec Authy, vu que ça ferme, surveillez le blog dans les jours qui viennent, je vous prépare un tuto pour vous sauver.

Pour sécuriser l’app, vous pouvez lui ajouter un code pin ansi sur le faceID, et cerise sur le gateau, vous avez la possibilité d’installer une extension sur votre navigateur desktop qui ira communiquer directement avec votre smartphone pour saisir à votre place les codes de double authentification via une simple alerte.

Bref, c’est un outil moderne, avec une interface très sympa et en plus c’est libre ! Que demande le peuple ?

À découvrir ici.