|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| [WD22] Sécurité : constante ou variable ? |
| Débuté par Ramirez22, 26 déc. 2019 15:37 - 8 réponses |
| |
| | | |
|
| |
Membre enregistré
60 messages
Popularité : +2 (2 votes) |
|
Posté le 26 décembre 2019 - 15:37 |
Bonjour,
Dans le cadre de la sécurisation du stockage de data sur un serveur SQL externe, je dois chiffrer les données enregistrées.
1 - Quel est l'intéret d'utiliser les fonction CrypteStandard et DecrypteStandard : l'utilisation des anciennes fonctions Crypte/Decrypte semble plus simple. Est-ce une question de sécurité, de hackage possible ? J'avoue ne pas être à l'aise avec les buffers...
2 - Au niveau de l'utilisation de la clé de codage/décodage (pour les 2 solutions), quelle est la meilleure méthode d'un point de vue sécurité :
- L'écrire "en dur" dans le programme, à chaque appel de la fonction ?
- L'écrire dans une variable dans le code d'initialisation du projet ?
- L'écrire dans une variable CONSTANTE dans le code d'initialisation du projet ?
Cordialement,
Ramirez22 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 887 messages
Popularité : +227 (347 votes) |
|
Posté le 27 décembre 2019 - 05:46 |
Bonjour,
Ramirez22 a écrit :
1 - Quel est l'intéret d'utiliser les fonction CrypteStandard et DecrypteStandard : l'utilisation des anciennes fonctions Crypte/Decrypte semble plus simple. Est-ce une question de sécurité, de hackage possible ? J'avoue ne pas être à l'aise avec les buffers...
C'est une question de portabilité vers d'autre plateformes cf la doc, qui plus est, à partir de la V22, Crypte est deprecated
2 - Au niveau de l'utilisation de la clé de codage/décodage (pour les 2 solutions), quelle est la meilleure méthode d'un point de vue sécurité :
- L'écrire "en dur" dans le programme, à chaque appel de la fonction ?
- L'écrire dans une variable dans le code d'initialisation du projet ?
- L'écrire dans une variable CONSTANTE dans le code d'initialisation du projet ?
La première proposition est à proscrire pour des raisons de maintenance
La 3° (constante) résout ce problème, si des modification doivent avoir lieu, on ne les fait qu'une fois mais comporte des failles de sécurité.
La deuxième est jouable, à condition de ne pas initialiser la variable "en dur" (dans ce cas on se retrouve dans le cas précédent.) L'initialisation doit se faire soit via un fichhier .INI (crypté bien entendu) soit via la BDR.
--
Il y a peut être plus simple, mais, ça tourneMessage modifié, 27 décembre 2019 - 05:48 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
60 messages
Popularité : +2 (2 votes) |
|
Posté le 27 décembre 2019 - 07:55 |
Voroltinquo a écrit :
> C'est une question de portabilité vers d'autre plateformes cf la doc, qui plus est, à partir de la V22, Crypte est deprecated
Est-ce que cela veut dire que pour peu que l'on connaisse
- la clef de récupération
- la méthode de hash de cette clef
- le protocole de cryptage
on est capable de récupérer les données avec n'importe quelle autre appli ? Alors que ce n'est pas le cas avec Crypte/Décrypte ? Dans ce cas, je crois que je vais me mettre un peu à essayer de comprendre les buffers car la sécurité des données est essentielles dans les 2 cas : il ne faut pas pouvoir y accéder si on a pas le droit, mais elles doivent toujours être accessibles même si PCSOFT ne distribue plus WINDEV 
La première proposition est à proscrire pour des raisons de maintenance
La 3° (constante) résout ce problème, si des modification doivent avoir lieu, on ne les fait qu'une fois mais comporte des failles de sécurité.
La deuxième est jouable, à condition de ne pas initialiser la variable "en dur" (dans ce cas on se retrouve dans le cas précédent.) L'initialisation doit se faire soit via un fichhier .INI (crypté bien entendu) soit via la BDR.
Du coup, si le fichier .ini est crypté, il lui faut une clef de décryptage qui doit être dans un fichier .ini crypté donc il faut d'abord le décrypter avec un fichier .ini crypté ... heu on se mord pas un peu la queue là  ?
Je vais essayer un mix des 2 solutions : les données cryptées par le CrypteStandard (ce sont les données qu'il faut pouvoir récupérer en cas de besoin, même avec l'aide d'un autre soft) et la clef cryptée dans un fichier .ini via la méthode standard. Illisible donc sécurisée, et la clé véritable protégée au coffre "au cas ou". Est-ce que tu penses que c'est une bonne solution ?
En tout cas, merci pour les explications.
Cordialement,
Ramirez22 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 887 messages
Popularité : +227 (347 votes) |
|
Posté le 27 décembre 2019 - 09:01 |
Ramirez22 a écrit :
Est-ce que cela veut dire que pour peu que l'on connaisse
- la clef de récupération
- la méthode de hash de cette clef
- le protocole de cryptage
on est capable de récupérer les données avec n'importe quelle autre appli ? Alors que ce n'est pas le cas avec Crypte/Décrypte ? Dans ce cas, je crois que je vais me mettre un peu à essayer de comprendre les buffers car la sécurité des données est essentielles dans les 2 cas : il ne faut pas pouvoir y accéder si on a pas le droit, mais elles doivent toujours être accessibles même si PCSOFT ne distribue plus WINDEV
C'est cela.
Du coup, si le fichier .ini est crypté, il lui faut une clef de décryptage qui doit être dans un fichier .ini crypté donc il faut d'abord le décrypter avec un fichier .ini crypté ... heu on se mord pas un peu la queue là ?
Le .INI est crypté avec une autre clé que l'on saisira au démarage, c'est pour cela que je préconise la BDR (on ne saisit la clé de décryptage qu'une fois.)
Quoiqu'il en soit, le fichier INI doit être dans un répertoire différent de celui de l'appli. Un stockage externe conservé dans une armoire forte ext préconisé.
L'initialisation peut se faire de cette manière :
SI RegistreExiste("HiveSécurité","CléAppliEnCours") ALORS
gbufCléCryptage=RegistreLit("HiveSécurité","CléAppliEnCours")
SINON
Saisie("Veuillez saisir la clé de chiffrement pour l'appli MonAppli SVP,gbufCléCryptage)
SI PAS RegistreExiste("HiveSécurité") ALORS
RegistreCréeClé("HiveSécurité"
FIN
RegistreEcrit("HiveSécurité","CléAppliEnCours",gbufCléCryptage)
Il y a bien entendu des contrôle à effectuer pour les saisies vides ou une valeur de clé de la BDR vide.
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
60 messages
Popularité : +2 (2 votes) |
|
Posté le 27 décembre 2019 - 09:59 |
Merci pour toutes ces précisions.
Si j'ai bien compris et pour résumer :
- BDR : contient la clef de déchiffrement du fichier INI, qui sera renseignée au premier lancement ou à l'installation, mais manuellement. Je suis très limité sur les accès BDR (pas de droits admin sur postes clients). A priori, HKCU/Software/Classes est OK.
- Fichier INI : chiffré, contient la clef de déchiffrement des données de la base SQL. La méthode de chiffrement du fichier INI importe peu DU MOMENT que l'on a sauvegarder la clef EN CLAIR dans un espace sécurisé (coffre par exemple). Mais là encore, si besoin est de retrouver la clef (destruction du support physique), autant avoir le fichier INI chiffré de manière standard. Je suis très limité sur les accès disques. Je vais être obligé de laisser le fichier INI dans le répertoire de l'application. A renommer pour éviter que cela ne soit trop flagrant ? Évidemment, les 2 clefs doivent impérativement être différentes.
- Base SQL : données sensibles chiffrées avec la clef du fichier INI, accès au serveur avec mot de passe.
Si c'est OK, j'ai encore un peu de boulot.
Merci de ton aide. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 887 messages
Popularité : +227 (347 votes) |
|
Posté le 27 décembre 2019 - 10:28 |
La BDR contient la clé de chiffrement des données. Elle est stockée une fois pour toute (sauf modification, problèmes de disque etc.)
En ce qui concerne la limitation, essaye de créer un hive dans la racine HKCU du style HKEY_CURRENT_USER\System\CurrentControlSet\Control\DeviceContainers\{aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee}, c'est là que tu stockera les différentes clés
--
Il y a peut être plus simple, mais, ça tourneMessage modifié, 27 décembre 2019 - 10:29 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
60 messages
Popularité : +2 (2 votes) |
|
Posté le 03 janvier 2020 - 15:27 |
Bonjour et meilleurs vœux !
Je reviens un peu tardivement (cause à quelques évènements festifs mal placés ) afin d'avoir quelques éclaircissements.
En effet, j'ai un doute sur la méthode.
De ce que j'ai compris, la BDR contient la clef de déchiffrement des données du serveur SQL. Est-ce que ce n'est pas trop "cheap" comme solution ? Car n'importe qui peut lire la BDR.
Ou alors, j'ai mal compris : La BDR contient la clef de décryptage d'un fichier INI crypté, implanté ailleurs (réseau avec accès restreint...), qui lui-même contient la clef de déchiffrement des données issues de ma base SQL ?
Merci pour ces quelques précisions. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 887 messages
Popularité : +227 (347 votes) |
|
Posté le 03 janvier 2020 - 20:13 |
N'importe qui, non, on peut mettre des droits sur la BDR en utilisant le compte administrateur.
Ensuite en nommant les hives ou les clés ou les 2 avec des noms relativement "tordus" cf mon post #6, il y a fort peut de chance qu'on sache quel hive ou clé correspond à la clé de décryptage.
Tu obtenir ce genre de noms avec la fonction DonneGUID
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
60 messages
Popularité : +2 (2 votes) |
|
Posté le 10 janvier 2020 - 07:21 |
Bonjour,
J'ai oublié de te remercier et je m'en excuse.
J'ai résolu mon problème et complexifié l'accès au mot de passe en le scindant en 2 endroits.
Merci encore de tes conseils.
Cordialement,
Ramirez22 |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|