YPMN
Messages postés98Date d'inscriptionvendredi 4 juin 2004StatutMembreDernière intervention20 août 2012
-
10 mars 2007 à 22:50
YPMN
Messages postés98Date d'inscriptionvendredi 4 juin 2004StatutMembreDernière intervention20 août 2012
-
11 avril 2007 à 16:24
salut!
après observation à la fin d'une compulation puis deploiement et empaquetage au moyen de l'outil par defaut de Vb6, je me suis rendu compte que dans le repertoire que j'avais designé pour créer l'exécutable, Ma Base de données s'y retrouve comme voulu; mais le constat amer est que cette base de données faite en access est premièrement visible, (elle dans son icone d'access connue de tous...) ainsi, ne court - elle un risque contre un mal intentionnée qui peux la supprimer ou la modifier dans access s'il parvient à pirater le mot de pase ? n'y a t-il pas des solutions contre cela si vraiment mon constat est un vrai problème? par exemple, ne peut - on pas présenter la base de données sous une forme compréssée ou bréf non réconnaissable, quoi à l'exécution ou après deploiement et empaquetage?
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 10 mars 2007 à 22:57
Ben
C'est sur
Ta base access, ouvrable par access, aura les ptotections d'access et pas des protections de VB !
Il ne servirait par ailleurs pas à grand chose de déguiser son extension en associant cette "extension maison" à Access ! Celui qui serait capable de violer la protection d'Access le serait encore plus de déterminer, en "deux coups de cuillère à pot", où se trouve cachée cette base de donnée et sous quel nom
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 11 mars 2007 à 08:31
Bonjour,
J'avais également pensé à un chiffrement des données, mais ceci n'empêcherait certes pas :
"...elle un risque contre un mal intentionnée qui peux la supprimer ou la modifier dans access s'il parvient à pirater le mot de pase ?..."
lemoret
Messages postés37Date d'inscriptionvendredi 10 septembre 2004StatutMembreDernière intervention11 mars 2007 11 mars 2007 à 09:13
C'est exact. Mais le risque de suppression n'est pas reservé à un fichier Access. Tout fichier externe à l'application peut être supprimé sauf en cas d'une stratégie de gestion de droits pas forcément évidente à mettre en oeuvre.
Vous n’avez pas trouvé la réponse que vous recherchez ?
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 11 mars 2007 à 09:32
Quelle que soit la stratégie mise en oeuvre, elle ne pourra l'être, exactement comme avec un coffre-fort, que par des identifications et des mots de passe.
Il est clair que celui qui a la combinaison d'un coffre-fort (obtenue légalement ou non) pourra l'ouvrir.
Or YPMN veut précisément pouvoir se protéger de l'utilisation d'un mot de passe "piraté"....et la problématique du piratage d'un mot de passe serait exactement la même, qu'il s'agisse utilisé pour l'ouverture d'une session Windows, de l'ouverture d'Access ou de toute autre application ou logiciel.
Je regrette beaucoup, mais :
1) Windows ne sait pas assurer une sécurité de bon niveau (il suffirait, par exemple, de démarrer la machine avec une disquette de boot) pour aller effacer ce que l'on veut et où l'on veut depuis DOS.
2) je ne vois aucun moyen, même avec des OS plus sécurisées, d'empêcher celui à qui on a donné une clef d'ouvrir la serrure qui fonctionne avec cette clef
3) je ne vois non plus aucun moyen d'empêcher celui qui, profitant d'une négligence, aurait fait une copie de cette clef, de s'en servir pour ouvrir la serrure qui va avec.
Je pense que YPMN espérait que les données de sa base pouvaient être incluses dans on exe. Ce n'est pas le cas et, même si la chose était réalisable :
1) les données disparaîtraient avec l'effacement de son exe.
2) on reviendrait (c'est le chien qui se mord la queue) à la problématique du mot de passe
3) rien n'empêcherait les gestes de malintention des possesseurs légitime d'un mot de passe.
4) Il deviendrait bien difficile de maintenir l'application (puisqu'il faudrait compiler à partir d'une source qui, elle, ne contiendrait pas les données)
5) et je préfère ne pas aller jusqu'aux problèmes que poseraient :
- a) les sauvegardes et restaurations
- b) les interventions "manuelles" qui pourraient s'avérer nécessaires sur la base de données elle-même...
Bref ! Aucune solution pour "permettre" sans "permettre" tout en "permettant"...que ce soit dans le domaine informatique ou dans tout autre domaine.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 11 mars 2007 à 09:59
On en revient toujours à l'éternel problème de la sécurité et du piratage, maintes fois débatus sur ce forum.
La sécurité absolue n'existe pas, sinon Microsoft ne se battrait pas contre les copies pirates de ses OS (Pour info, Vista censé avoir fait un grand pas en avant sur ce point, existait déjà en version pirate avant sa sortie officielle le 31 janvier et aujourd'hui, 1 mois 1/2 après sa sortie, les outils existent pour faire définitivement sauter les protections)
Tout le problème est de mettre en place une sécurité réaliste à la hauteur des enjeux engagés.
Si ton logiciel s'adresse à de simples utilisateurs ayant les droits idoines, et qui ne connaissent de l'informatique que le logiciel se lequel ils travaillent 8h/jour, mettre une usine à gaz comme protection ne sert à rien, un simple mot de passe et la base installée dans un sousrépertoire avec l'attribut caché voire système devrait suffire. Windows dans sa configuration de base masque ces fichiers/répertoires. Et ne pas connaitre l'existance du fichier est certainement la meilleure protection que tu peux lui offrir.
Si au contraire ton logiciel s'adresse à des pro de l'informatique, habituer à triturer le code et à trouver des moyens de rentrer, quelque soit la méthode de protection que tu trouveras, elle ne tiendra probablement pas longtemps.
Encore faut-il que cracker un logiciel (ou ici ta base de donnée) représente un interet quelconque pour le cracker
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
YPMN
Messages postés98Date d'inscriptionvendredi 4 juin 2004StatutMembreDernière intervention20 août 2012 12 mars 2007 à 10:30
Merci de vos réponses.
vous savez je suis convaincu qu'il nous faut encore beaucoup plus travailler. Alors quelque part, Sevyc64 parle de quelque chose qui m'attire l'attention: Y - a lieu depuis son exe de placer la base sous attribut: caché ? et même plus loin en lecture seule ? puisque oui, il en a fait allusion, je veux savoir.
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 12 mars 2007 à 10:58
Bonjour,
Si tu veux...
mais tu n'écarteras que des enfants de coeur, avec celà !
Sauf si tu inderdis à tes utilisateurs l'accès à explorer, à Excel, A Word, et j'en passe...
Car même depuis Word, on peut faire "sauter" ces protections sur un fichier....
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 12 mars 2007 à 11:33
certainemaent pas de lecture seule sur une base de données, elle serait pour le coup parfaitement inaccessible. D'ailleurs je n'ai jamais parlé de lecture seule.
Concernant les attributs Caché et Systeme, il faudrait tout d'abord faire l'essai pour voir si le moteur d'accès da ton appli arrive a acceder à la base de données. Personellement sur une base de données je n'ai jamais fait l'essai (jamais rencontré cette situation).
Les fichiers systèmes ou cachés ne sont pas affiché de base par l'explorateur. pour les afficher il faut le configurer explicitement dans les options de celui-ci. Il y a de forte chance que sur un pc de configuration basique (comme celui de tante simone par exemple) ces options n'aient pas été changées. Il en va tout autrement sur des pc de configuration plus évoluées comme par exemple des pc de développeurs ou généralement les utilisateurs (dont je suis le premier) aiment bien avoir la maitrise totale de ce qui se passe sur leur disque dur. Restera dans ce cas la barrière du mot de passe.
Pour les positionner, il faudrait le faire lors de l'installation donc par l'utilitaire d'installation. Le cas échant cela peut-etre fait depuis l'application en utilisant l'instruction SetAttr.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 12 mars 2007 à 12:01
Bonjour Casy,
Il peut bien sur, depuis son programme, modifier l'attribut (mis en lecture seule) pour travailler depuis son appli et le remettre en lecture seule in fine.
Il peut même aller plus loin encore dans les attributs mis hors applis et modifiés pendant l'appli.
Tout cela ne le protèrera certes pas des gestes malintentionnés car :
1) on fait sauter, comme tu le sais, tous les attributs que l'on veut...
2) quid, tout simplement, si le geste mal intentionné est tout simplement fait depuis l'appli elle-même ?
Rien de tout celà ne "tient debout"... (relire depuis le début de la conversation)
A Noter que l'on trouve partout sur le Web de quoi cacher l'existence même d'un volume et qu'on pourrait penser que la socution est là : utiliser un volume caché à cette fin... Même cette méthode ne tient hélàs pas face à la détermination et quelques connaissances de base (quelques secondes suffisent alors).
D'autres OS seraient, enfin, plus sécuritaires que Windows. Même dans ce cas, toutefois, celui à qui l'on a donné le privilège d'utiliser l'appli reste bien évidemment avec la possibilité de faire des gestes destructifs... sans compter le fait qu'il peut avoir été négligent ou non suffisamment discret... et que ses accès peuvent alors être utilisés par un tiers.
Même là où, étant plus particulièrement nécessaire de "protéger" très sérieusement (je sais de quoi je parle), on décide qu'à chaque ouverture de session le mot de passe soit changé (l'utilisateur reçoit une chaîne de caractères et doit, à l'aide d'un petit programme sur PC portable, en déduire le mot de passe nouveau... et conserver le dit PC portable dans un coffre-fort le reste du temps), des problèmes se sont posés, en dépit du fait que le nom de l'utilisateur se trouvait enregistré tans dans la base de donnée (sur chaque article traité) que dans un endroit complémentaire caché du disque dur. En dépit également du fait que le programme du PC portable "ad hoc" était doté de tout ce qu'il fallait pour enregistrer soigneusement toute utilisation faite en vue de "produire" le mot de passe de session ainsi que d'un compteur en interdisant une nouvelle utilisation au cours de la même journée sans un second mot de passe "spécial" devant alors être nécessairement donné par un "haut responsable" (le tout accompagné d'un PV de circonstances !...)