IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

SQLpro

[Actualité] Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB

Note : 5 votes pour une moyenne de 3,40.
par , 26/03/2024 à 09h28 (9028 Affichages)
Le chiffrement des données dans MySQL/MariaDB est trompeur, inefficace et même dangereux, dans les versions communautaires libres et même dans certaines autres distributions payantes.

Voici pourquoi...

En effet, bien qu'il existe quelques possibilités de chiffrement dans MySQL/MariaDB aucune n'est efficace ni pertinente...

Dans les grands SGBDR le chiffrement le plus employé est le "Transparent Data Encryption" aussi appelé TDE, qui consiste à chiffrer le stockage des bases au niveau du disque. Les données restent claires en mémoire et ce n'est que lorsqu'il faut lire les données sur les disques ou les écrire que le chiffrement déchiffrement s'effectue. Pour cela le SGBDR doit impérativement gérer directement son stockage sans passer par la couche système (ce que font IBM DB2; Oracle Database ou Microsoft SQL Server).
Or ce n'est pas le cas de MySQL/MariaDB qui délègue lectures et écritures disque à la couche OS....
Bien que MySQL propose le chiffrement "InnoDB Data-at-rest Encryption" cela ne concerne que les tables innodb...
Il y a bien un TDE dans l'édition Enterprise.... (payante...), mais le problème est que dans le TDE de l'édition Enterprise, les tables temporaires ne sont pas chiffrées, les sauvegardes (dump) non plus, et les performances sévèrement dégradées...

