J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui sont
ensuite écrit dans un fichier HF.
Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un
mauvais Décryptage (résultat en binaire) environ 1 fois sur 30.
J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux).
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
JC FLAJOULOT
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui sont ensuite écrit dans un fichier HF. Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un mauvais Décryptage (résultat en binaire) environ 1 fois sur 30. J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux). Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format binaire avec des caractères non imprimables, le problème est que dans ce format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans la chaine cryptée. Lors de l'enregistrement si (par exemple) un caractère de ce type figure en milieu de la chaine à enregistrer, elle va être tronquée et seuls les caractères figurants avant seront enregistrés dans le champ de votre fichier HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le résultat de ce décryptage sera obligatoirement erroné. Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une utilisation dans des champs de fichier HF (Attention il faut prévoir dans le fichier des champs de taille plus importante que la saisie en raison de l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez aussi une chaine cryptée). Le cryptage avec le format Binaire, est à utiliser avec beaucoup de méfiance car même dans un document texte il peut poser des problèmes, par exemple un caractère de fin de fichier placé en plein milieu du texte et on perd tout le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le cryptage est bien meilleur et on traite les opérations de cryptage/décryptage aussi vite.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui sont
ensuite écrit dans un fichier HF.
Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un
mauvais Décryptage (résultat en binaire) environ 1 fois sur 30.
J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux).
Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format
binaire avec des caractères non imprimables, le problème est que dans ce
format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans
la chaine cryptée.
Lors de l'enregistrement si (par exemple) un caractère de ce type figure en
milieu de la chaine à enregistrer, elle va être tronquée et seuls les
caractères figurants avant seront enregistrés dans le champ de votre fichier
HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le
résultat de ce décryptage sera obligatoirement erroné.
Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une
utilisation dans des champs de fichier HF (Attention il faut prévoir dans le
fichier des champs de taille plus importante que la saisie en raison de
l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez
aussi une chaine cryptée).
Le cryptage avec le format Binaire, est à utiliser avec beaucoup de méfiance
car même dans un document texte il peut poser des problèmes, par exemple un
caractère de fin de fichier placé en plein milieu du texte et on perd tout
le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le
cryptage est bien meilleur et on traite les opérations de
cryptage/décryptage aussi vite.
Sincères salutations
--
Jean-Claude FLAJOULOT
spetb_no_Spam@tiscali.fr
(otez _no_Spam pour me contacter en privé)
Sécurité Pointage & Biométrie
http://www.sp-et-b.com
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui sont ensuite écrit dans un fichier HF. Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un mauvais Décryptage (résultat en binaire) environ 1 fois sur 30. J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux). Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format binaire avec des caractères non imprimables, le problème est que dans ce format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans la chaine cryptée. Lors de l'enregistrement si (par exemple) un caractère de ce type figure en milieu de la chaine à enregistrer, elle va être tronquée et seuls les caractères figurants avant seront enregistrés dans le champ de votre fichier HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le résultat de ce décryptage sera obligatoirement erroné. Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une utilisation dans des champs de fichier HF (Attention il faut prévoir dans le fichier des champs de taille plus importante que la saisie en raison de l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez aussi une chaine cryptée). Le cryptage avec le format Binaire, est à utiliser avec beaucoup de méfiance car même dans un document texte il peut poser des problèmes, par exemple un caractère de fin de fichier placé en plein milieu du texte et on perd tout le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le cryptage est bien meilleur et on traite les opérations de cryptage/décryptage aussi vite.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
JC FLAJOULOT
Bonjour,
En complément je retranscris le contenu d'un post que j'avais envoyé ici le 14 novembre.
Pour obtenir une sécurité optimum, vous devez : 1°/ Donner un mot de passe d'exécution dans votre analyse pour empécher qu'elle soit ouverte avec les outils optionnels 2°/ Dans la description de chacun de vos fichiers (onglet détail) activez : - Fichiers de données, fichiers d'index et fichiers mémo Cryptage sur 128 bits - Cocher activer la sécurité renforcée 3°/ Donner un mot de passe pour la création des fichiers sous la forme : // Code à placer dans le code d'initialisation de votre application : cMdPPrinc est une chaîne cMdPPrinc = "CeciEstMonMotDePasse_123456" SI PAS HOuvre("*",cMdPPrinc) ALORS // Si le (ou les) fichier(s) existe(ent) déjà il est/sont ouvert(s) en tenant compte du mot de passe HCréationSiInexistant("*",cMdPPrinc) // Sinon le (ou les) fichier(s) est/sont créé(s) avec le mot de passe FIN
Il est recommandé d'utiliser un mot de passe différent pour l'analyse et les données, et de bien choisir ce mot de passe (plus de 10 caractères en panachant lettres et chiffres).
Donc on crypte l'analyse, les fichiers et dans les fichiers, on peut en plus crypter (comme vous le faites) certaines données.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
Bonjour,
En complément je retranscris le contenu d'un post que j'avais envoyé ici le
14 novembre.
Pour obtenir une sécurité optimum, vous devez :
1°/ Donner un mot de passe d'exécution dans votre analyse pour empécher
qu'elle soit ouverte avec les outils optionnels
2°/ Dans la description de chacun de vos fichiers (onglet détail) activez :
- Fichiers de données, fichiers d'index et fichiers mémo Cryptage sur 128
bits
- Cocher activer la sécurité renforcée
3°/ Donner un mot de passe pour la création des fichiers sous la forme :
// Code à placer dans le code d'initialisation de votre application :
cMdPPrinc est une chaîne
cMdPPrinc = "CeciEstMonMotDePasse_123456"
SI PAS HOuvre("*",cMdPPrinc) ALORS // Si le (ou les) fichier(s) existe(ent)
déjà il est/sont ouvert(s) en tenant compte du mot de passe
HCréationSiInexistant("*",cMdPPrinc) // Sinon le (ou les) fichier(s)
est/sont créé(s) avec le mot de passe
FIN
Il est recommandé d'utiliser un mot de passe différent pour l'analyse et les
données, et de bien choisir ce mot de passe (plus de 10 caractères en
panachant lettres et chiffres).
Donc on crypte l'analyse, les fichiers et dans les fichiers, on peut en plus
crypter (comme vous le faites) certaines données.
Sincères salutations
--
Jean-Claude FLAJOULOT
spetb_no_Spam@tiscali.fr
(otez _no_Spam pour me contacter en privé)
Sécurité Pointage & Biométrie
http://www.sp-et-b.com
En complément je retranscris le contenu d'un post que j'avais envoyé ici le 14 novembre.
Pour obtenir une sécurité optimum, vous devez : 1°/ Donner un mot de passe d'exécution dans votre analyse pour empécher qu'elle soit ouverte avec les outils optionnels 2°/ Dans la description de chacun de vos fichiers (onglet détail) activez : - Fichiers de données, fichiers d'index et fichiers mémo Cryptage sur 128 bits - Cocher activer la sécurité renforcée 3°/ Donner un mot de passe pour la création des fichiers sous la forme : // Code à placer dans le code d'initialisation de votre application : cMdPPrinc est une chaîne cMdPPrinc = "CeciEstMonMotDePasse_123456" SI PAS HOuvre("*",cMdPPrinc) ALORS // Si le (ou les) fichier(s) existe(ent) déjà il est/sont ouvert(s) en tenant compte du mot de passe HCréationSiInexistant("*",cMdPPrinc) // Sinon le (ou les) fichier(s) est/sont créé(s) avec le mot de passe FIN
Il est recommandé d'utiliser un mot de passe différent pour l'analyse et les données, et de bien choisir ce mot de passe (plus de 10 caractères en panachant lettres et chiffres).
Donc on crypte l'analyse, les fichiers et dans les fichiers, on peut en plus crypter (comme vous le faites) certaines données.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
Phil
Tél.: (450) 629-2776 Sans Frais: 1-888-629-2776 "JC FLAJOULOT" a écrit dans le message de news:coc3vo$hu9$
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui
sont
> ensuite écrit dans un fichier HF. > Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un > mauvais Décryptage (résultat en binaire) environ 1 fois sur 30. > J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux). > Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format binaire avec des caractères non imprimables, le problème est que dans ce format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans la chaine cryptée. Lors de l'enregistrement si (par exemple) un caractère de ce type figure
en
milieu de la chaine à enregistrer, elle va être tronquée et seuls les caractères figurants avant seront enregistrés dans le champ de votre
fichier
HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le résultat de ce décryptage sera obligatoirement erroné. Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une utilisation dans des champs de fichier HF (Attention il faut prévoir dans
le
fichier des champs de taille plus importante que la saisie en raison de l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez aussi une chaine cryptée). Le cryptage avec le format Binaire, est à utiliser avec beaucoup de
méfiance
car même dans un document texte il peut poser des problèmes, par exemple
un
caractère de fin de fichier placé en plein milieu du texte et on perd tout le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le cryptage est bien meilleur et on traite les opérations de cryptage/décryptage aussi vite.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
J'aurais dû y penser. RC, LF, etc.. sont sûrement la raison de ces "anomalies". Je suis surpris que PCS n'ai pas pensé à cela. Cela rend cette fonction alors inutilisable telle quelle puisque pour moi, si ce n'est pas fiable, ce n'est pas utilisable. Il me semble qu'ils auraient pu trouver une alternative assez facilement. Bien sûr, ils le disent que cela peut contenir des caractères non imprimables, mais quand même, cela limite beaucoup son utilisation. Heureusement, il existe d'autres alternatives.
De notre côté, on pourrait toujours - je présume - vérifier si la chaîne cryptée contient un de ces symboles et si c'est le cas recommencer l'encryption avec un mot de passe aléatoire (qui serait caché ailleurs) jusqu'à ce que la chaîne cryptée soit "propre". Avec Faux, j'aimais le fait que le texte crypté est de la même longueur.
Mais, votre conseil est judicieux, ce sera beaucoup plus simple d'utiliser crypteSécurisé avec l'option Vrai (format ASCII) et d'agrandir les champs - le compromis est minime.
Merci beaucoup de partager votre expérience à ce sujet.
Merci aussi pour le complément envoyé qui contient, assurément, d'excellentes suggestion pour une protection maximale.
Réal Phil
Tél.: (450) 629-2776 Sans Frais: 1-888-629-2776
"JC FLAJOULOT" <spetb@tiscali.fr> a écrit dans le message de
news:coc3vo$hu9$1@news.tiscali.fr...
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui
sont
> ensuite écrit dans un fichier HF.
> Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un
> mauvais Décryptage (résultat en binaire) environ 1 fois sur 30.
> J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux).
> Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format
binaire avec des caractères non imprimables, le problème est que dans ce
format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans
la chaine cryptée.
Lors de l'enregistrement si (par exemple) un caractère de ce type figure
en
milieu de la chaine à enregistrer, elle va être tronquée et seuls les
caractères figurants avant seront enregistrés dans le champ de votre
fichier
HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le
résultat de ce décryptage sera obligatoirement erroné.
Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une
utilisation dans des champs de fichier HF (Attention il faut prévoir dans
le
fichier des champs de taille plus importante que la saisie en raison de
l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez
aussi une chaine cryptée).
Le cryptage avec le format Binaire, est à utiliser avec beaucoup de
méfiance
car même dans un document texte il peut poser des problèmes, par exemple
un
caractère de fin de fichier placé en plein milieu du texte et on perd tout
le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le
cryptage est bien meilleur et on traite les opérations de
cryptage/décryptage aussi vite.
Sincères salutations
--
Jean-Claude FLAJOULOT
spetb_no_Spam@tiscali.fr
(otez _no_Spam pour me contacter en privé)
Sécurité Pointage & Biométrie
http://www.sp-et-b.com
J'aurais dû y penser. RC, LF, etc.. sont sûrement la raison de ces
"anomalies". Je suis surpris que PCS n'ai pas pensé à cela. Cela rend cette
fonction alors inutilisable telle quelle puisque pour moi, si ce n'est pas
fiable, ce n'est pas utilisable. Il me semble qu'ils auraient pu trouver une
alternative assez facilement. Bien sûr, ils le disent que cela peut contenir
des caractères non imprimables, mais quand même, cela limite beaucoup son
utilisation. Heureusement, il existe d'autres alternatives.
De notre côté, on pourrait toujours - je présume - vérifier si la chaîne
cryptée contient un de ces symboles et si c'est le cas recommencer
l'encryption avec un mot de passe aléatoire (qui serait caché ailleurs)
jusqu'à ce que la chaîne cryptée soit "propre".
Avec Faux, j'aimais le fait que le texte crypté est de la même longueur.
Mais, votre conseil est judicieux, ce sera beaucoup plus simple d'utiliser
crypteSécurisé avec l'option Vrai (format ASCII) et d'agrandir les champs -
le compromis est minime.
Merci beaucoup de partager votre expérience à ce sujet.
Merci aussi pour le complément envoyé qui contient, assurément,
d'excellentes suggestion pour une protection maximale.
Tél.: (450) 629-2776 Sans Frais: 1-888-629-2776 "JC FLAJOULOT" a écrit dans le message de news:coc3vo$hu9$
> J'utilise Crypte/Décrypte dans une fenetre avec plusieurs champs qui
sont
> ensuite écrit dans un fichier HF. > Cette fenetre est utilisée EnModeTest et j'ai apperçu ce qui semble un > mauvais Décryptage (résultat en binaire) environ 1 fois sur 30. > J'utilise Crypte/Décrypte(variable,MotDePasse,CrypteRapide,Faux). > Quelqu'un d'autre a observé la meme chose?
Bonjour,
Oui et celà est normal, le fait d'utiliser Faux écrit la chaine en format binaire avec des caractères non imprimables, le problème est que dans ce format, des caractères tels que RC, LF, EOT, EOF, etc peuvent figurer dans la chaine cryptée. Lors de l'enregistrement si (par exemple) un caractère de ce type figure
en
milieu de la chaine à enregistrer, elle va être tronquée et seuls les caractères figurants avant seront enregistrés dans le champ de votre
fichier
HF. Lors de la lecture, vous décryptez une chaine incomplète, donc le résultat de ce décryptage sera obligatoirement erroné. Pour résumer, vous devez utiliser le type Vrai (format ASCII) pour une utilisation dans des champs de fichier HF (Attention il faut prévoir dans
le
fichier des champs de taille plus importante que la saisie en raison de l'augmentation de la taille de la chaine ainsi cryptée, sinon vous aurez aussi une chaine cryptée). Le cryptage avec le format Binaire, est à utiliser avec beaucoup de
méfiance
car même dans un document texte il peut poser des problèmes, par exemple
un
caractère de fin de fichier placé en plein milieu du texte et on perd tout le reste du texte.
Dernier conseil, utilisez crypteSécurisé plutot que CrypteRapide, le cryptage est bien meilleur et on traite les opérations de cryptage/décryptage aussi vite.
Sincères salutations -- Jean-Claude FLAJOULOT
(otez _no_Spam pour me contacter en privé) Sécurité Pointage & Biométrie http://www.sp-et-b.com
J'aurais dû y penser. RC, LF, etc.. sont sûrement la raison de ces "anomalies". Je suis surpris que PCS n'ai pas pensé à cela. Cela rend cette fonction alors inutilisable telle quelle puisque pour moi, si ce n'est pas fiable, ce n'est pas utilisable. Il me semble qu'ils auraient pu trouver une alternative assez facilement. Bien sûr, ils le disent que cela peut contenir des caractères non imprimables, mais quand même, cela limite beaucoup son utilisation. Heureusement, il existe d'autres alternatives.
De notre côté, on pourrait toujours - je présume - vérifier si la chaîne cryptée contient un de ces symboles et si c'est le cas recommencer l'encryption avec un mot de passe aléatoire (qui serait caché ailleurs) jusqu'à ce que la chaîne cryptée soit "propre". Avec Faux, j'aimais le fait que le texte crypté est de la même longueur.
Mais, votre conseil est judicieux, ce sera beaucoup plus simple d'utiliser crypteSécurisé avec l'option Vrai (format ASCII) et d'agrandir les champs - le compromis est minime.
Merci beaucoup de partager votre expérience à ce sujet.
Merci aussi pour le complément envoyé qui contient, assurément, d'excellentes suggestion pour une protection maximale.
