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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
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
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
Bonjour
"Réal Phil" <realmip@yahoo.ca> a écrit dans le message de news:
1167590015.579000.71120@v33g2000cwv.googlegroups.com...
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).
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
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
Val a formulé ce lundi :
Bonjour
"Réal Phil" <realmip@yahoo.ca> a écrit dans le message de news:
1167590015.579000.71120@v33g2000cwv.googlegroups.com...
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
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
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
>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
N0.pascal.S...@efpe.biz
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.
>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
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
Salut Val,
Merci d'avoir partagé cette aventure pour le moins désagréable - que
nous pourrons éviter grâce à ton expérience.