OVH Cloud OVH Cloud

WD8: Fichier crypté ou accès par mot de passe?

5 réponses
Avatar
Réal Phil
Bonjour,

Dans un projet j'ai 1 fichier important contenant toujours un seul
enregistrement mais contenant 165 rubriques.

Pour en prot=E9ger l'acc=E8s aux fouineurs (rubriques, indices visuels,
etc...) quelle est la meilleure fa=E7on de faire ? Crypter le fichier ou
en prot=E9ger l'acc=E8s par mot de passe?

Acc=E8s par Mot de Passe:
Je constate qu'une fois cr=E9=E9, il n'est pas possible de rendre un
fichier accessible par mot de passe.
Si je cr=E9e un nouveau fichier avec le code
HCr=E9ation(Fichier2,"MotDePasse") je pr=E9sume que =E7a ne fonctionnera
pas parce que Fichier2 n'a pas =E9t=E9 d=E9fini dans l'analyse. Faut-il
passer par un Alias?
Et une fois cr=E9=E9, est-ce qu'il faut copier avec
HCopieEnreg(Fichier2,FichierSource) et HAjoute(Fichier2)?

Ou alors est-ce que le code suivant fonctionnera ?
HFerme("")
HChangeNom(FichierSource,Fichier2)
HCr=E9ation(FichierSource,"MotDePasse")

Est-ce que le Fichier2 sera ajout=E9 dans l'analyse? Comment s'est
d=E9faire ensuite?

Fichier crypt=E9
Je pr=E9sume que ce n'est pas la meilleure solution puisque le fichier
doit =EAtre d=E9crypt=E9 d=E8s l'ouverture de l'application et reste
accessible et bien visible depuis tout autre poste sur un r=E9seau.

Toute aide sera grandement appr=E9ci=E9e.

R=E9al Phil

5 réponses

Avatar
Pascal F
Réal Phil a écrit :
Bonjour,

Dans un projet j'ai 1 fichier important contenant toujours un seul
enregistrement mais contenant 165 rubriques.

Pour en protéger l'accès aux fouineurs (rubriques, indices visuels,
etc...) quelle est la meilleure façon de faire ? Crypter le fichier ou
en protéger l'accès par mot de passe?

Accès par Mot de Passe:
Je constate qu'une fois créé, il n'est pas possible de rendre un
fichier accessible par mot de passe.
Si je crée un nouveau fichier avec le code
HCréation(Fichier2,"MotDePasse") je présume que ça ne fonctionnera
pas parce que Fichier2 n'a pas été défini dans l'analyse. Faut-il
passer par un Alias?
Et une fois créé, est-ce qu'il faut copier avec
HCopieEnreg(Fichier2,FichierSource) et HAjoute(Fichier2)?

Ou alors est-ce que le code suivant fonctionnera ?
HFerme("")
HChangeNom(FichierSource,Fichier2)
HCréation(FichierSource,"MotDePasse")

Est-ce que le Fichier2 sera ajouté dans l'analyse? Comment s'est
défaire ensuite?

Fichier crypté
Je présume que ce n'est pas la meilleure solution puisque le fichier
doit être décrypté dès l'ouverture de l'application et reste
accessible et bien visible depuis tout autre poste sur un réseau.

Toute aide sera grandement appréciée.

Réal Phil



Dans une des dernières LST il y avait un exemple pour modifier par programmation le mot de passe d'un fichier. C'est un composant
fournit avec la LST 64. Le composant est fournit avec les sources.
Bonnes année à tous.

--
Pascal

Ne garder que le prénom pour me joindre
Avatar
Val
Bonjour

"Réal Phil" a écrit dans le message de news:

Bonjour,
Dans un projet j'ai 1 fichier important contenant toujours un seul
enregistrement mais contenant 165 rubriques.
Pour en protéger l'accès aux fouineurs (rubriques, indices visuels,
etc...) quelle est la meilleure façon de faire ? Crypter le fichier ou
en protéger l'accès par mot de passe?



Accès par Mot de Passe:
Je constate qu'une fois créé, il n'est pas possible de rendre un
fichier accessible par mot de passe.
Si je crée un nouveau fichier avec le code
HCréation(Fichier2,"MotDePasse") je présume que ça ne fonctionnera
pas parce que Fichier2 n'a pas été défini dans l'analyse. Faut-il
passer par un Alias?
Et une fois créé, est-ce qu'il faut copier avec
HCopieEnreg(Fichier2,FichierSource) et HAjoute(Fichier2)?




