La gamme de fréquence utilisée par le Bluetooth est la même que pour une partie du Wi-fi, des babyphones et même des transmetteurs vidéos sans fils (caméras de surveillance ou partage de décodeur Canal+).
C'est pour cela que j'ai précisé habiter dans une région relativement non polluée — du moins depuis quelques années. Cependant ce genre de déboire me suit depuis que je me suis hasardé à l'utilisation de Bluetooth.
Il suffit que pas loin un émetteur soit un peu puissant sur la même longueur d'onde, pour que cela ne marche plus.
Ça me paraît malgré tout fort peu probable là où je vis. J'ai déjà vu des potes faire fonctionner leur appareillage sous Bluetooth dans un environnement que je sais très pollué.
Ceci dit, rien ne m'empêche de le vérifier. Mais j'ignore comment mesurer cette pollution gigahertzienne de manière relativement fiable.
Il est possible aussi que quelqu'un dans le voisinage s'amuse avec des outils de desapairing bluetooth, soit innocemment, soit pour enquiquiner un autre.
Ça n'expliquerait pas mes déboires sur le long terme…
J'entends souvent des gens sur iOS me disant qu'ils ont parfois du mal à s'associer sur des périphériques non-Apple.
J'ai en effet entendu ça aussi (ou plutôt lu). Dans mon cas, le téléphone est Android et tous les ordinateurs sont sous [GNU/]Linux.
j'ai beaucoup de périphériques bluetooth
Ceux que tu énumères sont-ils fabriqués par la même société ou par des sociétés qui ont des accords commerciaux entre elles? Je pose la question car ça me paraît logique que des accords commerciaux, par exemple, amènent à partager des infos sur les protocoles sous clause de confidentialité. Si c'est la même société qui fabrique le tout, alors que ça fonctionne bien est une évidence, commercialement, en tout cas.
J'utilisais aussi mes souris bluetooth sous FreeBSD sur mon ancien HP ProBook, toujours sans aucun soucis.
Hmmm… j'ai fais ça aussi, passer par le sans-fil… jusqu'au jour où j'en ai eu ras la casquette de changer les piles au bout de deux à huit semaines et que les dispositifs déconnent à tout berzingue au bout de quelques jours — et je ne parle pas du lag, intermittent, à fracasser son clavier au mur tellement il a des ratés¹! Et je ne compte pas non plus le nombre d'appareils à piles dont la gestion de l'énergie est catastrophique, au point qu'on arrive à jeter, sans s'en douter, des piles qui ont encore jusqu'à 80% de réserve disponible (je ne parle pas de l'effet Batterizer). Suis revenu à clavier/souris filaires, même si ça doit traverser le salon!
Bon, j'exagère un chouïa, ma table (avec le clavier) n'est distante du PC que d'un mètre environ mais ça te donne une idée de mon état d'esprit. Pour le coup, je me sers d'un clavier Apple car c'est un des rares modèles, pas trop chers, à posséder au moins un hub USB. Pratique pour la souris. Et puis c'est plus robuste que le plastique, aussi… (Mais non, je tape pas dessus! Enfin… plus maintenant.)
ils regardent ce qui est le plus simple pour les gens sans préjugés informatiques […]
Sans vouloir verser dans la théorie du complot, perds quand-même pas de vue qu'«ils» ont tout intérêt aussi, comme je l'insinue ailleurs, à favoriser le tout-au-cloud même pour une liaison aussi triviale que téléphone-PC… J'ai envie de reformuler: «ils rendent plus simples à l'utilisation les transferts qui font un gourmand détour par internet».
Nous ne devons pas avoir la même définition de la simplicité.
En effet. Et ça n'a rien d'anormal. Je pense que "simplicité" n'est pas le bon terme à employer. Comme le fait justement remarquer Zenitram à propos des gens "normaux" (je pense et j'espère avoir compris ce qu'il veut dire par là), c'est la liaison vers le cloud qui semble être l'usage le plus répandu (le plus promu, aussi).
Maintenant, quant à parler de simplicité, la question est: «pour qui?»
Peut-être que passer par le cloud semble "simple" mais est-ce que c'est parce que les applications s'appuient sur des protocoles réseau, bien connus, mis en œuvre et en place depuis des décennies plutôt que sur une cata ambulante comme Bluetooth, qui change aussi souvent qu'un administrateur réseau changerait de SLIP¹? En ce cas, la simplicité (je parlerais plutôt de confort), c'est celle offerte aux développeurs et aux intégrateurs, pas forcément celle de l'utilisateur. En revanche, possible qu'on ait rendu cette fonctionnalité (via la pile réseau) simple à l'utilisation exprès pour que tout passe par là (comme c'est déjà le cas dans l'informatique PC).
Ensuite, rien de surprenant à ce que les communications passent par Gogol, Mama Zone ou encore Appelle-le, vu ce qu'on sait de ces entreprises et de ce qu'elles font des données qu'elles collectent. Pour les géants de l'information, c'est pas que ce soit simple, c'est juste bien juteux de manipuler autant de données, personnelles ou non. Et la simplicité d'utilisation, c'est la graine le confort qui attire le pigeon l'utilisateur. Personnellement, ça me tord une côte que mes fichiers fassent d'abord le tour de la planète en partant de chez moi avant d'y revenir…
Ça aurait été tout aussi profitable (au moins pour l'utilisateur) de rendre simple à l'utilisation toute mise en œuvre applicative du protocole Bluetooth… pour autant que ce soit faisable, bien entendu. Apparemment, ça n'est pas le cas. Que ce soit voulu ou pas, c'est une autre histoire.
¹ Tout compte fait, suis pas certain que ce soit une bonne analogie…
KDEConnnect ou GSConnect selon que ton gestionnaire de bureau est compatible avec l'un ou l'autre.
Je suis du côté sombre du miroir: je roule avec Xfce… C'est sur Blueman que je m'appuye/ais jusqu'à maintenant.
Tu pourras faire bien plus que transférer tes photos […]
Depuis tout ce temps, il n'y a jamais eu que le transfert de fichiers qui m'ait été vraiment utile avec BT. Ce qu'on peut faire d'autre ne m'intéresse pas vraiment.
Je suis parti en effet sur Blueman, que j'ai installé partout, à chaque fois, où j'ai pu le faire… sauf sur mon téléphone, bien entendu. Tant qu'à présent j'ai des résultats plus cohérents avec les versions "ligne de commande" des outils comme bluetoothctrl.
En fait, c'est uniquement le transfert de fichiers qui m'est (ou me serait) utile avec Bluetooth. À la limite, s'il est possible de recevoir des fichiers rien qu'avec les outils en ligne de commande, je m'en contenterai. Et alors exit blueman, façon «Keep It Strictly Straight».
J'ai lu qque part que dans les grands espaces comme au mieux d'une rue le BT avant la V5 peut perdre les pédales, car il avait besoin du rebond sur des murs pour s'en sortir…
Même lorsque les appareils sont distants de quelques dizaines de centimètres?
Si chez vous il y a une vieille installation électrique et du CPL […]
L'installation a moins de dix ans et il n'y a pas de CPL dans les parages — pas que je sache et pas chez moi en tout cas.
Je viens de terminer une mise à jour, c'est réussi. Par contre, j'ai toujours le message d'erreur:
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Error: Timeout was reached
Comment puis-je savoir exactement à quoi est dû ce message? J'imaginais que c'était le second lien mais là je n'en suis plus très sûr.
En tout cas, en ne payant pas d'impôt (à sa mesure) en France, il vole les français ;-)
Je me sens floué, volé, bafoué. Il y a un tas d'idées que j'ai eues et que des sociétés, qui ne m'ont même pas consulté et avec lesquelles je n'ai même pas eu d'échange, ont reprises et commercialisées en se faisant un tas de tunes avec ça. Je leur intenterais bien un procès pour manque à gagner, tiens. Ou mieux, je vais monter une société de lobbying et harceler les députés Européens pour faire élaborer un règlement en ma faveur. Oooh, je sens là une activité bien juteuse!
J'ai visionné le reportage Arte sur les Ouïghours. L'usage du conditionnement par les autorités chinoises sur ces gens est consternant d'horreur, tout comme celui de la technologie pour le pistage et l'identification systématique des citoyens. Et que ce genre de totalitarisme numérique se répande aussi en Europe (reconnaissance faciale, quelqu'un?) me fait froid dans le dos. De toute évidence, ce n'est pas dans le même but, hein? Ici c'est pour notre bien.
J'ai moins pris ça pour une attaque personnelle que pour une répétition ad nauseam. Considérons l'incident clos.
Mais, et je dis mais, ton propos serait valable aussi pour du SHA-256 ou n'importe quelle fonction de hashage.
Oui, tout-à-fait. C'est bien pour ça que j'ai ajouté: «Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.» Tu n'auras pas manqué de relever ce passage, j'espère? C'est juste que MD5, comparé à tout autre algo plus sophistiqué, rend terriblement plus rapide la déduction du schéma d'entrée par force brute.
Donc ta tirade sur MD5 = caca n'a strictement aucun intérêt et juger la stratégie de Lampiris sur ce point est une erreur. C'est tout.
Hein? Si je les juge, c'est pour leur méconnaissance (que je me dois de présumer apparente, bien que les indices ne me paraissent pas favorables) des mesures de sécurité (eu égard aux échanges que j'ai déjà eu avec eux, genre, je résume, «on utilise MD5 donc c'est sécuris黹), notamment à travers leur idée reçue sur MD5 et son emploi dans un contexte qui aurait dû nécessiter autre chose qu'une fonction de hash, qui plus est aussi trivialement réfutable et contestable que celle-là.
Ce serait minimiser mes propos et beaucoup trop simpliste que de les réduire à "MD5=caca, bouh Lampiris!" Ça va bien plus loin que ce simple constat.
Le discours qu'ils m'ont tenu en dit long sur leur manque de maîtrise du chapitre sécurité et pas qu'en raison de l'utilisation de MD5. Je ne vais évidemment pas publier ici nos échanges.
[…] je ne suis pas sûr qu'en justice tu gagnerais un procès en suivant ce principe non plus.
Ce n'est pas un procès qui m'intéresse, ça n'est pas constructif (oui, je sais, les traiter de cons non plus). Ce qui m'intéresse c'est qu'ils prennent plus de précaution à l'avenir pour sécuriser des données personnelles, quitte à réfléchir davantage sur la pertinence de leur utilisation dans les futures campagnes.
Bon, j'imagine qu'il vaut mieux en rester là, alors que je vois passer l'avertissement Goodwin de Linuxfr… J'ai entendu tes arguments et tu as entendu les miens, ça me convient.
¹ … ainsi qu'à la nonchalance généralisée des entreprises belges que nous avons contactées lors de mon expérience avec le RGPD dans le cadre des activités au sein d'une société à la construction de laquelle j'avais participé. La quasi totalité ignorait même l'existence du RGPD et ne s'en montrait que peu concernée. Les sociétés luxembourgeoises se sont avérées infiniment plus réceptives à ce sujet. Je pars avec un a priori, certes mais rien ne prouve qu'il est infondé.
Tu n'as rien compris (ou presque) […]
Et tu ne comprends pas non plus […]
En fait tu ne comprends pas que la sécurité […]
[…] tu manipules des concepts que tu ne comprends pas
Cela montre que tu ne comprends pas
C'est bon? Il y en a suffisamment à ton goût?
Première remarque: peux-tu, s'il te plaît cesser ce genre de réflexion grotesque et irritante? Tu n'es pas dans ma tête et tu n'as en aucun cas le droit de me juger sur des propos que tu penses avoir compris ou pas. Tu ne me connais absolument en rien et tu peux te dispenser ce genre de commentaire.
Le problème de MD5 est là, il n'est pas résistant aux collisions.
J'ai parfaitement compris le chapitre sur les collisions. Ce n'est pas de cela que je parle ici.
On ignore quelle est l'entrée (donc en fait comment a été généré cette suite)
Ça n'est pas suffisant pour affirmer haut et fort que le niveau de sécurité est suffisant.
Mais cela veut dire quoi craquer une URL ici ? Tu illustres ce que je dis plus haut, tu manipules des concepts que tu ne comprends pas.
Bon. Je vais tâcher de rester calme et d'ignorer ce lancinant agacement de ta remarque concernant mes capacités à comprendre. À mon tour d'être didactique.
Ce que j'entends par "craquer une URL" est un raccourci de langage, je pensais que tu aurais saisi.
L'obtention ou l'interception d'une seule URL, révélant l'utilisation de MD5 a les conséquences suivantes: s'il est possible de retrouver la donnée d'entrée, il est probable qu'alors le schéma de cette donnée corresponde à des données identifiables par un autre moyen. Avant de me voler dans les plumes, je suis conscient qu'il s'agit de pure spéculation… jusqu'à présent. Or ce qui n'était que pure spéculation de ma part quant à MD5 s'est avéré parfaitement exact. Réfléchis donc un rien avant de balancer à la poubelle mon argumentation, ainsi que ce qui pourrait bien me faire dire ça. Tu ne connais (probablement) pas Lampiris (supposition de ma part, jusqu'à preuve du contraire) ni leurs équipes informatiques ni l'état de leurs connaissances en termes de sécurité (moi non plus, objecteras-tu, n'est-ce pas?) et tu me connais encore moins (ça, c'est une certitude).
Si le craquage d'un seul hash permet de reconstituer la partie hashée de l'URL (c-à-d la donnée d'entrée), alors il est possible qu'en générant des données d'entrée, répondant au même schéma, on aboutisse à l'URL de vidéos relatives à d'autres clients.
Or jusqu'à présent, rien ne permet d'être certain que la donnée d'entrée ne fasse pas moins de 32 caractères — je ne me contenterai pas d'une simple supposition, je te rassure. Et dans ce cas, la donnée d'entrée ayant servi à générer les 32 caractères d'une URL reçue (ou interceptée) peut très bien être retrouvée — craquer un hash MD5 d'une quinzaine de caractères par force brute est tout à fait possible dans des temps parfaitement raisonnables, surtout si on dispose de plusieurs semaines ou mois. D'autant plus que les données d'entrée sont — plus que probablement — alphanumériques et non binaires, ce qui réduit considérablement le nombre de possibilités d'entrée à évaluer (la surface d'attaque).
J'objecte quant à utiliser un nombre aléatoire, hashé via MD5: ce serait absurde. Une série de 32 caractères aléatoires aurait bien plus de sens. Quant à ce fameux nombre aléatoire que tu suggères, plus il est court, plus il a de chances d'être craqué par force brute en un temps relativement court, donc plus l'utilisation de MD5 est compromise. Et plus sa longueur se rapproche de 32, moins l'utilisation de MD5 a de sens par rapport à la génération de 32 caractères alphanumériques aléatoires. Sans compter que la suggestion d'utiliser un nombre aléatoire a encore moins de sens puisqu'elle réduit à 10 au lieu de 62 (10+2x26) le nombre de symboles à utiliser pour les combinaisons d'entrée, ce qui est encore plus facile à craquer.
Avec seulement 10 symboles (0 à 9), la longueur maximum "craquable" en un mois est de 17 avec le système que j'ai mentionné. Et si tous les codes d'entrées sont sur 17 chiffres (ou moins) on génère l'URL des vidéos de tous les clients en moins d'un mois… Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.
Combine avec ça que, des possibilités d'entrée à tester, on peut très bien éliminer les combinaisons aussi triviales que aaaaaaa*, bbbbb* etc. C'est ce genre de "divination" que les outils de craquage prennent parfaitement en charge.
Donc, en résumé: MD5 n'élimine pas la possibilité de retrouver une seule donnée d'entrée, ce qui pourrait amener à retrouver le schéma d'entrée, complet, du hashage, utilisé dans l'URL des vidéos, d'où la possibilité de retrouver, par synthèse, d'autres vidéos personnelles. En raison de l'utilisation qui a été faite de MD5, la robustesse de la sécurité des données personnelles en jeu ne dépend que de la longueur de la donnée d'entrée: plus la seconde est petite, plus la première se rapproche de zéro.
Or je soupçonne la longueur de cette donnée d'entrée d'être bien inférieure à 32. Je ne m'en tiendrai pas, comme je l'ai annoncé, à cette simple supposition.
Note une chose, mon propos est uniquement à propos de ça et du fait que devant le peu de données réellement contenues dans ce genre de vidéo, cela n'a pas une grande importance non plus.
L'importance que tu accordes aux données personnelles ou à leur volume n'entre pas en ligne de compte quant à l'obligation légale de les sécuriser et les moyens employés.
Mon propos est que l'utilisation de MD5, contrairement aux idées reçues, n'est pas une sécurisation suffisante comparé, par exemple, à un accès authentifié.
Je suis d'accord avec toi sur le fait que :
Cette vidéo est globalement inutilement complexe pour peu d'informations ;
Ce contenu pourrait être accessible dans l'espace client uniquement.
Et moi je pense que toi, tu n'as pas perçu l'importance de ce problème. Dans les faits, MD5 est déprécié depuis plus de 20 ans, ses faiblesses sont démontrées depuis tout aussi longtemps et son utilisation dans un but de sécurité est fortement découragée. En gros (voir la page man de md5sum, c'est déjà un début):
"Ne pas utiliser MD5 à des fins de sécurité!"
ou encore:
"Do not use MD5 for security purposes."
C'est pas clair, ça?
Tel est aussi le message envoyé par les experts en cryptographie et en sécurité informatique (dont Bruce Schneier, tu peux aller vérifier). Tu n'as aucun effort à faire pour lire ça un peu partout. Libre à toi de l'ignorer mais prétendre que je ne comprends pas le concept et que je prouve que je ne sais pas de quoi je parle… ça me sidère!
Quelqu'un qui arrive encore aujourd'hui à justifier, envers et contre tout, l'utilisation de MD5 dans un contexte de sécurité est précisément quelqu'un qui ne sait pas de quoi il parle.
Pour craquer l'URL, le mauvais raisonnement consiste à prétendre que 32 caractères aléatoires représentent un nombre de possibilités trop élevé. Pourquoi? Parce que c'est raisonner à l'envers.
Puisqu'il ne faut que quelques secondes à quelques minutes pour craquer un hash MD5 avec du matériel commun, il suffit de générer autant de suites (dont la taille est limitée à quelques caractères), que l'on passe à MD5¹ pour multiplier les chances de tomber sur une URL valide, n'importe laquelle. Un des (nombreux) problèmes de MD5 est que plus la donnée "hashée" est petite, plus le temps nécessaire pour la craquer devient court. Et en dessous d'une certaine longueur, qui augmente à mesure que le temps passe, ce temps est ridiculement court, de l'ordre de la seconde.
En un mois, soient environ 2.500.000 secondes, et si on considère un système capable de générer 40 milliards de hash MD5 à la seconde, ça fait 10¹⁷ hashes par force brute au bout d'un mois. Et encore, là, on est sur un système qui date de 2016…
Ce n'est qu'une question de patience: à mesure que le temps passe, n'importe quelle URL finira craquée. Or il suffit d'une seule fuite, de craquer un seul de ces codes MD5 pour que la sécurité de toutes les données personnelles soit compromise. Et le nombre de clients ne se compte pas en dizaines de milliers mais bien plus que ça.
À moins qu'il sache quelle était l'entrée de la fonction de hashage, […]
Voilà, on y arrive: c'est exactement le point! MD5 1) ne protège pas contre la détection de la source employée et 2) la sécurité d'un système doit être inchangée même en connaissant l'algorithme (voir l'article concernant "la sécurité par l'obscurité" sur Wikipédia, pour commencer). Or là, ce n'est pas le cas.
[…] ce serait pareil avec n'importe quelle fonction de hashage
LOL! En fait tu en viens exactement, de manière détournée, à dire la même chose que moi: utiliser exclusivement une fonction de hashage dans une URL pour l'accès, sur un site public, à des données personnelles et privées est une mesure insuffisante.
Que veux-tu que je te dise d'autre…
Dois-je aussi rappeler que l'utilisation de MD5 ne constitue qu'une partie du raisonnement?
¹ C'est ce que fait hashcat, entre autres. Le craquage par force brute est limité à quelques caractères mais plus le temps passe, plus ce type de craquage est effectif. D'autres attaques, de type "rainbow table" sont également possibles. J'ignore si cette dernière est applicable ici mais dans tous les cas, les outils ne manquent pas.
J'ai reçu une réponse de leur part et ce qui n'était que spéculation de ma part est maintenant confirmé: les 32 caractères correspondent bel et bien à un hash MD5, que les experts en cryptographie déconseillent depuis plus de vingt ans. Ça prouve qu'ils utilisent, comme beaucoup d'autres (ce qui ne les dédouane pas pour autant), qu'ils utilisent probablement plus d'une technologie obsolète depuis plus de vingt ans, soit sans s'être jamais posé la question soit sans y accorder le moindre intérêt.
Ça me fait marrer, ces affirmations de parano sur ma personne… Vraiment.
Un sarcasme sur le "l'informatique n'est qu'un outil au même titre qu'un stylo ou qu'un tournevis".
OK, je vois ce que tu veux dire. C'est un faux débat. La vraie question est d'apprendre à respecter les autres et la vie. Un fabricant d'outils n'est pas responsable des actes de ceux qui les achètent. Chacun est responsable de ses propres actes. Le détournement de responsabilité est un symptôme de notre société moderne où on rejette plus facilement la faute sur d'autres personnes, souvent en plus petit nombre, parce qu'elles sont plus faciles à atteindre. Ça n'en est pas moins illégitime.
Les auteurs de logiciels libres n'ont, en conséquence, pas la responsabilité de l'utilisation qui sera faite de leurs logiciels, même s'ils sont utilisés pour tuer. S'ils se sentent coupables, ce n'est pas pour autant que leur responsabilité est effective.
Un informaticien ne se contente sans doute pas d'une "sécurité par l'obscurité"
Si tu parles pour moi, en effet :-) .
mais en fait personne n'ira fouiller là-dedans juste pour récupérer une adresse et une consommation
C'est bien l'erreur commise par ceux qui ne comprennent pas: il semble logique que quiconque juge ces données inutiles n'ira probablement pas y mettre son nez. Ceci dit, l'importance des données personnelles, c'est subjectif — mes données personnelles n'intéressent probablement pas grand monde, autre que moi. Mais de là à dire que personne n'y mettra son nez, je ne serais pas aussi catégorique — l'intérêt porté aux données n'est qu'un aspect des nombreuses fuites qui ont déjà été constatées. Le RGPD définit un cadre légal, obligatoire, quelle que soit l'importance ou la pertinence qu'on y voit ou qu'on perçoit des données. Et heureusement, d'ailleurs!
Même si ce risque peut être perçu comme étant très faible, la possibilité d'une fuite augmente avec la durée de rétention. De même, il suffit d'une seule erreur et d'une seule fuite pour compromettre, et parfois de manière irréparable, la situation des abonnés.
De toutes façons le RGPD est formel: toute donnée privée/personnelle, quelle qu'elle soit et, surtout, quelle qu'en soit la pertinence perçue, doit être protégée par des mesures "adéquates"¹ — le RGPD ne précise pas ce que doit être "adéquates". Mais ce ne devrait être ignoré de personne: la sécurité par l'obscurité, sur le long terme, ça ne tient pas. Or c'est précisément de cela qu'il s'agit ici.
¹ Je simplifie, bien évidemment, ce serait trop long d'énumérer tous les cas, que je suis loin de connaître, que le RGPD définit comme étant une donnée personnelle.
Je ne trouve pas choquant qu'un sous-traitant en vienne à manipuler des données personnelles […]
Bien sûr, ça ne l'est pas. C'est une situation habituelle et bien normale, que le RGPD réglemente aussi. Ce que je voulais dire c'est qu'on passe d'un cas de figure relativement "classique", où une société gère les données personnelles dans le cadre de son service, à un cas de sous-traitance, plus complexe, avec tout ce que le RGPD implique comme contraintes, pour le client et le sous-traitant. On passe d'une série de contraintes "simples" à gérer pour un acteur à un ensemble de contraintes supplémentaires liées à la protection des échanges de données avec le sous-traitant, leur stockage, la stratégie de rétention, les droits d'accès, le respect de la confidentialité…
Le cadre du traitement des données par un sous-traitant est différent de celui où la société traite elle-même ses données. Le premier est plus contraignant que le second. Et dans ce cas-ci, il n'est pas possible de dire si le sous-traitant a eu accès aux données personnelles ou non. C'est un cas de manque de transparence, couvert aussi par le RGPD, si j'ai bonne mémoire.
Je n'ai pas percuté tout de suite mais ce que tu montres là va bien plus loin que la question du simple accès à des données personnelles sur un site internet. Deux options, au moins, se présentent:
soit Lampiris a rempli soi-même les champs du modèle vidéo, auquel cas ils n'ont pas eu à exfiltrer des données personnelles;
soit ils ont sous-traité ce travail à 87seconds et là, se posent toutes les questions du RGPD quant à la sous-traitance et, en particulier, le traitement des données personnelles par un sous-traitant.
Rien que ce que tu viens d'indiquer soulève encore plus de questions que le simple constat que j'ai fait en ce qui me concerne, ainsi que les autres clients de Lampiris ayant reçu ou qui prochainement recevront une facture de régularisation accompagnée de cette vidéo.
Posté par FantastIX .
En réponse au journal Les cons? ça ose tout!.
Évalué à 3.
Dernière modification le 20 octobre 2019 à 10:56.
Oui, c'est exactement ça! Juste que celle que j'ai reçue est en français. Ça confirme ce que je soupçonnais: ce genre de vidéo n'est pas destiné à un client unique (moi, sinon, j'en aurais effectivement pas fait un patacaisse) mais à de nombreux clients — une régularisation est liée aux prix de l'électricité mais aussi à l'adaptation des factures, prévisionnelles, à la consommation passée, ce qui signifie que tous les clients sont potentiellement impliqués par cette vidéo.
Il est donc plausible que derrière le dossier de l'URL en question, se trouvent plusieurs vidéos et pas seulement celle qui m'était destinée. Donc qu lieu d'avoir une probabilité ridiculement faible de trouver une URL valide, on se retrouve_rait_ avec une probabilité non négligeable de tomber sur des informations personnelles d'abonnés quelconques.
Très sincèrement merci pour avoir trouvé la société qui s'est chargée de la campagne. Je vais tenter de les contacter afin d'investiguer davantage.
Posté par FantastIX .
En réponse au journal Les cons? ça ose tout!.
Évalué à 6.
Dernière modification le 19 octobre 2019 à 00:48.
J'ai l'impression que l'auteur du journal commence à […]
T'as raison, c'est juste une impression. Et en matière de psychologie, ton système de déduction n'est pas encore au point. Si je te dis que tu te plantes, tu vas me demander de te le démontrer?
Des arguments, des démonstrations, pour des sujets où tout le monde n'est pas en phase avec toi, est-ce trop demander?
Pour prendre un exemple, je t'ai demandé si tu confondais pas authentification et identification, tu n'as pas répondu. Et en plus de ça tu te permets depuis le début de penser à ma place, de prétendre ce que je suis ou ce que je ne suis pas, de considérer mes relations avec les autres, ça me fait tellement marrer un tel niveau d'auto-suffisance… Bien sûr, tu me répondras sans doute que venant de quelqu'un qui traite de cons "tout ceux qui ne sont pas comme lui" c'est gonflé, pas vrai? Ironiquement, je ne serais pas nécessairement en désaccord avec toi sur ce point. Mais ne va pas trop vite en déduction, par contre car on est deux dans ce cas.
Pourquoi voudrais-tu que je fasse l'effort de te satisfaire quand toi tu ne prends même pas la peine de répondre à ma question? Quand tu m'auras répondu, peut-être qu'on pourra passer à la suite, pour autant que tu cesses de chercher à me coller des qualificatifs et laisse de côté ta condescendance. Tu peux faire ça?
Ce n'est pas que je cherche à me la jouer œil-pour-œil mais ton style d'argumentation me laisse complètement pantois et, tant qu'à présent, quoi que je réponde tu ignores, déformes, dédaigne ou tourne en ridicule ce que je raconte; c'est pas très engageant — est-ce qu'au moins une fois dans ta vie, tu as envisagé te répondre à toi-même sur le ton et le vocabulaire que tu emploies? En d'autres termes, toi, tu ne m'as pas convaincu que je réussirais à ce que mes explications servent à quoi que ce soit, seraient entendues, non déformées et que peut-être, il serait possible que, toi, tu te trompes. C'est facile de prétendre que je ne démontre rien de manière unilatérale quand c'est toi qui décide de ne pas entendre. Jamais, à aucun moment, tu ne prends la peine de t'interroger si ton interprétation de ce que je raconte est conforme au message que j'essaie de faire passer. Et tu me donnes des leçons d'objectivité? Là, je comprends plus…
Mon diagnostic, c'est que toi et moi on est dans une impasse d'argumentation. On peut en rester là, moi je m'en tamponne. Je ne ressens pas le besoin de te prouver quoi que ce soit et tu ne fais pas partie de mon cercle privé. C'est déjà fatiguant pour moi de répondre à un flot et un style d'argumentation comme le tien, sans parler de ta panoplie bien rodée d'attaques personnelles et de ton expertise dans l'art du sophisme. Ce n'est pas une stratégie productive que de tourner son adversaire et ses propos au ridicule avant de s'assurer qu'on a bien compris ce qu'il raconte.
[^] # Re: Débits inadaptés
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 2.
Hmmm… ça m'intéresse. Comment faire pour détecter des microcoupures éventuelles ou des problèmes de pairage, tout ça?
[^] # Re: Fréquence occupée ?
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 2.
C'est pour cela que j'ai précisé habiter dans une région relativement non polluée — du moins depuis quelques années. Cependant ce genre de déboire me suit depuis que je me suis hasardé à l'utilisation de Bluetooth.
Ça me paraît malgré tout fort peu probable là où je vis. J'ai déjà vu des potes faire fonctionner leur appareillage sous Bluetooth dans un environnement que je sais très pollué.
Ceci dit, rien ne m'empêche de le vérifier. Mais j'ignore comment mesurer cette pollution gigahertzienne de manière relativement fiable.
Ça n'expliquerait pas mes déboires sur le long terme…
[^] # Re: Chez moi ça marche©
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 3. Dernière modification le 25 novembre 2019 à 11:42.
J'ai en effet entendu ça aussi (ou plutôt lu). Dans mon cas, le téléphone est Android et tous les ordinateurs sont sous [GNU/]Linux.
Ceux que tu énumères sont-ils fabriqués par la même société ou par des sociétés qui ont des accords commerciaux entre elles? Je pose la question car ça me paraît logique que des accords commerciaux, par exemple, amènent à partager des infos sur les protocoles sous clause de confidentialité. Si c'est la même société qui fabrique le tout, alors que ça fonctionne bien est une évidence, commercialement, en tout cas.
Hmmm… j'ai fais ça aussi, passer par le sans-fil… jusqu'au jour où j'en ai eu ras la casquette de changer les piles au bout de deux à huit semaines et que les dispositifs déconnent à tout berzingue au bout de quelques jours — et je ne parle pas du lag, intermittent, à fracasser son clavier au mur tellement il a des ratés¹! Et je ne compte pas non plus le nombre d'appareils à piles dont la gestion de l'énergie est catastrophique, au point qu'on arrive à jeter, sans s'en douter, des piles qui ont encore jusqu'à 80% de réserve disponible (je ne parle pas de l'effet Batterizer). Suis revenu à clavier/souris filaires, même si ça doit traverser le salon!
Bon, j'exagère un chouïa, ma table (avec le clavier) n'est distante du PC que d'un mètre environ mais ça te donne une idée de mon état d'esprit. Pour le coup, je me sers d'un clavier Apple car c'est un des rares modèles, pas trop chers, à posséder au moins un hub USB. Pratique pour la souris. Et puis c'est plus robuste que le plastique, aussi… (Mais non, je tape pas dessus! Enfin… plus maintenant.)
¹ Ça sent le vécu, hein?
[^] # Re: Photos -> USB
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 10.
Sans vouloir verser dans la théorie du complot, perds quand-même pas de vue qu'«ils» ont tout intérêt aussi, comme je l'insinue ailleurs, à favoriser le tout-au-cloud même pour une liaison aussi triviale que téléphone-PC… J'ai envie de reformuler: «ils rendent plus simples à l'utilisation les transferts qui font un gourmand détour par internet».
[^] # Re: Photos -> USB
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 7. Dernière modification le 25 novembre 2019 à 11:08.
En effet. Et ça n'a rien d'anormal. Je pense que "simplicité" n'est pas le bon terme à employer. Comme le fait justement remarquer Zenitram à propos des gens "normaux" (je pense et j'espère avoir compris ce qu'il veut dire par là), c'est la liaison vers le cloud qui semble être l'usage le plus répandu (le plus promu, aussi).
Maintenant, quant à parler de simplicité, la question est: «pour qui?»
Peut-être que passer par le cloud semble "simple" mais est-ce que c'est parce que les applications s'appuient sur des protocoles réseau, bien connus, mis en œuvre et en place depuis des décennies plutôt que sur une cata ambulante comme Bluetooth, qui change aussi souvent qu'un administrateur réseau changerait de SLIP¹? En ce cas, la simplicité (je parlerais plutôt de confort), c'est celle offerte aux développeurs et aux intégrateurs, pas forcément celle de l'utilisateur. En revanche, possible qu'on ait rendu cette fonctionnalité (via la pile réseau) simple à l'utilisation exprès pour que tout passe par là (comme c'est déjà le cas dans l'informatique PC).
Ensuite, rien de surprenant à ce que les communications passent par Gogol, Mama Zone ou encore Appelle-le, vu ce qu'on sait de ces entreprises et de ce qu'elles font des données qu'elles collectent. Pour les géants de l'information, c'est pas que ce soit simple, c'est juste bien juteux de manipuler autant de données, personnelles ou non. Et la simplicité d'utilisation, c'est
la grainele confort qui attirele pigeonl'utilisateur. Personnellement, ça me tord une côte que mes fichiers fassent d'abord le tour de la planète en partant de chez moi avant d'y revenir…Ça aurait été tout aussi profitable (au moins pour l'utilisateur) de rendre simple à l'utilisation toute mise en œuvre applicative du protocole Bluetooth… pour autant que ce soit faisable, bien entendu. Apparemment, ça n'est pas le cas. Que ce soit voulu ou pas, c'est une autre histoire.
¹ Tout compte fait, suis pas certain que ce soit une bonne analogie…
[^] # Re: KDEConnect / GSConnect
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 2.
Je suis du côté sombre du miroir: je roule avec Xfce… C'est sur Blueman que je m'appuye/ais jusqu'à maintenant.
Depuis tout ce temps, il n'y a jamais eu que le transfert de fichiers qui m'ait été vraiment utile avec BT. Ce qu'on peut faire d'autre ne m'intéresse pas vraiment.
[^] # Re: Complexe
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 2.
Je suis parti en effet sur Blueman, que j'ai installé partout, à chaque fois, où j'ai pu le faire… sauf sur mon téléphone, bien entendu. Tant qu'à présent j'ai des résultats plus cohérents avec les versions "ligne de commande" des outils comme
bluetoothctrl.En fait, c'est uniquement le transfert de fichiers qui m'est (ou me serait) utile avec Bluetooth. À la limite, s'il est possible de recevoir des fichiers rien qu'avec les outils en ligne de commande, je m'en contenterai. Et alors exit
blueman, façon «Keep It Strictly Straight».[^] # Re: Murs absorbants ? ou CPL ?
Posté par FantastIX . En réponse au journal Bluetooth? C'est quoi pour une technologie de m***?. Évalué à 3.
Même lorsque les appareils sont distants de quelques dizaines de centimètres?
L'installation a moins de dix ans et il n'y a pas de CPL dans les parages — pas que je sache et pas chez moi en tout cas.
[^] # Re: Indisponibilité temporaire ? Ou ...
Posté par FantastIX . En réponse au message Mise à jour raspbian échoue avec un timeout, impossible de continuer. Évalué à 2.
Je viens de terminer une mise à jour, c'est réussi. Par contre, j'ai toujours le message d'erreur:
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Error: Timeout was reached
Comment puis-je savoir exactement à quoi est dû ce message? J'imaginais que c'était le second lien mais là je n'en suis plus très sûr.
[^] # Re: Indisponibilité temporaire ? Ou ...
Posté par FantastIX . En réponse au message Mise à jour raspbian échoue avec un timeout, impossible de continuer. Évalué à 2.
Merci. Le paquet est bien accessible. Je vais réessayer, c'est que je commençais à désespérer à force, au bout de plusieurs heures.
[^] # Re: Vie privée vraiment ?
Posté par FantastIX . En réponse à la dépêche Firefox 70. Évalué à 2.
Il y a d'ailleurs une excellente vidéo du Dr Mike Pound là-dessus.
[^] # Re: Si on arrêtait le mensonge et la diffamation ?
Posté par FantastIX . En réponse à la dépêche Meta‑Press.es : un méta‑moteur de recherche pour la presse dans votre navigateur. Évalué à 2.
Ouais, t'as raison. Demain, j'arrête. Puis c'est pas comme si ça avait quoi que ce soit à voir avec la réalité ;-) …
[^] # Re: Si on arrêtait le mensonge et la diffamation ?
Posté par FantastIX . En réponse à la dépêche Meta‑Press.es : un méta‑moteur de recherche pour la presse dans votre navigateur. Évalué à 2.
Je me sens floué, volé, bafoué. Il y a un tas d'idées que j'ai eues et que des sociétés, qui ne m'ont même pas consulté et avec lesquelles je n'ai même pas eu d'échange, ont reprises et commercialisées en se faisant un tas de tunes avec ça. Je leur intenterais bien un procès pour manque à gagner, tiens. Ou mieux, je vais monter une société de lobbying et harceler les députés Européens pour faire élaborer un règlement en ma faveur. Oooh, je sens là une activité bien juteuse!
-->[]
# Notepad++ conspué par des militants chinois...
Posté par FantastIX . En réponse à la dépêche Revue de presse de l’April pour la semaine 44 de l’année 2019. Évalué à 5.
J'ai visionné le reportage Arte sur les Ouïghours. L'usage du conditionnement par les autorités chinoises sur ces gens est consternant d'horreur, tout comme celui de la technologie pour le pistage et l'identification systématique des citoyens. Et que ce genre de totalitarisme numérique se répande aussi en Europe (reconnaissance faciale, quelqu'un?) me fait froid dans le dos. De toute évidence, ce n'est pas dans le même but, hein? Ici c'est pour notre bien.
Mais bien sûr…
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 0.
J'ai moins pris ça pour une attaque personnelle que pour une répétition ad nauseam. Considérons l'incident clos.
Oui, tout-à-fait. C'est bien pour ça que j'ai ajouté: «Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.» Tu n'auras pas manqué de relever ce passage, j'espère? C'est juste que MD5, comparé à tout autre algo plus sophistiqué, rend terriblement plus rapide la déduction du schéma d'entrée par force brute.
Hein? Si je les juge, c'est pour leur méconnaissance (que je me dois de présumer apparente, bien que les indices ne me paraissent pas favorables) des mesures de sécurité (eu égard aux échanges que j'ai déjà eu avec eux, genre, je résume, «on utilise MD5 donc c'est sécuris黹), notamment à travers leur idée reçue sur MD5 et son emploi dans un contexte qui aurait dû nécessiter autre chose qu'une fonction de hash, qui plus est aussi trivialement réfutable et contestable que celle-là.
Ce serait minimiser mes propos et beaucoup trop simpliste que de les réduire à "MD5=caca, bouh Lampiris!" Ça va bien plus loin que ce simple constat.
Le discours qu'ils m'ont tenu en dit long sur leur manque de maîtrise du chapitre sécurité et pas qu'en raison de l'utilisation de MD5. Je ne vais évidemment pas publier ici nos échanges.
Ce n'est pas un procès qui m'intéresse, ça n'est pas constructif (oui, je sais, les traiter de cons non plus). Ce qui m'intéresse c'est qu'ils prennent plus de précaution à l'avenir pour sécuriser des données personnelles, quitte à réfléchir davantage sur la pertinence de leur utilisation dans les futures campagnes.
Bon, j'imagine qu'il vaut mieux en rester là, alors que je vois passer l'avertissement Goodwin de Linuxfr… J'ai entendu tes arguments et tu as entendu les miens, ça me convient.
¹ … ainsi qu'à la nonchalance généralisée des entreprises belges que nous avons contactées lors de mon expérience avec le RGPD dans le cadre des activités au sein d'une société à la construction de laquelle j'avais participé. La quasi totalité ignorait même l'existence du RGPD et ne s'en montrait que peu concernée. Les sociétés luxembourgeoises se sont avérées infiniment plus réceptives à ce sujet. Je pars avec un a priori, certes mais rien ne prouve qu'il est infondé.
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à -1.
C'est bon? Il y en a suffisamment à ton goût?
Première remarque: peux-tu, s'il te plaît cesser ce genre de réflexion grotesque et irritante? Tu n'es pas dans ma tête et tu n'as en aucun cas le droit de me juger sur des propos que tu penses avoir compris ou pas. Tu ne me connais absolument en rien et tu peux te dispenser ce genre de commentaire.
J'ai parfaitement compris le chapitre sur les collisions. Ce n'est pas de cela que je parle ici.
Ça n'est pas suffisant pour affirmer haut et fort que le niveau de sécurité est suffisant.
Bon. Je vais tâcher de rester calme et d'ignorer ce lancinant agacement de ta remarque concernant mes capacités à comprendre. À mon tour d'être didactique.
Ce que j'entends par "craquer une URL" est un raccourci de langage, je pensais que tu aurais saisi.
L'obtention ou l'interception d'une seule URL, révélant l'utilisation de MD5 a les conséquences suivantes: s'il est possible de retrouver la donnée d'entrée, il est probable qu'alors le schéma de cette donnée corresponde à des données identifiables par un autre moyen. Avant de me voler dans les plumes, je suis conscient qu'il s'agit de pure spéculation… jusqu'à présent. Or ce qui n'était que pure spéculation de ma part quant à MD5 s'est avéré parfaitement exact. Réfléchis donc un rien avant de balancer à la poubelle mon argumentation, ainsi que ce qui pourrait bien me faire dire ça. Tu ne connais (probablement) pas Lampiris (supposition de ma part, jusqu'à preuve du contraire) ni leurs équipes informatiques ni l'état de leurs connaissances en termes de sécurité (moi non plus, objecteras-tu, n'est-ce pas?) et tu me connais encore moins (ça, c'est une certitude).
Si le craquage d'un seul hash permet de reconstituer la partie hashée de l'URL (c-à-d la donnée d'entrée), alors il est possible qu'en générant des données d'entrée, répondant au même schéma, on aboutisse à l'URL de vidéos relatives à d'autres clients.
Or jusqu'à présent, rien ne permet d'être certain que la donnée d'entrée ne fasse pas moins de 32 caractères — je ne me contenterai pas d'une simple supposition, je te rassure. Et dans ce cas, la donnée d'entrée ayant servi à générer les 32 caractères d'une URL reçue (ou interceptée) peut très bien être retrouvée — craquer un hash MD5 d'une quinzaine de caractères par force brute est tout à fait possible dans des temps parfaitement raisonnables, surtout si on dispose de plusieurs semaines ou mois. D'autant plus que les données d'entrée sont — plus que probablement — alphanumériques et non binaires, ce qui réduit considérablement le nombre de possibilités d'entrée à évaluer (la surface d'attaque).
J'objecte quant à utiliser un nombre aléatoire, hashé via MD5: ce serait absurde. Une série de 32 caractères aléatoires aurait bien plus de sens. Quant à ce fameux nombre aléatoire que tu suggères, plus il est court, plus il a de chances d'être craqué par force brute en un temps relativement court, donc plus l'utilisation de MD5 est compromise. Et plus sa longueur se rapproche de 32, moins l'utilisation de MD5 a de sens par rapport à la génération de 32 caractères alphanumériques aléatoires. Sans compter que la suggestion d'utiliser un nombre aléatoire a encore moins de sens puisqu'elle réduit à 10 au lieu de 62 (10+2x26) le nombre de symboles à utiliser pour les combinaisons d'entrée, ce qui est encore plus facile à craquer.
Avec seulement 10 symboles (0 à 9), la longueur maximum "craquable" en un mois est de 17 avec le système que j'ai mentionné. Et si tous les codes d'entrées sont sur 17 chiffres (ou moins) on génère l'URL des vidéos de tous les clients en moins d'un mois… Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.
Combine avec ça que, des possibilités d'entrée à tester, on peut très bien éliminer les combinaisons aussi triviales que aaaaaaa*, bbbbb* etc. C'est ce genre de "divination" que les outils de craquage prennent parfaitement en charge.
Donc, en résumé: MD5 n'élimine pas la possibilité de retrouver une seule donnée d'entrée, ce qui pourrait amener à retrouver le schéma d'entrée, complet, du hashage, utilisé dans l'URL des vidéos, d'où la possibilité de retrouver, par synthèse, d'autres vidéos personnelles. En raison de l'utilisation qui a été faite de MD5, la robustesse de la sécurité des données personnelles en jeu ne dépend que de la longueur de la donnée d'entrée: plus la seconde est petite, plus la première se rapproche de zéro.
Or je soupçonne la longueur de cette donnée d'entrée d'être bien inférieure à 32. Je ne m'en tiendrai pas, comme je l'ai annoncé, à cette simple supposition.
L'importance que tu accordes aux données personnelles ou à leur volume n'entre pas en ligne de compte quant à l'obligation légale de les sécuriser et les moyens employés.
Mon propos est que l'utilisation de MD5, contrairement aux idées reçues, n'est pas une sécurisation suffisante comparé, par exemple, à un accès authentifié.
Bien. On se comprend au moins sur ce point.
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 0.
Et moi je pense que toi, tu n'as pas perçu l'importance de ce problème. Dans les faits, MD5 est déprécié depuis plus de 20 ans, ses faiblesses sont démontrées depuis tout aussi longtemps et son utilisation dans un but de sécurité est fortement découragée. En gros (voir la page man de md5sum, c'est déjà un début):
ou encore:
C'est pas clair, ça?
Tel est aussi le message envoyé par les experts en cryptographie et en sécurité informatique (dont Bruce Schneier, tu peux aller vérifier). Tu n'as aucun effort à faire pour lire ça un peu partout. Libre à toi de l'ignorer mais prétendre que je ne comprends pas le concept et que je prouve que je ne sais pas de quoi je parle… ça me sidère!
Quelqu'un qui arrive encore aujourd'hui à justifier, envers et contre tout, l'utilisation de MD5 dans un contexte de sécurité est précisément quelqu'un qui ne sait pas de quoi il parle.
Pour craquer l'URL, le mauvais raisonnement consiste à prétendre que 32 caractères aléatoires représentent un nombre de possibilités trop élevé. Pourquoi? Parce que c'est raisonner à l'envers.
Puisqu'il ne faut que quelques secondes à quelques minutes pour craquer un hash MD5 avec du matériel commun, il suffit de générer autant de suites (dont la taille est limitée à quelques caractères), que l'on passe à MD5¹ pour multiplier les chances de tomber sur une URL valide, n'importe laquelle. Un des (nombreux) problèmes de MD5 est que plus la donnée "hashée" est petite, plus le temps nécessaire pour la craquer devient court. Et en dessous d'une certaine longueur, qui augmente à mesure que le temps passe, ce temps est ridiculement court, de l'ordre de la seconde.
En un mois, soient environ 2.500.000 secondes, et si on considère un système capable de générer 40 milliards de hash MD5 à la seconde, ça fait 10¹⁷ hashes par force brute au bout d'un mois. Et encore, là, on est sur un système qui date de 2016…
Ce n'est qu'une question de patience: à mesure que le temps passe, n'importe quelle URL finira craquée. Or il suffit d'une seule fuite, de craquer un seul de ces codes MD5 pour que la sécurité de toutes les données personnelles soit compromise. Et le nombre de clients ne se compte pas en dizaines de milliers mais bien plus que ça.
Voilà, on y arrive: c'est exactement le point! MD5 1) ne protège pas contre la détection de la source employée et 2) la sécurité d'un système doit être inchangée même en connaissant l'algorithme (voir l'article concernant "la sécurité par l'obscurité" sur Wikipédia, pour commencer). Or là, ce n'est pas le cas.
LOL! En fait tu en viens exactement, de manière détournée, à dire la même chose que moi: utiliser exclusivement une fonction de hashage dans une URL pour l'accès, sur un site public, à des données personnelles et privées est une mesure insuffisante.
Que veux-tu que je te dise d'autre…
Dois-je aussi rappeler que l'utilisation de MD5 ne constitue qu'une partie du raisonnement?
¹ C'est ce que fait hashcat, entre autres. Le craquage par force brute est limité à quelques caractères mais plus le temps passe, plus ce type de craquage est effectif. D'autres attaques, de type "rainbow table" sont également possibles. J'ignore si cette dernière est applicable ici mais dans tous les cas, les outils ne manquent pas.
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à -2.
J'ai reçu une réponse de leur part et ce qui n'était que spéculation de ma part est maintenant confirmé: les 32 caractères correspondent bel et bien à un hash MD5, que les experts en cryptographie déconseillent depuis plus de vingt ans. Ça prouve qu'ils utilisent, comme beaucoup d'autres (ce qui ne les dédouane pas pour autant), qu'ils utilisent probablement plus d'une technologie obsolète depuis plus de vingt ans, soit sans s'être jamais posé la question soit sans y accorder le moindre intérêt.
Ça me fait marrer, ces affirmations de parano sur ma personne… Vraiment.
[^] # Re: Serment d'Hippopotame
Posté par FantastIX . En réponse à la dépêche Revue de presse de l’April pour la semaine 40 de l’année 2019. Évalué à 3.
OK, je vois ce que tu veux dire. C'est un faux débat. La vraie question est d'apprendre à respecter les autres et la vie. Un fabricant d'outils n'est pas responsable des actes de ceux qui les achètent. Chacun est responsable de ses propres actes. Le détournement de responsabilité est un symptôme de notre société moderne où on rejette plus facilement la faute sur d'autres personnes, souvent en plus petit nombre, parce qu'elles sont plus faciles à atteindre. Ça n'en est pas moins illégitime.
Les auteurs de logiciels libres n'ont, en conséquence, pas la responsabilité de l'utilisation qui sera faite de leurs logiciels, même s'ils sont utilisés pour tuer. S'ils se sentent coupables, ce n'est pas pour autant que leur responsabilité est effective.
[^] # Re: Questions
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 4.
Si tu parles pour moi, en effet :-) .
C'est bien l'erreur commise par ceux qui ne comprennent pas: il semble logique que quiconque juge ces données inutiles n'ira probablement pas y mettre son nez. Ceci dit, l'importance des données personnelles, c'est subjectif — mes données personnelles n'intéressent probablement pas grand monde, autre que moi. Mais de là à dire que personne n'y mettra son nez, je ne serais pas aussi catégorique — l'intérêt porté aux données n'est qu'un aspect des nombreuses fuites qui ont déjà été constatées. Le RGPD définit un cadre légal, obligatoire, quelle que soit l'importance ou la pertinence qu'on y voit ou qu'on perçoit des données. Et heureusement, d'ailleurs!
Même si ce risque peut être perçu comme étant très faible, la possibilité d'une fuite augmente avec la durée de rétention. De même, il suffit d'une seule erreur et d'une seule fuite pour compromettre, et parfois de manière irréparable, la situation des abonnés.
De toutes façons le RGPD est formel: toute donnée privée/personnelle, quelle qu'elle soit et, surtout, quelle qu'en soit la pertinence perçue, doit être protégée par des mesures "adéquates"¹ — le RGPD ne précise pas ce que doit être "adéquates". Mais ce ne devrait être ignoré de personne: la sécurité par l'obscurité, sur le long terme, ça ne tient pas. Or c'est précisément de cela qu'il s'agit ici.
¹ Je simplifie, bien évidemment, ce serait trop long d'énumérer tous les cas, que je suis loin de connaître, que le RGPD définit comme étant une donnée personnelle.
[^] # Re: Questions
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 1.
Bien sûr, ça ne l'est pas. C'est une situation habituelle et bien normale, que le RGPD réglemente aussi. Ce que je voulais dire c'est qu'on passe d'un cas de figure relativement "classique", où une société gère les données personnelles dans le cadre de son service, à un cas de sous-traitance, plus complexe, avec tout ce que le RGPD implique comme contraintes, pour le client et le sous-traitant. On passe d'une série de contraintes "simples" à gérer pour un acteur à un ensemble de contraintes supplémentaires liées à la protection des échanges de données avec le sous-traitant, leur stockage, la stratégie de rétention, les droits d'accès, le respect de la confidentialité…
Le cadre du traitement des données par un sous-traitant est différent de celui où la société traite elle-même ses données. Le premier est plus contraignant que le second. Et dans ce cas-ci, il n'est pas possible de dire si le sous-traitant a eu accès aux données personnelles ou non. C'est un cas de manque de transparence, couvert aussi par le RGPD, si j'ai bonne mémoire.
[^] # Re: Questions
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 3.
Je n'ai pas percuté tout de suite mais ce que tu montres là va bien plus loin que la question du simple accès à des données personnelles sur un site internet. Deux options, au moins, se présentent:
Rien que ce que tu viens d'indiquer soulève encore plus de questions que le simple constat que j'ai fait en ce qui me concerne, ainsi que les autres clients de Lampiris ayant reçu ou qui prochainement recevront une facture de régularisation accompagnée de cette vidéo.
[^] # Re: Serment d'Hippopotame
Posté par FantastIX . En réponse à la dépêche Revue de presse de l’April pour la semaine 40 de l’année 2019. Évalué à 2. Dernière modification le 20 octobre 2019 à 11:17.
Peux-tu développer? J'avoue ne pas savoir pas si ce que tu écris doit être pris sur le ton du sarcasme ou d'un simple relevé factuel. Ou autre.
[^] # Re: Questions
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 3. Dernière modification le 20 octobre 2019 à 10:56.
Oui, c'est exactement ça! Juste que celle que j'ai reçue est en français. Ça confirme ce que je soupçonnais: ce genre de vidéo n'est pas destiné à un client unique (moi, sinon, j'en aurais effectivement pas fait un patacaisse) mais à de nombreux clients — une régularisation est liée aux prix de l'électricité mais aussi à l'adaptation des factures, prévisionnelles, à la consommation passée, ce qui signifie que tous les clients sont potentiellement impliqués par cette vidéo.
Il est donc plausible que derrière le dossier de l'URL en question, se trouvent plusieurs vidéos et pas seulement celle qui m'était destinée. Donc qu lieu d'avoir une probabilité ridiculement faible de trouver une URL valide, on se retrouve_rait_ avec une probabilité non négligeable de tomber sur des informations personnelles d'abonnés quelconques.
Très sincèrement merci pour avoir trouvé la société qui s'est chargée de la campagne. Je vais tenter de les contacter afin d'investiguer davantage.
Par curiosité: comment as-tu trouvé celle-là?
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à 6. Dernière modification le 19 octobre 2019 à 00:48.
T'as raison, c'est juste une impression. Et en matière de psychologie, ton système de déduction n'est pas encore au point. Si je te dis que tu te plantes, tu vas me demander de te le démontrer?
Pour prendre un exemple, je t'ai demandé si tu confondais pas authentification et identification, tu n'as pas répondu. Et en plus de ça tu te permets depuis le début de penser à ma place, de prétendre ce que je suis ou ce que je ne suis pas, de considérer mes relations avec les autres, ça me fait tellement marrer un tel niveau d'auto-suffisance… Bien sûr, tu me répondras sans doute que venant de quelqu'un qui traite de cons "tout ceux qui ne sont pas comme lui" c'est gonflé, pas vrai? Ironiquement, je ne serais pas nécessairement en désaccord avec toi sur ce point. Mais ne va pas trop vite en déduction, par contre car on est deux dans ce cas.
Pourquoi voudrais-tu que je fasse l'effort de te satisfaire quand toi tu ne prends même pas la peine de répondre à ma question? Quand tu m'auras répondu, peut-être qu'on pourra passer à la suite, pour autant que tu cesses de chercher à me coller des qualificatifs et laisse de côté ta condescendance. Tu peux faire ça?
Ce n'est pas que je cherche à me la jouer œil-pour-œil mais ton style d'argumentation me laisse complètement pantois et, tant qu'à présent, quoi que je réponde tu ignores, déformes, dédaigne ou tourne en ridicule ce que je raconte; c'est pas très engageant — est-ce qu'au moins une fois dans ta vie, tu as envisagé te répondre à toi-même sur le ton et le vocabulaire que tu emploies? En d'autres termes, toi, tu ne m'as pas convaincu que je réussirais à ce que mes explications servent à quoi que ce soit, seraient entendues, non déformées et que peut-être, il serait possible que, toi, tu te trompes. C'est facile de prétendre que je ne démontre rien de manière unilatérale quand c'est toi qui décide de ne pas entendre. Jamais, à aucun moment, tu ne prends la peine de t'interroger si ton interprétation de ce que je raconte est conforme au message que j'essaie de faire passer. Et tu me donnes des leçons d'objectivité? Là, je comprends plus…
Mon diagnostic, c'est que toi et moi on est dans une impasse d'argumentation. On peut en rester là, moi je m'en tamponne. Je ne ressens pas le besoin de te prouver quoi que ce soit et tu ne fais pas partie de mon cercle privé. C'est déjà fatiguant pour moi de répondre à un flot et un style d'argumentation comme le tien, sans parler de ta panoplie bien rodée d'attaques personnelles et de ton expertise dans l'art du sophisme. Ce n'est pas une stratégie productive que de tourner son adversaire et ses propos au ridicule avant de s'assurer qu'on a bien compris ce qu'il raconte.