Securité de la base de données après compulation

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?

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

rien ne t'empêches de compresser ou de chiffrer le fichier Access, mais il faudra alors prendre du temps d'exécution pour la rendre lisible

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

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.

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.

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

---

# LE PARTAGE EST NOTRE FORCE #

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.

Merci pour vos contribution ...

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

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

---

# LE PARTAGE EST NOTRE FORCE #