Fichier crypté
Je présume que ce n'est pas la meilleure solution puisque le fichier
doit être décrypté dès l'ouverture de l'application et reste
accessible et bien visible depuis tout autre poste sur un réseau.

Toute aide sera grandement appréciée.



Concernant le cryptage des fichiers (sur 128bits pour mon cas), j'en garde
un très, très, très mauvais souvenir.

En effet, début 2006, j'ai commencé la diffusion d'un programme où les
fichiers FIC, NDX et MMO étaient cryptés sur 128 bits.
Au bout de quelques jours et puisque de plus en plus de clients se
manifestaient pour me signaler des alertes de leurs antivirus sur les
fichiers HF utilisés par le programme (FIC et NDX en particulier), j'ai
commencé à regarder cela de plus près.
Et effectivement ... certains antivirus (AVAST en particulier) ne semblent
pas toujours faire la distinction entre un code malicieux et un numéro de
téléphone codé sur 128 bits ... donc quand ils ne savent pas trop à quoi ils
ont à faire ... pan ... ils balancent une alerte virus et à charge ensuite
de l'utilisateur de faire la distinction entre faux positif et vrai positif.

Quelle galère ... oui, il n'y a pas d'autres mots !!
En effet, en ce qui me concerne, je diffuse 90% de mes logiciels auprès du
Grand Public et je ne peux donc pas imposer à mes clients quel logiciel de
sécurité ils doivent utiliser (les conseiller oui, mais leur imposer un
choix non).
Donc, pendant des jours, des semaines et des mois je n'ai fait que répondre
aux clients qui étaient confrontés au problème (AVAST est très utilisé par
le Grand Public puisque largement plébiscité par tout le monde ... arkkkk)
en leur conseillant de mettre en zone de confiance le dossier où se
trouvaient les fichiers HF du logiciel.
Oui mais bon ... il faut qu'en même se mettre à la place du client. En
effet, d'un côté il a son antivirus qui lui dit "danger" et de l'autre
l'éditeur du logiciel qu'il ne connaît pas et qui lui dit "pas de danger".
Qui doit-il croire ??
L'éditeur du logiciel ou l'antivirus ?

Personnellement, dans un telle situation, je ne prendrais pas de risque et
je ne ferais donc pas confiance à l'éditeur du logiciel.
C'est la raison pour laquelle ce "phénomène" s'est fortement ressenti au
niveau des ventes du logiciel (il est diffusé en Shareware).
En effet, un client qui teste le logiciel et qui, après 3 mn, se retrouve
avec une alerte de sécurité de son antivirus, croyez-moi, il désinstalle le
logiciel et il passe son chemin.
Donc oui, ce "phénomène" m'a fait perdre des clients ... donc de l'argent.

Donc j'ai entrepris de nombreux tests sur mes machines, notamment en
supprimant le cryptage sur les NDX et les MMO et en ne laissant donc le
cryptage que sur les fichiers FIC.
Les alertes étaient moins fréquentes, mais il en subsistait encore.
En finalité, j'en ai eu ras le bol et j'ai supprimé ce pu##!!** de cryptage
sur tous les fichiers (FIC, NDX et MMO).

Désormais, tout va pour le mieux ... et que l'on ne me parle plus jamais de
cryptage (ni d'AVAST d'ailleurs).

Val
Avatar
J-M des Grottes
Val a formulé ce lundi :
Bonjour

"Réal Phil" a écrit dans le message de news:

Bonjour,
Dans un projet j'ai 1 fichier important contenant toujours un seul
enregistrement mais contenant 165 rubriques.
Pour en protéger l'accès aux fouineurs (rubriques, indices visuels,
etc...) quelle est la meilleure façon de faire ? Crypter le fichier ou
en protéger l'accès par mot de passe?



Accès par Mot de Passe:
Je constate qu'une fois créé, il n'est pas possible de rendre un
fichier accessible par mot de passe.
Si je crée un nouveau fichier avec le code
HCréation(Fichier2,"MotDePasse") je présume que ça ne fonctionnera
pas parce que Fichier2 n'a pas été défini dans l'analyse. Faut-il
passer par un Alias?
Et une fois créé, est-ce qu'il faut copier avec
HCopieEnreg(Fichier2,FichierSource) et HAjoute(Fichier2)?




