votre avatar Abonné

Jean_G

est avec nous depuis le 2 juin 2010 ❤️

Bio

Ancien lecteur, devenu vieux lecteur, et contributeur occasionnel !

Site personnel

https://secu.si

324 commentaires

Cadran de coffre-fort

Hier à 14h 22

Une question qui se pose souvent dans le milieu professionnel : est-ce que l'open source est sûr ? Souvent les avis sont tranchés (oui catégorique ou non définitif), alors que la vraie réponse est qu'avec l'open source, il faut gérer des risques différemment. Les développeurs sont souvent bénévoles, sauf pour quelques gros projets, la réactivité n'est pas la même, et rien que la licence d'utilisation peut réserver des surprises.

Et pour illustrer le dessin de xkcd, le projet openSSL (qui a eu une influence déterminante sur le développement d'internet en permettant des communications sécurisées) n'était maintenu que par un seul développeur à plein temps au moment de l'apparition de la vulnérabilité HeartBleed.

Photo d'une pince coupante

Le 02/04/2024 à 18h 57

Si ça n'avait pas été intercepté à temps, la backdoor aurait aussi fini par être présente dans WSL.

Sur WSL, on est passé sur... 5.6.1 ! Mais pas de panique, il s'agit d'une version spéciale. En réalité, il s'agit de la version 5.4.5-1. Ouf...

2024-04-01 12:22:29 status installed xz-utils:amd64 5.6.1+really5.4.5-1

Le 20/03/2024 à 17h 00

C'était bien le sens de ma remarque...

:fumer:

Le 20/03/2024 à 12h 34

Ca fera combien de FPS avec Fortnite ?

:fume:

Le 08/03/2024 à 10h 05

C'est d'ailleurs depuis longtemps son argument principal : la sécurité (et pas du tout que ça oblige tout le monde à leur verser des royalties et autres frais, non, non).

:fumer:

Le 08/03/2024 à 09h 55

Pareil, ça m'intéresse beaucoup mais je ne comprends pas vraiment. Les empreintes ne sont - heureusement ! - pas accessibles aux apps donc dire que la biométrie est à jeter, ça me semble non seulement un peu fort, mais risqué au vu de l'utilisation d'autres FA moins solides.

Après, si une banque utilise une pauvre reconnaissance faciale, le problème n'est pas la biométrie ! Si quelqu'un utilise comme mot de passe "aaaaaaaaaaaaaaaaaaaa", on ne va pas remettre en question la solidité d'un mot de passe de 20 caractères. Tout comme on ne remet pas en question celle des PIN de cartes bleues (parce qu'il n'y a que 3 essais possibles et des plafonds de dépense).

Allez voir la tronche des KYC modernes, où il faut sourire, arrêter de sourire, pencher la tête, etc. ce n'est pas avec une capture random que vous allez réussir le challenge.

Également, j'ai dû mal à comprendre :
Dernier rappel : l’entropie des caractéristiques biométriques atteignent péniblement celle d’un code PIN sur quatre chiffres. On est loin du bullet-proof…
Pour une reconnaissance faciale basique, pourquoi pas. Mais pour une empreinte digital ?!

Alors déjà ça n'est pas (que) moi qui dit que la biométrie n'est pas un bon moyen d'authentification, c'est l'ANSSI (cf. doc sur l'authentification forte). Pour ma part, j'ai également fait une étude de 6 mois sur le sujet (pour mon autre boulot, en dehors de Next), et je suis d'accord avec eux. L'avantage principal de la biométrie est le confort d'utilisation, pas son niveau de sécurité. Après, ça répond à certains usages, pas à d'autres. L'ANSSI ne recommande son utilisation qu'en complément d'un autre facteur suffisamment fort.

Point important : les banques n'utilisent pas une reconnaissance faciale pourrie ou pas, elles utilisent en général le dispositif installé sur le smartphone. Quelqu'un de minutieux ira interroger le terminal pour adapter sa sécurité en fonction du niveau de qualité connu de la biométrie, mais on approche de la science-fiction (il faudrait une évaluation indépendante de tous les dispositifs, mais à ma connaissance ça n'existe que pour les dispositifs FIDO).

Un mythe qu'il faut également briser : qu'une appli ou un OS n'ait pas accès aux gabarits biométriques, c'est la moindre des choses mais les attaques ne passent jamais par là. Attaquer une enclavé sécurisée est trop compliqué et, à l'inverse de ce que dit un confrère, il n'y a rien de rassurant à savoir que les attaquants n'ont utilisé aucune vulnérabilité de l'OS ni récupéré d'information dans l'enclave sécurisée : le point faible n'est pas là ! Il est dans le fait qu'on trouve des éléments biométriques n'importe où (la CNIL considère d'ailleurs maintenant que tous les types de biométrie peuvent laisser des traces dans leur environnement, et donc peuvent être interceptées). On peut même retrouver l'empreinte digitale dans les selfies de personnes faisant le signe "V"... Ici, dans le cas de figure de l'article, l'attaque consistait à récupérer une vidéo à rejouer ou une image à enrichir avec de l'IA pour déjouer l'authentification d'applications bancaires.

