Commentaires

Bonjour,

Mieux vaut tard que jamais... 2 correctifs de fonctions dans lySQLiteFields :

Code pascal :

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

1
2
3
4
5
6
7
8
9
function  TlySQLiteTable.getSubsetFieldByIndex(aCol, aIndex: integer): TlyField;
begin
  if (aCol<0) or (aCol>FColCount-1) or (aIndex<0) or (aIndex>SubsetCount-1)
  then Result:=nil
  // correction du 18/04/2024
  // else Result:=TlyField(FFields[Subset[aIndex]]);
  else Result:=TlyField(FFields[Subset[aIndex]*FColCount+aCol]);
  // fin correction
end;

Code pascal :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
function TlySQLiteTable.Locate(aValue: string; aCol: integer): Boolean;
var
  i, l, index: integer;
begin
//  FSubsetIndex:=-1; // comme ça, Next place sur First !
  // toute nouvelle recherche efface et reconstitue l'ensemble résultat
  SetLength(Subset, 0);
  if (aCol<0) or (aCol>FColCount-1)
  then Result:=False
  else begin
    for i:=0 to FRowCount-1
    do begin
      index:=i*FColCount+aCol;
      if TlyField(FFields[index]).AsText=aValue
      then begin
        l:=Length(Subset);
        SetLength(Subset, l+1);
        // correction du 18/04/2024
        // Subset[l]:=index;
        Subset[l]:=i; 
        // fin correction
      end;
    end;
    Result := (Length(Subset) > 0);
  end;
end;

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

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...

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 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.

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 ?

À 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.

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.

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.

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.

Autre méthode :

Code :

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

1
2
3
4
5
6
select t2.* 
from 
 (select user_id , max (finished_at) as finished_at 
  from [action]  
  group by user_id  ) t1
inner join action t2 on t1.user_id = t2.user_id and t1.finished_at = t2.finished_at