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

la s�curit�, c'est un m�tier !
Pas le mien.

Ca ne m'emp�che pas d'avoir "les yeux ouverts" sur "ce qu'on rencontre en entreprise".
Impl�mentations de TDS sous SQL server dans diff�rentes entreprises : retours terrain :

• gestion du certificat non pris en charge ("c'�tait pour faire un test et c'est pass� en prod")
• flux en clair (ah bon les donn�es sont en clair entre le client et le serveur ?)
• toute connexion acc�de, dans les faits, aux donn�es en clair ("tu comprends, la gestion du chaque cas est complexe, c'est pas comme si on n'avait pas de s�curit�")
• copies du certificat ("on stocke le certificat avec les donn�es, comme �a c'est plus simple pour le DRP")

Ce que je sais de la s�curit� c'est que c'est pas 1 techno qui fait le TAF, mais la volont� politique de son op�rationnalit� effective.

Pour moi, il est clair que cette volont� est beaucoup plus affirm�e chez M$ que chez MariaDB/MySQL.

Envoy� par kedare

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.

Si je comprends ta position, il ne vaut mieux ne pas crypter qu'utiliser un cryptage dont tu ne connais pas la m�thode de salage.

En tant que novice le terme "salage" me parait suffisant en lui m�me pour le dissocier de l'algorithme de cryptage.
O� est le probl�me ?

Bonjour,


Je regrette juste que cet article n'�voque pas le co�t CPU du chiffrement et le temps de restitution des donn�es aux utilisateurs. Quid des performances ?

Sauf � h�berger des donn�es dans le Cloud, il y a d'autres moyens de prot�ger l'acc�s aux donn�es que de les chiffrer sur le disque de stockage.

Merci, en tout cas, pour cet article tr�s int�ressant.


Denis.

oh, cool, merci