Du point de vue de la résistance aux attaques (c'est ça, la vraie "entropie" qu'il faut évaluer), Apple est meilleur qu'Android sur la reconnaissance faciale car il peut imposer sur ses terminaux plusieurs capteurs de type différents qui permettent de fiabiliser la reconnaissance faciale. Néanmoins, Apple annonce aujourd'hui un taux d'erreur de 1 sur 1 000 000 (en jouant probablement un peu sur les paramètres mais c'est un détail), ce qui correspond à un code PIN sur 6 caractères à peu près (sachant qu'un code PIN peut être changé, pas un visage...). Pour l'empreinte digitale, iOS annonce un taux d'erreur de 1 sur 50 000, Android c'est souvent le même ordre de grandeur (ça dépend des fabricants), donc ça n'est pas meilleur, c'est pire (sur les smartphones).

De plus, autant dans Android que dans iOS, le code PIN prime lorsqu'il s'agit d'opérations sensibles (c'est dans tous les docs d'utilisation). En clair : on a plus confiance dans un code PIN que dans la biométrie, fut-elle faciale...

Par ailleurs, il ne faut pas confondre les capteurs de haut niveau (type Thalès, avec une surface de captation de plusieurs cm²) avec un capteur de smartphone dont la résolution est souvent de l'ordre de 64 pixels sur 64. Sachant que pour interpréter une image d'empreinte digitale, il faut interpréter des motifs (spirales, boucles, arches...), le système doit faire ça sur une image de 64x64 pixels !

Pour ce qui est des systèmes qui demandent de tourner la tête, de sourire, et tout ça, c'est justement ça que cette attaque permet de bypasser : les attaquants fabriquent un filtre (genre Insta ou TikTok) et se le mettent sur leur visage et c'est ça qu'ils présentent au système d'authentification. Ce dernier voit donc qqch qui ressemble au bon utilisateur, et qui bouge selon les ordres...

Tu parles également de l'utilisateur qui mettrait "aaaaaaa..." dans son mot de passe : oui, on ne remet pas en cause les mots de passe longs. La "faille" vient du manque d'entropie en entrée, ce qui peut être vérifié pour un mot de passe (tu as sûrement souvent vu un thermomètre indiquant si le mot de passe que tu es en train de créer est suffisamment sécurisé ou pas). Le problème de la biométrie est que tu ne peux pas demander à un utilisateur de modifier son doigt ou son visage pour être sécurisé. Et, heureusement, un visage est souvent homogène, parfois harmonieux : il est par exemple rare de changer de coloration de peau 20 fois sur un cm². L'entropie biométrique (pour le visage) est largement affaiblie par le fait que nos visages ne sont pas fait d'aléas extraordinairement nombreux.

Et heureusement, car on aura du mal à se reconnaître, et je terminerai là dessus : la biométrie aura toujours une marge d'erreur, car c'est une mesure (donc intrinsèquement avec une marge d'erreur, qui dépend de la qualité des capteurs et du mode de calcul de ressemblance) et surtout il faut qu'il y ait une marge d'erreur car nous sommes vivants et donc nous changeons. Aujourd'hui, on pense que la biométrie faciale a une marge de progression, mais à vouloir être trop précis on finira par ne plus reconnaître l'utilisateur légitime (car la moindre différence entraînera le rejet, donc interdiction de vieillir, de se couper les cheveux, de se raser ou de se laisser pousser la barbe, d'avoir de la couperose, de laisser pousser les cartilages comme le nez ou les oreilles, etc.).

Ferris the crab, unofficial mascot for Rust

Le 04/03/2024 à 15h 54

Il y a beaucoup de vulnérabilités liées à la nature du COBOL ?

Ca fait longtemps que je ne fais plus de COBOL, il autorise désormais aussi les pointeurs hélas, mais en tout cas les attaques seront différentes et probablement moins efficaces (dans le cadre de la gestion de mémoire) mais surtout en raison de l'OS sous-jacent (z/OS) qui ne fonctionne pas comme Windows ou Linux.

Mais bon, écrire un driver d'imprimante Windows en COBOL, faut aimer le sport.

Le 04/03/2024 à 09h 39

Et les perfs ?
Je n'ai jamais entendu parler du fait que Rust serait plus rapide que le C !?

Et pour faire plus rapide que le C, c'est l'assembleur ... et là, les « framework for monkeys » y'en a pas.

Y aussi le COBOL. C'est quasiment de l'assembleur, cela dit.

Le 04/03/2024 à 09h 38

Dans le document de la Maison Blanche, Rust est le seul exemple cité. LMI indique bien que Rust est cité, et que c'est un autre document de la NSA qui évoquer les autres langages (Swift, C#, etc.).

Le 04/03/2024 à 09h 24

Tout à fait d'accord pour l'empilement des couches. Depuis 30 ans que je fais de l'informatique, je n'ai quasiment jamais entendu quelqu'un parler d'optimisation...

Pour ce qui est de Rust, le langage est effectivement memory safe sauf que... pour une raison qui m'échappe, il est prévu des opérations unsafe telles que déréférencer un pointeur.

:reflechis: :fumer:

Le 04/03/2024 à 08h 53

[troll]Biden décide de s'occuper des problèmes de mémoire. Il était temps.[/troll]

Cerveau et intelligence artificielle

Le 27/02/2024 à 11h 30

Flock a déclaré forfait. Bisous Flock !

une icône de l'application reddit affiche 2 notifications en attente

Le 23/02/2024 à 09h 02

On comprend mieux https://next.ink/brief_article/google-met-la-generation-dimages-via-gemini-sur-pause/ :fumer:

lexique IA parodie

Le 16/01/2024 à 11h 10

Pour ma part, je parlerais de classement automatisé de motifs complexes. J'ai vu ça dans un bouquin. Et après, je serai assez d'accord avec S. Hawking, mais ça n'est l'IA qui va tuer l'être humain, c'est l'être humain qui va donner les clés de la boutique aux machines, par bêtise. Voilà pour la petite note optimiste de la matinée !
:fumer:

Guacamole sur un plateau épisode 5 sur 5

Le 16/12/2023 à 22h 46

Le code n'est pas à usage unique : il est valable durant un temps limité, qui n'est d'ailleurs pas défini précisément dans le RFC : il est recommandé à 30 secondes, mais il est plus souvent de l'ordre de la minute.


Désolé de te contredire, mais non ;)

