Hier à 10h 24

En effet, on se demande... Et je vais leur demander !

Le 22/04/2024 à 13h 15

Après l'attaque du Slip, on se fait trouer le pot.

Le 18/04/2024 à 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.

Le 02/04/2024 à 18h 57

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...

Le 20/03/2024 à 12h 34

Ca fera combien de FPS avec Fortnite ?

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).

Le 08/03/2024 à 09h 55

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.).

Le 04/03/2024 à 15h 54

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

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.

Le 04/03/2024 à 08h 53

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

Le 27/02/2024 à 11h 30

Flock a déclaré forfait. Bisous Flock !

Le 23/02/2024 à 09h 02

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

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 !

Le 16/12/2023 à 22h 46

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...

Le 15/12/2023 à 15h 18

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 ?

Le 14/12/2023 à 09h 49

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...

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).

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).

Le 01/12/2023 à 11h 22

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...

Le 27/11/2023 à 10h 01

Ayé, corrigé.

Le 25/11/2023 à 10h 56

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 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.

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 ?

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.

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.

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.

Le 28/08/2023 à 15h 22

(reply:2149322:FrancoisA) Patrick Drahi ?

Le 22/08/2023 à 11h 32

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

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 )

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…

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.

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).

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.

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

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).