SQLpro

Bonjour,
Tu pourrais nous en dire plus sur la partie déchiffrement ?
Notamment pour ton exemple qui donne deux données chiffrées différentes pour le même chiffrement ?

(Il y a une petite boulette dans le lien vers le site de l'INSEE qui ne fonctionne pas)

Ce qui veut dire qu'il suffit d'avoir accès au code de l'application pour péter le chiffrement... C'est comme si vous fermiez votre voiture à clé en laissant les clés sur la porte !

Oui et non... l'état de l'art à l'heure actuelle a (heureusement) bien évolué et on ne met plus les clés/mots de passe en direct dans le code, pour éviter entre autre qu'en cas de faille sur le serveur Web ces données sensibles ne soient accessibles directement. On place les clés/mots de passe dans des fichiers (eux-mêmes chiffrés) dans un dossier hors des dossiers présentés par les serveurs web. La clé de déchiffrement des fichiers est, elle aussi, située dans un emplacement isolé (on peut même aller plus loin en utilisant un dongle USB et des mécanismes d'OTP si on souhaite un niveau supérieur, mais ça demande alors l'utilisation de librairies spécifiques).
Le programme (script, appli...) lit à la volée la clé de déchiffrement première, puis lit les clés de déchiffrement (ou les mots de passe) d'accès aux ressources. Bien entendu, si on a un accès direct à la machine avec un compte qui a accès aux emplacements sécurisés ou s'il y a une faille dans le service web suffisamment grave pour provoquer un débordement de pile et accéder à des zones de RAM dans lesquelles on va retrouver les clés de déchiffrement, on peut avoir un problème. Mais on a quand-même sérieusement diminué les risques (et, de toutes façons, s'il y a une faille de sécurité suffisamment importante pour avoir un accès à la RAM, ou un accès superviseur sur le serveur, alors on peut aussi accéder aux données de la base en mémoire quelle que soit la situation).

Envoyé par Karadoc

(Il y a une petite boulette dans le lien vers le site de l'INSEE qui ne fonctionne pas)

Oui et non... l'état de l'art à l'heure actuelle a (heureusement) bien évolué et on ne met plus les clés/mots de passe en direct dans le code, pour éviter entre autre qu'en cas de faille sur le serveur Web ces données sensibles ne soient accessibles directement.

ça c'est un vœux pieu, mais dans les faits, la plupart des applications utilisent des mots de passe directement en clair dans le code; parce que les mécanisme en jeu dans MySQL/mariaDB n'obligent pas à cela et que l'effort de développement et/ou de rectification des applications écrites ainsi est colossal !

On place les clés/mots de passe dans des fichiers (eux-mêmes chiffrés) dans un dossier hors des dossiers présentés par les serveurs web. La clé de déchiffrement des fichiers est, elle aussi, située dans un emplacement isolé (on peut même aller plus loin en utilisant un dongle USB et des mécanismes d'OTP si on souhaite un niveau supérieur, mais ça demande alors l'utilisation de librairies spécifiques).
Le programme (script, appli...) lit à la volée la clé de déchiffrement première, puis lit les clés de déchiffrement (ou les mots de passe) d'accès aux ressources.

Ce que fait intrinsèquement SQL Server ou Oracle.... Et qu'il faut faire à la main dans le code avec MySQL / MariaDB... perte de temps, complexité...

Bien entendu, si on a un accès direct à la machine avec un compte qui a accès aux emplacements sécurisés ou s'il y a une faille dans le service web suffisamment grave pour provoquer un débordement de pile et accéder à des zones de RAM dans lesquelles on va retrouver les clés de déchiffrement, on peut avoir un problème. Mais on a quand-même sérieusement diminué les risques (et, de toutes façons, s'il y a une faille de sécurité suffisamment importante pour avoir un accès à la RAM, ou un accès superviseur sur le serveur, alors on peut aussi accéder aux données de la base en mémoire quelle que soit la situation).

C'est bien pour cela que les enclaves sécurisé en mémoire sont faites... Mais cela n'existe pas dans MySQL/MariaDB...

Envoyé par CinePhil

Bonjour,
Tu pourrais nous en dire plus sur la partie déchiffrement ?
Notamment pour ton exemple qui donne deux données chiffrées différentes pour le même chiffrement ?

Microsoft ne communique pas sur l'algorithme de salage ni sur la manière dont cela est fait... Et heureusement. En matière de sécurité et de chiffrement moins on en sait et mieux cela vaut !

Dans cette matière certains SGBD sont assez débiles pour informer de la nature précise d'une erreur de connexion... Ce qu'il ne faut jamais faire !
Par exemple j'ai vu des SGBDR dire que le mot de passe était erroné, ce qui veut dire que le compte de connexion était bon !
Dans SQL Server par exemple, le message en cas de connexion incorrect est toujours le même, mais la nature profonde est enregistrée dans un log interne consultable seulement pas les DBA....

mais pour te répondre plus précisément, le déchiffrement ne pas pas de problème...

Le même exemple en plus complet....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT ENCRYPTBYPASSPHRASE('Le petit chat est vivant...', 'DUPONT')  AS NOM_CHIFFRÉ
INTO T;

INSERT INTO T 
SELECT ENCRYPTBYPASSPHRASE('Le petit chat est vivant...', 'DUPONT')  AS NOM_CHIFFRÉ;

les deux dupond sont mis dans la même table créée à la volée... Aucune autre colonne !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NOM_CHIFFRÉ
--------------------------------------------------------------------------
0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C
0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2

Déchiffrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT *, DECRYPTBYPASSPHRASE('Le petit chat est vivant...', NOM_CHIFFRÉ) AS NOM_DÉCHIFFRÉ
FROM   T;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NOM_CHIFFRÉ                                                                   NOM_DÉCHIFFRÉ
----------------------------------------------------------------------------- -------------------    
0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C    0x4455504F4E54
0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2    0x4455504F4E54

On voit que c'est du binaire car le type de données est "perdu"... mais on voit que les deux binaires sont maintenant strictement identique

Il suffit de "caster" le nom binairement déchiffré :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT *, CAST(DECRYPTBYPASSPHRASE('Le petit chat est vivant...', NOM_CHIFFRÉ) AS VARCHAR(32)) AS NOM_DÉCHIFFRÉ_CLAIR
FROM   T;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NOM_CHIFFRÉ                                                                   NOM_DÉCHIFFRÉ_CLAIR
----------------------------------------------------------------------------- ------------------- 
0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C    DUPONT
0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2    DUPONT

CQFD

Selon toute probabilité, le salage est généré à partir d'une valeur attribué aléatoirement pour chaque mot de passe. Le sel et le mot de passe sont concaténés et transmis à une fonction de hachage et l'information ainsi calculée est stockée avec le sel dans la colonne de la table.

Quel que soit le SGBDR utilisé, chiffrer les données augmente la sécurité, complexifiant la récupération de données en cas de problèmes, mais est devenu indispensable.

Dire que chiffrer les données dans MySQL ne sert à rien est je trouve exagéré, car comme tu l'expliques, le chiffrement utilisé n'est pas suffisamment fort, mais c'est pallié avec un plugin externe.

Il est dit que ce

module externe sensible que des personnes malveillantes peuvent modifier facilement ou supprime

certes, tout comme une personne malveillante peut utiliser ce qui est externe à SQL Server pour l'attaquer, comme notamment l'Active Directory ou même un CVE récent concernant SQL Server tel que 2024-056 :

Un défaut dans Microsoft.Data.SqlClient et System.Data.SqlClient permet à un attaquant, ayant mis en place une attaque de type « adversary in the middle », de déchiffrer, consulter ou modifier le trafic TLS entre le client et le serveur.

On va me rétorquer qu’une mise à jour corrige le problème, au même titre qu'une faille détectée dans MySQL, un plugin qu'il utilise, ou une autre SGBD sera également corrigé.

Il faut garder aussi à l'esprit la base de données n'est pas forcément le point de défaillance en terme de sécurité, si un client lourd d'accès aux données est non fiable en terme de sécurité, ou un site web accédant aux données est faillible, cela revient à installer une porte blindée mais laisser les volets ouverts.

MySQL/mariaDB n'est pas un SGBD d'entreprise, mais sert surtout à des CMS ou des blogs et n'a aucune vocation a traiter des données de santé ou des données financières

Son usage est quand-même significatif en entreprise, de par le fait que 43% des sites Web dans le monde sont fait avec WordPress. WordPress peut héberger des boutiques en lignes et donc des données financières. et il ne faut pas le négliger,c ar ça peut être un point d'entrée pour plomber le LAN (exemple : mise en place d'un lien utilisant une faille de sécurité pour obtenir l'accès à la machine modifiant le site).
Il y a pléthores de sites Web sous WordPress qui se sont fait piraté, mais pléthore aussi qui ne l'ont pas été, car bien gérés. Et dans ces cas de piratage, ce n'était pas le SGBD qui était en cause, et le chiffrement des données n'empêchait pas l'accès aux données.
Même chose pour les Ransonwares, des bases de données SQL Server ont fuité. A relativier par lae fait que ces Ransonwares ont pu agir pour cause de failles de sécurtiés non comblées par mises à jours existantes, et on ne sait pas le taux de bases de données qui étaient chiffrés.

Le poste est clairement subjectif et tourné vers SQL Server.
Vous êtes libre de hash en SHA512 ou tout ce que vous voulez sans aucun souci, même chose si vous voulez utiliser un salt, libre a vous de le faire (et je préfère un salt explicite plutôt que de cacher ca on ne sait trop ou dans sql server)

Par exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT SHA2(CONCAT(my_field, salt), 512);

Bien que MySQL propose le chiffrement "InnoDB Data-at-rest Encryption" cela ne concerne que les tables innodb...

Toutes les tables sont normalement en INNODB, y compris les tables systèmes, ca fait des années que je n'ai vu personne utiliser d'autres moteurs de stockage.

Le poste est clairement subjectif et tourné vers SQL Server.

Oui, mais ce n'est pas pour ça qu'il n'est pas intéressant, et tout le monde peut argumenter.

Toutes les tables sont normalement en INNODB

Il y a des alternatives, comme XtraDB

C’est une différence avec SQL Server, on peut utiliser storage engines defférents. Après difficile pour moi de juger objectivement l'intérêt.

À titre d'exemple, Microsoft SQL Server utilise un chiffrement de type SHA_512 (512 bits, donc trois fois plus lourd que MySQL/MariaDB) avec salage interne.

Il me semble que SHA n'est pas un bon algorithme de hachage pour les mots de passe.
Il est préférable d'utiliser des algorithmes comme argon2, bcrypt ou PBKDF2 par exemple, qui demandent plus de ressources et qui compliquent la génération de "rainbow tables" c'est à dire de hash précalculés.

A titre personnel, ce n'est pas à la couche base de données que je laisse le traitement de chiffrement, mais à la couche logicielle, et évidemment, on ne stocke pas les mots de passe dans le code source.

Je ne suis pas expert en base de données, mais laisser le chiffrement à la partie logicielle n'est pour moi pas forcément une bonne idée.

Imagines que ta base de données doit être connectée à un service externe, une API x ou y (ce qui je pense est un cas de figure courant), commet cette API sur laquelle tu n'as pas forcément la main va pouvoir gérer le chiffrement ?

Envoyé par chrtophe

Je ne suis pas expert en base de données, mais laisser le chiffrement à la partie logicielle n'est pour moi pas forcément une bonne idée.

Imagines que ta base de données doit être connectée à un service externe, une API x ou y (ce qui je pense est un cas de figure courant), commet cette API sur laquelle tu n'as pas forcément la main va pouvoir gérer le chiffrement ?

J'utilise des protocoles standards, si je hache mon mot de passe avec Argon2 via mon application A écrite en JAVA, une application B écrite en python sera capable de se connecter également, pour peu qu'elle possède une implémentation de l'algorithme en question.

EDIT:
Si c'est l'application qui gère la partie sécurité, c'est à mon sens plus facile d'utiliser un autre algorithme que de mettre à jour la base de données, ou d'attendre que celle-ci le mette à disposition.
Ceci dit, on est bien d'accord que ce n'est pas une solution universelle, ça dépend des cas d'utilisation.

Envoyé par SQLpro

Microsoft ne communique pas sur l'algorithme de salage ni sur la manière dont cela est fait... Et heureusement. En matière de sécurité et de chiffrement moins on en sait et mieux cela vaut !

Il ne communique pas, mais je ne vois pas en quoi cela offre plus de sécurité, car cela n'empêche personne de mettre son nez dedans.
J'ai l'impression que l'auteur est un fervent partisan de SQL Server. Dommage, il aurait été bien de montrer les réels limites de chaque approche!

Envoyé par steel-finger

Il ne communique pas, mais je ne vois pas en quoi cela offre plus de sécurité, car cela n'empêche personne de mettre son nez dedans.
J'ai l'impression que l'auteur est un fervent partisan de SQL Server. Dommage, il aurait été bien de montrer les réels limites de chaque approche!

C'est exactement ca....

En cryptographie au contraire il faut bien connaitre comment ca fonctionne, cacher l'algorithme est un gros défaut de sécurité qui rend pour moi cette feature juste inutilisable.
Et potentiellement ca cache des vulnérabilités qui ne seront jamais publiés et découvertes (grosse limite des logiciels propriétaires contrairement aux solutions open source)
Dans certains milieux régulés (type medical device, HIPAA, HDS, etc.) il est obligatoire de pouvoir décrire avec précision le fonctionnement des algorithme de hashage de mot de passe, impossible d'utiliser cette feature de SQL Server par exemple dans ce domaine)

Donc effectivement l'auteur a l'air d'avoir de grosses lacunes en terme de sécurité pour dire ca...

Que ce soit SQL Server ou MySQL, ils utilisent des chiffrements dont les algorithmes sont connus