Quant à chiffrer certaines colonnes de certaines tables, là aussi les méthodes mises en œuvre dans MySQL sont pauvres, inefficaces et inutiles !
Le chiffrement des mots de passe est basé sur l'algorithme SHA-1 (160 bits) non salé...
Or la CNIL indique que pour les données de santé (un exemple parmi d'autres... idem dans le monde bancaire notamment) le hachage doit se faire avec un algorithme d'au moins 80 bits et salé ! Ce que ne permet pas MySQL...
C'est pourquoi il fait souvent l'objet de pénalités pour les clients qui utilisent des bases de données MySQL/MariaDB...
À 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.

NOTE : qu'est-ce que le salage du chiffrement ?
Cela consiste à introduire une information relativement "aléatoire", en complément de l'information que l'on veut chiffrer, afin que deux valeurs identiques une fois chiffrées avec le paramètre de salage ne donnent pas la même valeur de chiffrement afin de lutter contre l'attaque d'informations chiffrée par analyse fréquentielle. Par exemple le chiffrement de deux patronymes identiques "DUPONT" afférents à deux personnes physiques différentes devrait donner pour l'un une valeur binaire différente de l'autre. La figure ci-après donne un exemple de chiffrement dans Microsoft SQL Server ou l'on voit bien que le même patronyme est chiffré de deux manières différentes :

Nom : Chiffrement salé dans SQL Server.jpg
Affichages : 14231
Taille : 55,7 Ko

NOTE : qu'est-ce que l'analyse fréquentielle ?
C'est une technique de cassage du chiffre par analyse de la fréquence d'apparition des mêmes données chiffrées pour toute ou partie d'une valeur chiffrée dans une collection de valeurs dont on sait que certaines valeurs peuvent être répétitives et dont on connait la loi de distribution, même de manière approximative. Par exemple le nom DUPONT est le 22e nom de famille le plus fréquent en France...

Nom : Distribution des 25 premiers patronymes.jpg
Affichages : 5520
Taille : 82,3 Ko

Autre problématique, le chiffrement des colonnes des tables n'existe pas en standard dans MySQL. Il faut recourir à un plugin externe, qui limite le chiffrement à l'algorithme AES en128, 192 ou 256 bits.
Quatre inconvénients : (1) un module externe sensible que des personnes malveillantes peuvent modifier facilement ou supprimer et (2)qui impose d'utiliser le mot de passe en clair à un moment dans les applications, (3) la limitation de la clé de chiffrement et le (4) fait que les données chiffrées ne sont pas salées...
Cette dernière problématique est extrêmement grave, car le salage du chiffrement est indispensable dans les données des bases. En effet, les bases de données portant d’importantes collections de données, une attaque par analyse fréquentielle des données chiffrées est aisé sur des données dont on connait la distribution statistique, comme les patronymes (voir https://www.geneanet.org/genealogie/), les prénoms (https://www.insee.fr/fr/statistiques...mmaire=7635552), les données comptables (loi de Benford), les numéros de sécurité sociale…
De même, les applications devant chiffrer ou déchiffrer doivent à un moment avoir le mot de passe en clair.... 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 !

Autrement dit le chiffrement dans MySQL ne sert à rien...

À titre d'exemple, Microsoft SQL Server utilise un chiffrement interne systématiquement salé, par clé symétrique, asymétrique, certificat, mot de passe, et avec les algorithmes : RC2, RC4, RC4_128, DES, TRIPLE_DES, TRIPLE_DES_3KEY, DESX, AES (128, 192, 256), RSA (512, 1024, 2048, 3072, 4096)...
De plus pour sécuriser le chiffrement, les clés sont protégées par une hiérarchie de clefs depuis la clé d’instance puis la clé de la base, qui protège les clés crées par SQL Server pour le chiffrement des données. Et pour qu'il ne soit pas nécessaire d'exposer la moindre clé dans les applications, le déchiffrement peut être automatisé sans jamais exposer le mot de passe (DECRYPTBYKEYAUTOASYMKEY, DECRYPTBYKEYAUTOCERT) ou encore par des vues de déchiffrement situées dans d’autres bases...
Enfin, il est possible de déléguer la gestion des clés de ,SQL Server par un boitier électronique sécurisé (« Hardware Security Module » technologie appelé EKM : Extensible Key Management) qui s'autodétruit en cas d'intrusion... Exemple Thales Luna

Enfin, le fin du fin est d'utiliser le chiffrement de bout en bout qui laisse les données chiffrées dans la base et les véhicules chiffrées jusqu'à l'application qui peut les déchiffrer pour les afficher. Par exemple la technologie "AlwaysEncrypted" de Microsoft SQL Server. De même le traitement des données chiffrées peut utiliser des zones de mémoire réservées, inaccessibles à d'autres processus, car la mémoire peut aussi être lue par des processus malveillants. On appelle cela des enclaves mémoire sécurisées et cela existe pour Microsoft SQL Server avec la technologie Secure Enclaves...

Tout cela n'existe pas dans MySQL, même dans la version Enterprise, par ce que 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... ou de quelconques données sensibles comme la paye...

Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Viadeo Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Twitter Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Google Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Facebook Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Digg Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Delicious Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog MySpace Envoyer le billet « Dangers du chiffrement (cryptage) des données d'une base de données MySQL/MariaDB » dans le blog Yahoo

Mis à jour 26/03/2024 à 10h07 par Malick (Orthographe + Typo)

Catégories
Sans catégorie

Commentaires

  1. Avatar de CinePhil
    • |
    • permalink
    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 ?
  2. Avatar de Karadoc
    • |
    • permalink
    (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).
  3. Avatar de SQLpro
    • |
    • permalink
    Citation 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...
  4. Avatar de SQLpro
    • |
    • permalink
    Citation 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
    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.
    Mis à jour 26/03/2024 à 19h45 par SQLpro
  5. Avatar de chrtophe
    • |
    • permalink
    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.
    Mis à jour 30/03/2024 à 09h06 par chrtophe
  6. Avatar de kedare
    • |
    • permalink
    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.
  7. Avatar de chrtophe
    • |
    • permalink
    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.
  8. Avatar de fr1man
    • |
    • permalink
    À 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.
  9. Avatar de chrtophe
    • |
    • permalink
    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 ?
  10. Avatar de fr1man
    • |
    • permalink
    Citation 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.
  11. Avatar de steel-finger
    • |
    • permalink
    Citation 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!
  12. Avatar de kedare
    • |
    • permalink
    Citation 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...
  13. Avatar de chrtophe
    • |
    • permalink
    Que ce soit SQL Server ou MySQL, ils utilisent des chiffrements dont les algorithmes sont connus
  14. Avatar de Michel.Priori
    • |
    • permalink
    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.
  15. Avatar de Michel.Priori
    • |
    • permalink
    Citation 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 ?
  16. Avatar de bloginfo
    • |
    • permalink
    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.