Extrait de la RFC 6238 :

Note that a prover may send the same OTP inside a given time-step
window multiple times to a verifier. The verifier MUST NOT accept
the second attempt of the OTP after the successful validation has
been issued for the first OTP, which ensures one-time only use of an
OTP.


Que l'on pourrait traduire par :
Notez qu'un "prouveur" peut envoyer le même OTP à l'intérieur d'une fenêtre temporelle plusieurs fois à un "vérifieur". Le "vérifieur" NE DOIT PAS accepter la seconde tentative de l'OTP après une validation réussie du premier essai, ce qui assure un usage unique pour un OTP

Par ailleurs, il existe des versions (très) améliorées des keyloggers : les proxy locaux ou Man-in-the-Browser.


Oui, mais là, on change généralement de catégorie. Ce n'est plus un keylogger si le logiciel scrute le réseau. C'est de l'ordre de l'interception ou d'une attaque par l'homme du milieu.

Un keylogger est un dispositif (il peut être matériel ou logiciel) qui va enregistrer ce que l'utilisateur a saisie au clavier. Là, tu parles de logiciels qui vont examiner les flux réseaux. Si l'objectif recherché est le même (voler les identifiant), les moyens mis en oeuvre les classes dans des catégories très différentes.
Ayant travaillé longtemps pour une banque, je t'assure que cette technique est réelle et très efficace. Je n'ai plus le nom du plus virulent (je crois que c'était Dridex) mais la seule véritable parade était (et est toujours) d'utiliser un vrai second canal. A noter que FIDO/FIDO2 permet aussi de créer un second canal "virtuel", sous certaines conditions, en permettant de valider un challenge en dehors du navigateur.


Je n'ai jamais dis que les TOTP étaient une protection ultime. Dans ton article, c'est toi qui parle de keylogger, et qui dit que le TOTP ne protège pas des keylogger. Ce qui est erroné.

Par contre, je suis d'accord avec toi pour dire que l'OTP ne va pas protéger d'attaques plus poussées comme les attaques de l'homme du milieu, et que séparer les canaux rend les attaques très difficile à mettre en oeuvre, puisqu'il faut alors pouvoir scruter les 2 canaux en même temps, et en temps réel.

Je m'incline !

Le 16/12/2023 à 21h 27

Pas tout à fait : les mots de passe à usage unique sont plutôt des HOTP (basés sur RFC 4226), utilisant un secret et un compteur, et ne sont plus très souvent utilisés, la synchronisation des compteurs étant délicate. On utilise le plus souvent un TOTP (RFC 6238), Time-based OTP, basé sur un secret partagé et une horloge. Google Authenticator utilise ce standard, par exemple. Le code n'est pas à usage unique : il est valable durant un temps limité, qui n'est d'ailleurs pas défini précisément dans le RFC : il est recommandé à 30 secondes, mais il est plus souvent de l'ordre de la minute.

Par ailleurs, il existe des versions (très) améliorées des keyloggers : les proxy locaux ou Man-in-the-Browser. Des malwares utilisant ce type de technique vont intercepter tout ce qui passe à destination d'internet : on va donc "lire" à la fois le mot de passe et l'éventuel code TOTP s'il est fourni par le même canal (d'où l'importance de la distinction entre second facteur et second canal). Quand on cherche à intercepter une connexion, on va écouter tout le temps, intercepter les informations de connexions dans le proxy local, les envoyer vers l'attaquant et rejouer l'authentification ailleurs, immédiatement, puis maintenir la connexion si besoin.

Ayant travaillé longtemps pour une banque, je t'assure que cette technique est réelle et très efficace. Je n'ai plus le nom du plus virulent (je crois que c'était Dridex) mais la seule véritable parade était (et est toujours) d'utiliser un vrai second canal. A noter que FIDO/FIDO2 permet aussi de créer un second canal "virtuel", sous certaines conditions, en permettant de valider un challenge en dehors du navigateur.

Le 16/12/2023 à 21h 02

L'exemple est fourni par DUO, donc je suppose que ça leur suffit ! Je ne connais pas l'usage exact de ce paramètre donc je leur fais confiance...

Guacamole sur un plateau épisode 4 sur 5

Le 15/12/2023 à 15h 18

Arf, j'ai pas lu l'article précédent. J'avoue ^^

Mais oui, en tout cas, c'est important de bien sécuriser les clés. C'est d'autant plus important que l'idée des articles est de monter un bastion sécurisé !

Une clé privée (ou une clé de chiffrement symétrique) se doit de n'être accessible que par le minimum de monde. Et surtout pas exécutable :aie:

Egalement OK pour les certificats, par contre c'est un peu plus sioux d'après ce que j'ai vu, il faudrait faire :
root@r:/etc# chown -R tomcat /etc/letsencrypt/archive /etc/letsencrypt/live
Pour le droit exécutable, certbot himself les laisse... Je ne sais pas pourquoi, d'ailleurs.

Le 15/12/2023 à 15h 16

Le 755 est un mauvais réflexe de serveur web. Tout à fait d'accord avec la solution pour mysql. Je l'intègre dans l'article... dès que je peux. Seb, si tu nous écoutes ?

Guacamole sur un plateau épisode 3 sur 5

Le 14/12/2023 à 09h 49

Très clair, mais par contre, je n’aime pas que toutes les commandes soient exécutées en root (par exemple, les wget et autres tar ne devraient pas l’être), et que les droits d’accès ne soient pas gérés correctement (dans l’article précédent, le chmod -R 755 /etc/letsencrypt n’est pas une bonne idée par exemple, clairement pas à faire pour de la prod).

Mais ça a le mérite d’être là, et effectivement, très facile à suivre 👍

C'est écrit au tout début de la 1ère partie de l'article : "Sécurisez aussi l’accès du compte root (avec toutes les variantes possibles : authentification par certificat uniquement, second facteur, interdiction de la connexion root et utilisation de sudo, etc.) mais on risque de déborder largement du sujet." L'article est déjà long, l'idée était surtout de montrer la globalité de la construction.

Après, comme toujours, il est possible (et même encouragé) de proposer des discussions et des améliorations dans les commentaires ! Ici, on partage la connaissance !

Le 14/12/2023 à 09h 37

On faisait pas beaucoup de tutos, jusqu'à présent, et la console pour les pigistes n'est pas encore opérationnelle, donc tout n'est pas encore au point ! Mais oui, sur du WordPress, on devrait pouvoir trouver qqch...

Guacamole sur un plateau épisode 2 sur 5

Le 13/12/2023 à 17h 31

Si si, c'est bien Flock. Il a peut-être recadré son illustration (où il l'a fournie à l'arrache).

Guacamole sur un plateau épisode 1 sur 5

Le 12/12/2023 à 23h 13

On peut creuser le sujet. Par contre il faut bien différencier "second facteur" et "second canal" ; j'en parle dans la suite en utilisant une solution multicanale, hélas non open source ;) D'un point de vue pratique, ça pourra faire l'objet d'un petit complément et d'un état des lieux, car ça évolue en permanence (quoique dans le fond, pas trop).

Chiffre et formules mathématiques sur un tableau

Le 01/12/2023 à 11h 22

PCI-DSS, c'est pour les systèmes hébergeant ou traitant les informations liées aux cartes de paiement. J'ai participé à des implémentations PCI-DSS jusqu'à la version 3, et je peux dire que la première chose nécessaire comme compétence pour ce type d'exercice, c'est la compréhension à la lecture (qui semble faire défaut malheureusement chez certains SecOff).

Dans l'ensemble, ISO 27k1 est très intéressant, mais il s'agit surtout de gouvernance et de processus encadrant le contexte sécurité (formalisation, exécution et contrôle) plutôt que de sécurité elle-même. Connaître la norme est important évidemment important si on veut obtenir la certification pour une entreprise, mais cela ne fonctionne que si on a du personnel sécurité compétent pour faire fonctionner ces processus. Pour moi un des points vraiment très importants de la norme est que ça met un cadre autour des analyses de risque et peut inciter les entreprises à les faire correctement (par exemple via iso 27k5), car sans gestion du risque correcte, on ne peut pas prendre de décisions éclairées.

Quand je présente mon activité, je dis souvent : "en réalité, la sécurité des systèmes d’information devrait s’appeler la gestion des risques de sécurité liés à l’utilisation des systèmes d’information."

PCI-DSS sert en effet pour les moyens de paiement, ISO27001 est une norme de qualité s'appliquant aux SMSI (Systèmes de Management de la Sécurité de l'Information) mais qui traite assez peu de sécurité (directement) : son objet est plutôt l'amélioration continue de sa gestion de la sécurité. En gros, on peut être certifié ISO27001 en ayant une sécurité pourrie. Simplement, ça veut dire que vous avez mis en place une gestion qui tend à l'améliorer en permanence. Et comme tout norme, elle s'applique sur un périmètre précis. C'est un peu comme l'ISO9001 (dont elle est très proche) mais appliqué à la sécu info.

Après, chez Next, on écoute nos lecteurs, donc si ça intéresse quelqu'un...

Pilule rouge et bleue avec des messages codés

Le 27/11/2023 à 10h 01

Ayé, corrigé.

Le 25/11/2023 à 10h 56

J'admets que ça m'a fait tiquer également. J'ai fait une recherche pour lever le doute et le terme "encapsulage" existe bel et bien. Juste pas en informatique en fait.

Vous avez raison, mais à force de lire et traduire plusieurs sources, je me suis emmêlé les pinceaux. On corrige dès que les journées de 36 heures auront été inventées (c'est pour dire qu'avec le nouveau site, toute l'équipe est sous l'eau, y a un taf' énorme derrière et ils sont surchargés). C'est l'occasion de les encourager et les féliciter !

Le 24/11/2023 à 22h 37

Ca n'était que pour faire une analogie : TLS 1.3 a en effet changé beaucoup de choses, et le mécanisme d'encapsulation qui était appliqué aux anciennes versions de TLS ne le serait donc plus, merci pour tes éclaircissements ! Pour les curieux : https://datatracker.ietf.org/doc/html/rfc8446#page-24 !

Le 24/11/2023 à 18h 03

Oui, c'est tout à fait exact, mais hélas je n'arrive plus à retrouver l'émoticône Maître Capello sur le nouveau site. Je vais demander une formation au (rédac) chef.

Le CICR édicte des règles d'engagement à l'intention des hackers impliqués dans des cyberguerres

Le 09/10/2023 à 08h 42

La question n’est pas (hélas) de savoir si les lois sont respectées en temps de guerre, on sait qu’elles ne le sont pas toujours et c’est un euphémisme. Toutefois il y a derrière cela des questions fondamentales : quel est le statut d’une personne prenant partie dans un conflit via des attaques informatiques ? Doit-il être reconnu comme un combattant ou pas ?



Quant à la question des “lois”, il ne faut pas oublier qu’elles ont aussi un rôle post conflit, avec la possibilité de juger des “criminels” selon qu’ils aient respecté ou non ces principes. Pour illustrer, on pourrait ainsi se dire : quelqu’un qui a réalisé des cyberattaques contre des hôpitaux pourrait être traduit en justice, mais pas celui qui n’a attaqué que des infrastructures militaires.



Cela peut paraître utopique ou illusoire, mais même en temps de guerre on a le droit (sans jeu de mot) ou le devoir de se poser des questions.



Pour ceux qui veulent aller plus loin, le blog des juristes ayant réfléchi à ces règles est ici : EJIL : Talk!.



Sachez aussi que certains sites de la Croix Rouge (les branches russe et biélorusse) ont été la cible d’attaquants pro-ukrainiens qui estiment que cet organisation devrait plutôt agir sur les exactions russes durant ce conflit.


What's Next ?

Le 03/10/2023 à 07h 59

Y aura des goodies genre Vacheron Constantin ou Panerai Luminor, histoire de vérifier la précision suisse de la répartition du temps ?


[Enquête] Les escrocs du scraping

Le 28/09/2023 à 11h 57

A mon avis, l’analogie ne fonctionne pas ici : l’utilisation normale du marteau est de bricoler, ce qui est légal. L’utilisation normale (et le seul usage) du plugin oblige l’utilisateur a enfreindre les CGU de LinkedIn.



Les commentaires sont là pour ça ! D’ailleurs le jugement semble bien dire que le scraping est légal. Par contre, dans le cas mentionné, si on était en Europe, cela tomberait sous le coup du RGPD : même si le scraping reste légal, la collecte de données sans l’accord de l’utilisateur ne le serait probablement pas.


Le 27/09/2023 à 07h 37


(reply:2155301:fofo9012) Prenons une analogie, avec un monde (purement imaginaire) où la vente d’armes à feu serait autorisée mais leur usage interdit. Quel serait le levier le plus efficace pour être protégé (si on excepte prendre soi-même une arme à feu) : demander à toute la population de respecter la loi qui interdit de s’en servir ? Demander de ne pas en acheter ? Ou agir à la source (sur la vente d’armes ou leur fabrication) ? C’est la question (ouverte) du problème du scraping, heureusement plus énervant que grave !



Le 27/09/2023 à 06h 55


(reply:2155218:Zone démilitarisée) Levons (un peu) l’ambiguïté : je confirme que skrapp.io n’a pas le droit de parcourir les pages LinkedIn pour en tirer de l’information en tant que responsable du traitement. Par exemple il n’a pas le droit de les stocker lui-même pour les proposer ensuite à ses clients, cf. ce que nous a dit la CNIL à ce sujet sur le responsable de traitement. Mais c’est là toute l’astuce, c’est un utilisateur de LinkedIn qui opère et qui est responsable de l’usage du plugin sur LinkedIn et des données.



Le 26/09/2023 à 15h 18


(reply:2155194:Zone démilitarisée) (reply:2155184:Xanatos)




Le problème (la subtilité) est là : le scraping n’est pas interdit. C’est l’utilisateur du plugin qui est en faute quand il l’utilise (car cela contrevient aux CGU qu’il a acceptées, lui). Or la “victime” ne peut se retourner que contre l’utilisateur du plugin (si l’utilisateur contrevient au GRPD), pas l’éditeur du plugin. Or s’il a du succès, on peut se retrouver avec centaines d’utilisateurs du plugin à contacter, au lieu d’un seul point de contact (l’éditeur). Idem pour LinkedIn qui ne pourra agir que sur les utilisateurs (côté CGU). C’est tout le problème du scraping, et les outils sont nombreux (par ex https://chrome.google.com/webstore/search/scraping?hl=fr&_category=extensions).



Côté skrapp.io : zéro réponse.


#Flock joue avec le feu et distille des indices

Le 17/09/2023 à 16h 27

Attention : à tous ceux qui voient déjà Bambi à la tête de NextInpact, méfiez-vous : il y a un autre personnage sur la photo 14. Hélas , ce personnage est difficile à distinguer, mais il pourrait s’agit de Fleur ou de Panpan. Le mystère reste donc entier.
:fumer:


Petite histoire du CAPTCHA : création, évolutions et dérives

Le 04/09/2023 à 16h 32

L’idée du test de Türing original était qu’on arrive à ce qu’on ne puisse pas distinguer une machine d’un humain (et à ma connaissance, aucune machine n’a réussi le test, et vu comment il est facile de tromper un chatGPT et autres qui ne se cachent même pas d’être des machines…).




Un CAPTCHA est donc plutôt un test de Türing inversé car on cherche exactement le contraire, à savoir réussir à distinguer la machine de l’humain. Après, je trouve très paradoxal qu’on demande à une machine de deviner s’il y a un humain à l’autre bout… Dans un test de Türing, c’est un humain qui mène le bal.



:fumer:


Next INpact au ralenti ce lundi

Le 28/08/2023 à 15h 22


(reply:2149322:FrancoisA) Patrick Drahi ?



CAPTCHA : les machines « prouvent » plus rapidement qu'elles sont des humains

Le 22/08/2023 à 11h 32


(reply:2148039:Daniel K) Y a qu’à demander :D



Le 22/08/2023 à 09h 11


(reply:2147953:anagrys) Non, tu seras juste rétrogradé au rang d’esclave des machines.




Sinon un rappel : la solution Google reCAPTCHA telle quelle n’est pas conforme au RGPD. En effet, il faudrait en théorie d’abord cliquer sur une case de consentement pour utiliser ce service avant la collecte des données.



Sources : https://www.nextinpact.com/article/30414/109181-application-stopcovid-la-cnil-exige-correction-plusieurs-irregularites et https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/FAQ (§ 16).



Le RGPD permet de se passer du consentement utilisateur uniquement si le service ne sert qu’à la lutte contre la fraude (et donc les bots), ce qui n’est pas le cas avec le reCAPTCHA.


Le 22/08/2023 à 08h 48

Sinon voir aussi https://www.youtube.com/watch?v=LButXcZ57pc (attention aux trackers Google :D)
:fumer:


Le 22/08/2023 à 08h 33

Le système de CAPTCHA avec juste une case à cocher est en réalité beaucoup plus complexe : la case à cocher n’est que l’étape ultime d’une analyse des interactions avec l’utilisateur. Le principe est de lancer un JavaScript en début de chargement de page, et ce JavaScript examine les interactions, dialogue avec un serveur de l’éditeur du CAPTCHA, et en déduit un “score” qui indique la probabilité d’avoir un humain à l’autre bout du navigateur. Ensuite, si le score est élevé, on ne demande que de cocher une case ; si le score est trop faible, alors on peut soit refuser, soit proposer un challenge du genre lire un texte, chercher dans des images, etc.



Deux points importants sur le reCAPTCHA de Google : évidemment, comme beaucoup de solutions de ce type, il y a des l’IA pour évaluer “l’humanité” de l’utilisateur. Si cela permet d’entraîner de l’IA côté Google, ça reste sur un périmètre limité.



Par contre, plus important, cela veut dire que Google se sert de tous les utilisateurs du service pour cela. Pire encore : dans les conditions générales de Google, quand vous utilisez le service reCAPTCHA, il faut savoir que ce dernier est géré par la licence globale d’utilisation. Ainsi, les infos possiblement récoltées par le reCAPTCHA peuvent servir à Google pour le ciblage publicitaire. En corollaire, les trackers publicitaires de Google sont si largement utilisés qu’en général, quand un site web appelle le service reCAPTCHA, ce dernier a dispose déjà de tout ce qu’il faut pour savoir si vous êtes un humain ou pas.



En ce qui concerne la compétition homme-IA, sachant que les services de CAPTCHA utilisent quasiment tous de l’IA, il est logique qu’on puisse entraîner des IA pour les contrer. Tout comme en sécurité informatique, on utilise de plus en plus d’IA pour contrer les attaques, il faut s’attendre à ce que l’IA soit de plus en plus utilisées par les attaquants pour contourner les défenses en place…


Les exercices de gestion de crise cyber se généralisent dans les établissements de santé

Le 01/08/2023 à 08h 57


(reply:2145410:127.0.0.1) (reply:2145453:Soriatane)




La solution dans le cas que je décris était de simplement décoller la feuille et la recoller non pas derrière sur un mur, mais sur le bureau d’accueil, face aux soignants et non face aux patients. Idéalement, coller sur le bureau, en dessous du rebord où on pose ses papiers en s’adressant à l’accueil, caché de la vue des visiteurs (les bureaux d’accueil sont d’ailleurs très souvent conçus ainsi pour que l’accueillant puisse voir et écrire sur des documents hors de la vue des visiteurs).



Simple, efficace, pas cher et pas technique. Ca coûte pas 2 milliards, ça coûte un bout de scotch.



Je voulais par cet exemple juste souligner la distorsion entre cette mesure si simple à mettre en œuvre (et si efficace) et la difficulté à l’appliquer, probablement pour des raisons justifiables (imaginez si au moment de devoir utiliser ces codes, en période de stress, la personne ne retrouve pas la liste à sa place habituelle).


Le 31/07/2023 à 14h 54

Je me rappelle un passage aux urgences d’un grand hôpital parisien et, malgré une douleur difficilement contenue de doigts écrasés (les miens) par une porte blindée, j’ai tenté de façon constructive de dire à la personne en charge de l’accueil qu’avoir à portée de main (façon de parler) les logins/mot de passe pour les procédures d’urgence comme le plan blanc (= nombreuses victimes simultanées), c’est bien, mais que la feuille soit collée dans son dos visible de toute la salle d’attente relevait peut-être d’un problème de sécurité. La personne en question a poussé un “oh!” de surprise, me remerciant chaleureusement de lui avoir fait part de ce problème. Puis elle m’a assuré qu’elle aller en parler à son chef (ou sa cheffe, je ne sais plus) dès que possible pour remédier à ça.




La feuille doit toujours être à sa place, à mon avis.



:fumer:


Les exploits « 0-day » reposent de plus en plus sur des « Déjà vu-lnérabilités »

Le 31/07/2023 à 15h 04

Oui, mais pas uniquement le RGPD : des lois obligeant à faire part (publiquement ou non) des attaques subies se multiplient, et pas seulement en Europe. Avec parfois des petites variantes : en Chine, Alibaba Cloud, dont les chercheurs avaient découvert la faille log4shell, a eu des problèmes pour avoir divulgué la faille publiquement (= à l’éditeur Apache) au lieu d’en informer au préalable les instances gouvernementales chinoises (cf. ZDNet).


Les 2/3 des Américains aimeraient pouvoir revivre dans un monde sans Internet

Le 21/06/2023 à 07h 19

Mon petit avis perso : je me demande ce que ça aurait donné si on avait posé la question avec les smartphones au lieu d’internet.


LastPass : les pirates sont entrés par l’ordinateur d’un développeur

Le 01/03/2023 à 10h 17

Je ne sais pas où en est Dashlane, et je ne répondrai pas sans étudier le sujet, on est sérieux dans cette boutique ! Ca pourrait être d’ailleurs le sujet d’un test détaillé sous forme d’article (note à moi-même)… Néanmoins je pense qu’un coffre fort de mots de passe codes secrets en ligne est une mauvaise idée à cause de la centralisation des infos : un outil de ce type est clairement une cible de choix pour un attaquant, ce qui implique que du côté du fournisseur du logiciel, il faut être irréprochable (on le voit bien avec Lastpass dont le processus de qualité ne semble pas être au niveau). Voir aussi l’article de Vincent.


Le 01/03/2023 à 08h 33

Et Tavis Ormandy (de l’équipe Project Zero de Google) pointait la faiblesse de LastPass et Dashlane dès 2016… Les leçons n’ont pas été tirées.



https://www.numerama.com/tech/189111-mots-de-passe-apres-lastpass-la-securite-de-dashlane-mise-a-mal.html


Une voix synthétique générée par une IA permet d'accéder aux détails d'un compte bancaire

Le 27/02/2023 à 11h 01


wanou a dit:


Je suis le seul à tiquer sur l’image avec un handicapé incapable de se servir correctement de son téléphone et développant un trouble musculosquelettique en prime?




Non, non, la CNIL aussi tique sur ce sujet. Idem pour les empreintes : il y a des adermatoglyphes. Et je parle pas des accidents divers (brûlures, section, etc.)



La biométrie n’est pas un bon moyen d’authentification dans l’absolu, mais cela peut diminuer le risque dans certains cas, cf. notre article. Le gros souci est que ça n’est pas secret et que ça n’est pas modifiable. Ok, quelqu’un qui te cible, pour l’instant c’est rare. Mais une fois les caractéristiques (voix ou empreinte ou forme de l’iris) compromises, c’est-à-dire stockées dans une base de données, tout le monde pourra se la partager (chez les méchants pirates). Et toi tu ne pourras ni changer ta voix… ni la réutiliser puisqu’elle sera compromise !



Quant à l’éternel histoire du code PIN pour les sites bancaires, la plupart de ceux que je connais bloquent (souvent temporairement, genre 1 jour) l’accès après 3 ou 4 tentatives. C’est déjà pas mal, surtout que depuis DSP2, les accès sont normalement renforcés (au moins pour certaines opérations).


ChatGPT, Bard et les autres, agents de désinformation massive ?

Le 10/02/2023 à 15h 51

Pour ceux que ça intéresse, j’ai fait un petit test sur chatGPT pour bien montrer qu’il ne pense pas et qu’on peut lui faire dire ce qu’on veut. Le danger ne vient pas vraiment de l’outil mais des croyances que tout le monde forge autour de ce type d’outil.



https://www.linkedin.com/posts/jeangebarowski_chatgpt-activity-7029826264899158016-9N4Y?utm_source=share&utm_medium=member_desktop


Le 10/02/2023 à 08h 59

Bonjour à tous,



Je me permets de revenir sur cette “fameuse” phrase au sujet de faire ses propres recherches. Il ne s’agit évidemment pas de dire que faire des recherches par soi-même relève du complotisme. Simplement, dire “faites vos propres recherches” est une affirmation ambiguë : si elle est cohérente avec la politique d’utilisation de chatGPT, elle est aussi une constante des discours complotistes et, comme on navigue en eaux troubles, cela pose forcément question, car on voit bien que l’outil n’a pas de capacité de jugement ou d’appréciation et aussi il est incapable de savoir à qui il est en train de parler d’écrire.



A l’instar des chasseurs, il y a les bons chercheurs et les mauvais chercheurs d’information. Aujourd’hui, il faut faire preuve d’esprit critique lorsque l’on fait une recherche sur internet, car si on cherche quelque chose, on le trouve forcément. Vous ne croyez pas que la Terre est ronde sphérique ? Faites vos propres recherches ! Vous trouverez forcément de quoi alimenter cette théorie. On ne devrait donc pas dire “faites vos propres recherches” mais “faites vos propres recherches éclairées, de façon critique, ou sinon appuyez vous sur des gens compétents ou reconnus dans le domaine” (mais on pourrait débattre des heures sur ce sujet).



La difficulté est de sélectionner l’information pertinente et utile, ce dont sont incapables les moteurs de recherche et la tendance en cours d’intégrer des IA dans ces mêmes moteurs ne laisse rien présager de bon puisqu’on ne fera que faciliter l’utilisation d’un mécanisme non fiable à la base mais avec une apparence plus légitime (celle de l’IA).