votre avatar Abonné

Fang9559

est avec nous depuis le 5 avril 2015 ❤️

10 commentaires

Le 20/09/2023 à 05h 51

Vidéo sur la publication scientifique :



DATA GUEULE : Privés de savoir ?

Le 25/03/2023 à 05h 00

Cela me rappelle le comportement de Ms Word (il y a quelque temps) qui ajoutait les informations de modification à la fin du fichier Word si on enregistre le fichier simplement. (le fichier devenait énorme)



pour éviter cela, il fallait faire un “Enregistrer sous…” pour purger les anciennes données….



Comme quoi l’histoire se répète….
:mad2:

Le 22/02/2023 à 06h 44

Salto est arrivé trop tard sur un marché déjà dominé pour la concurrence. (mais avant, il n’y avait pas de preuve de rentabilité pour les “investisseurs”)



Si l’on ajoute à cela la chronologie de média, la copie privée, un catalogue pauvre
et un public formaté par les séries US depuis des années…



Note : Je me demande, combien d’opportunités n’ont pas vu le jour en raison d’investissement frileux et de recherche de rentabilité immédiate.

Le 20/02/2023 à 18h 45

Hum si le budget ne part pas en rapports et études Bullshit. Car une telle manne va surement attirer pas mal de cabinets de conseil en tout genre. (surement, nouvellement spécialiste de la question)

Le 02/02/2023 à 21h 35

Voici Une vidéo de la chaine DATA GUEULE sur le sujet



youtube.com YouTube



6 ans déjà…

Le 31/01/2023 à 06h 53


SebGF a dit:


J’ai un doute que ça fonctionne si le fichier est synchro entre plusieurs appareils.


Je pense que la fonction est encore plus justifiée si la base est partagée par plusieurs appareils ==> multiples appareils => plus de surface d’attaque pour cette faille.



Dans ce cas, il faut valider les fichiers de conf de chaque appareil (ou simplement de la section trigger) (une entrée par appareil?)



Une autre solution est de permettre d’invalider le lancement des triggers dans la conf de la base.



Note ; l’accès à la machine de l’utilisateur pourrait permettre d’ajouter aussi des plugin-ins non ?

Le 31/01/2023 à 06h 29

Si le hash n’est pas identique alors désactivation des fonctions à risques (trigger) + invite de l’utilisateur à vérifier la configuration.



Note : dans une entreprise, il y a un certain nombre de personnes ayant accès au compte local des utilisateurs (le support de proximité, le admins système…). il leur est donc possible de modifier le fichier pour l’export des mdp de l’utilisateur. (qu’il n’a pas le besoin d’en connaître)
….Oups point déjà évoqué

Le 31/01/2023 à 05h 56

Une solution possible serait le stockage d’un hash du fichier de config dans la base. Celui-ci sera utilisé pour valider le fichier de config avant application.



À voir si cela peut être appliqué avec plusieurs bases…

Le 05/04/2015 à 08h 42

Quel est la différence avec cet amendement :

http://www.senat.fr/amendements/commissions/2014-2015/300/Amdt_COM-746.html

Qui semble retiré