Fichier crypté
Je présume que ce n'est pas la meilleure solution puisque le fichier
doit être décrypté dès l'ouverture de l'application et reste
accessible et bien visible depuis tout autre poste sur un réseau.

Toute aide sera grandement appréciée.



Concernant le cryptage des fichiers (sur 128bits pour mon cas), j'en garde
un très, très, très mauvais souvenir.

En effet, début 2006, j'ai commencé la diffusion d'un programme où les
fichiers FIC, NDX et MMO étaient cryptés sur 128 bits.
Au bout de quelques jours et puisque de plus en plus de clients se
manifestaient pour me signaler des alertes de leurs antivirus sur les
fichiers HF utilisés par le programme (FIC et NDX en particulier), j'ai
commencé à regarder cela de plus près.
Et effectivement ... certains antivirus (AVAST en particulier) ne semblent
pas toujours faire la distinction entre un code malicieux et un numéro de
téléphone codé sur 128 bits ... donc quand ils ne savent pas trop à quoi ils
ont à faire ... pan ... ils balancent une alerte virus et à charge ensuite
de l'utilisateur de faire la distinction entre faux positif et vrai positif.

Quelle galère ... oui, il n'y a pas d'autres mots !!
En effet, en ce qui me concerne, je diffuse 90% de mes logiciels auprès du
Grand Public et je ne peux donc pas imposer à mes clients quel logiciel de
sécurité ils doivent utiliser (les conseiller oui, mais leur imposer un
choix non).
Donc, pendant des jours, des semaines et des mois je n'ai fait que répondre
aux clients qui étaient confrontés au problème (AVAST est très utilisé par
le Grand Public puisque largement plébiscité par tout le monde ... arkkkk)
en leur conseillant de mettre en zone de confiance le dossier où se
trouvaient les fichiers HF du logiciel.
Oui mais bon ... il faut qu'en même se mettre à la place du client. En
effet, d'un côté il a son antivirus qui lui dit "danger" et de l'autre
l'éditeur du logiciel qu'il ne connaît pas et qui lui dit "pas de danger".
Qui doit-il croire ??
L'éditeur du logiciel ou l'antivirus ?

Personnellement, dans un telle situation, je ne prendrais pas de risque et je
ne ferais donc pas confiance à l'éditeur du logiciel.
C'est la raison pour laquelle ce "phénomène" s'est fortement ressenti au
niveau des ventes du logiciel (il est diffusé en Shareware).
En effet, un client qui teste le logiciel et qui, après 3 mn, se retrouve
avec une alerte de sécurité de son antivirus, croyez-moi, il désinstalle le
logiciel et il passe son chemin.
Donc oui, ce "phénomène" m'a fait perdre des clients ... donc de l'argent.

Donc j'ai entrepris de nombreux tests sur mes machines, notamment en
supprimant le cryptage sur les NDX et les MMO et en ne laissant donc le
cryptage que sur les fichiers FIC.
Les alertes étaient moins fréquentes, mais il en subsistait encore.
En finalité, j'en ai eu ras le bol et j'ai supprimé ce pu##!!** de cryptage
sur tous les fichiers (FIC, NDX et MMO).

Désormais, tout va pour le mieux ... et que l'on ne me parle plus jamais de
cryptage (ni d'AVAST d'ailleurs).

Val



Salut,

Attention aux cryptage. Le jour où ton appli plante et que l'on doit
accéder à tes données via ODBC.....c'est la m..... Avec le cryptage,
tout est illisible.

Je pense qu'il vaut mieux bien sécuriser le transport des données et le
serveur, tout en laissant les données "libresé.

Bien à toi

Von dev

--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique
Avatar
Réal Phil
>Dans une des dernières LST il y avait un exemple pour modifier par progr ammation le mot de passe d'un fichier. C'est un composant
fournit avec la LST 64. Le composant est fournit avec les sources.
Bonnes année à tous.

--
Pascal

Ne garder que le prénom pour me joindre


--------------------------------------------------------------------------
Zut, je me suis réabonné depuis la LST 65.
J'ai bien l'impression que cela m'aurait facilité la vie.

Réal Phil
Avatar
Réal Phil
Salut Val,

Merci d'avoir partagé cette aventure pour le moins désagréable - que
nous pourrons éviter grâce à ton expérience.

Bone année 2007

Réal Phil