Version imprimable
Bonjour tout le monde .
est ce que postgreSQL offre le cryptage de base de données,
soit au niveau base, table ou colonne ?
aussi pour ceux qui connaissent postgre et firebird a la fois,
quels sont les differences, avantages et inconvénients et lacunes des deux SGBD ?
bref comment camparer les deux SGBD ?
Merci et bonne journée .
Le cryptage dans PostGreSQL via PGcrypto est une vaste merde. En effet :
1) le stockage des clefs de cryptage doit se faire sur le serveur pour que les clefs puissent être ouvertes afin de crypter et décrypter => faille de sécurité.
2) le chiffrement n'étant pas "salé", l'analyse fréquentielle permet de casse le cryptage pour des données à fréquence d'apparition connues (nom, n° de sécurité sociale, prénoms...)
Je pense que c'est la même chose dans FireBird. A ma connaissance aucun SGBDR open source ne permet un chiffrement efficace. Pour info les organismes de surveillances du monde bancaire les ont tous refusés. Et ça ne va pas tardé dans le domaine de la santé....
Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr
A +
Merci pour le conseil et pour le lien .
en fait ça pourrait servir pour mon cas, je veux juste une solution pour éviter qu'un utilisateur lambda récupère la base de données en clair et la consulte librement .
a ma connaisance Firebird n'offre "Aucune" solution pour le cryptage de données, SQL server et les autres SGBD du même rang ne sont clairement par moi ,car trop cher pour les types d'applications que je développe
je ne sais pas si SQL server ou oracle express offrent une solution de cryptage. mais même si c'était le cas, la limitation des 1go peut poser des problèmes je pense
Bonne journée .
Pour SQL Server vous avez la version Express qui supporte parfaitement le chiffrement. Les bases de données sont limitées à 10 Go de données (et non 1 go) et vous pouvez avoir jusqu'à 32650 bases de données par instances soit 320 To... Envisagez vous de dépasser les 320 To ?Citation:
Envoyé par Issam
1) SQL Server offre plusieurs solutions de chiffrement ce que je dit dans l'article déjà cité (il suffit que vous le lisiez !)Citation:
je ne sais pas si SQL server ou oracle express offrent une solution de cryptage. mais même si c'était le cas, la limitation des 1go peut poser des problèmes je pense
2) la limitation est bien de 10 Go par base (et non 1go), mais vous pouvez faire plusieurs dizaines de milliers de bases par instance....
A +
Pas du tout. La fonction decrypt() de pgcrypto prend une clef en paramètre, elle peut très bien venir d'une application qui elle-même l'obtient de l'utilisateur.Citation:
Envoyé par SQLpro
Le salage ne s'applique pas au chiffrement avec clef, tu dois confondre avec le hachage cryptographique. Par ailleurs, il n'a pas de rapport avec l'analyse fréquentielle, mais avec les tables de hachage précalculées, ou rainbow tables, cf https://fr.wikipedia.org/wiki/Rainbow_tableCitation:
2) le chiffrement n'étant pas "salé", l'analyse fréquentielle permet de casse le cryptage pour des données à fréquence d'apparition connues (nom, n° de sécurité sociale, prénoms...)
De toute façon pgcrypto ne fait que mettre en oeuvre les algorithmes inventés par les cryptographes, et tout le monde utilise les mêmes.
Ce que postgres ne fait pas c'est le chiffrage global de toute la base. Pour ça on peut utiliser une partition chiffrée, les solutions pour ça sont au niveau du système d'exploitation.
Les bases de données commerciales préfèrent avoir ça en intégré parce que du point de vue marketing, c'est une case cochée en plus dans la liste des fonctionnalités, et ça aide pour être directement conforme à des spécifications du genre PCI DSS.
Du point de vue des solutions libres, c'est sans intérêt de redévelopper ce genre de choses en interne, si ça existe déjà via le système de fichiers.
Cela ne change rien, soit tu stocke sur le serveur sous forme fichier, soit tu stocke sur le client sous forme de fichier ou dans un fichier (exécutable par exemple) dans tous les cas c'est une faille de sécurité...Citation:
Envoyé par estofilo
Dans SQL Server (et comme dans Oracle) les clefs sont stockées de manière chiffrées soit dans la base, soit dans un HSM (Hardare Security Module) c'est à dire un boitier externe inviolable comme celui de THALES (exemple nShield Connect+)
Pièce jointe 196708Désolé mais là tu dis n'importe quoi ! Au lieu d'affirmer des conneries, regarde au moins les articles publiés à ce sujet (dont le mien déjà cité) et si tu ne crois pas les écrit des autres il te suffit de faire un test en installant par exemple un SQL Server express et constater !Citation:
Le salage ne s'applique pas au chiffrement avec clef, tu dois confondre avec le hachage cryptographique. Par ailleurs, il n'a pas de rapport avec l'analyse fréquentielle, mais avec les tables de hachage précalculées, ou rainbow tables, cf https://fr.wikipedia.org/wiki/Rainbow_table
Tous les algorithmes de chiffrement inclus dans SQL Server depuis la version 2005 :
DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 128 bits, DESX, AES 128 bits, AES 196 bits et AES 256 bits.
utilisent un salage automatique afin d'éviter une attaque par analyse fréquentielle !
Voici un article du staff de MS qui précise cela :
https://technet.microsoft.com/en-us/...ql.100%29.aspx
Comme je soupçonne que tu vas même pas lire cela je t'en extrait un morceau :
"
To prevent discovery of plain text content by comparing encrypted values (the second attack), most encryption algorithms include a salt value. Specifying a different salt value generates a very different encrypted output. When using the .NET cryptography classes, you can specify the salt as the initialization vector argument. In SQL Server, a random salt value is always applied to the encryption.
"
Ce n'est pas parce que PostGreSQL en est à l'âge de pierre en matière de chiffrement que tu dois penser que c'est une référence en la matière et que Oracle ou SQL Server ne savent pas faire mieux !!!
Au moins intéresse toi à ce qui se fait par ailleurs pour comparaison au lieu de faire de la désinformation !
C'est d’ailleurs beaucoup ce que je reproche aux aficionados du logiciel libre qui croient naïvement que le libre c'est le meilleur et que les produits commerciaux c'est de la merde qui fait rien de mieux... Au moins ai le minimum d'honnêteté en t'y intéressant ne serais-ce que pour comparer avec PG, ce que moi, je fais constamment !
Argument de base étage quand on a plus rien à dire... Le libre c'est moins cher !Citation:
De toute façon pgcrypto ne fait que mettre en oeuvre les algorithmes inventés par les cryptographes, et tout le monde utilise les mêmes.
Ce que postgres ne fait pas c'est le chiffrage global de toute la base. Pour ça on peut utiliser une partition chiffrée, les solutions pour ça sont au niveau du système d'exploitation.
Les bases de données commerciales préfèrent avoir ça en intégré parce que du point de vue marketing, c'est une case cochée en plus dans la liste des fonctionnalités, et ça aide pour être directement conforme à des spécifications du genre PCI DSS.
Le plus important est la sécurité des clefs. Dans PostGreSQL il n'y a aucune protection des clefs ce qui est une aberration. Ça ne sert à rien de crypter si tu laisse les clefs dans un fichier sur le serveur ou le poste de travail.Citation:
Du point de vue des solutions libres, c'est sans intérêt de redévelopper ce genre de choses en interne, si ça existe déjà via le système de fichiers.
Dans SQL Server tu a le choix de ranger les clefs dans la base (elle sont elle même protégées par d'autres clefs hiérarchisées : clef d'instance, clef maitre de la base, clef de chiffrement....) ou dans un HSM, qui fait que même en volant la base tu ne peut pas déchiffrer sans rétablir toute la hiérarchie des clefs...
Bref voler une base SQL Server chiffrée ne permet pas de la déchiffrer sans toute la hiérarchie de chiffrement (clef d'instance, clef maître de la base, clef de chiffrement...) Alors que dans PG si tu peut voler les fichiers de la base, alors tu peut voler les fichiers des clefs et il n'y a donc aucune sécurité !
Autrement dit, dans PG le fait de mettre les clefs dans un fichier c'est comme si tu mettais ta clef d'appartement sous le paillasson en priant pour que personne ne la découvre !
Voici pour info la hiérarchie de chiffrement de SQL Server :
Pièce jointe 196709
Le jour ou PostGreSQL sera au même niveau de chiffrement que SQL Server on en reparlera !
A +
je parlait de le la quantité de RAM utilisée, je ne sais pas quel effet va avoir cette limitation sur les performances générales du serveur .Citation:
Envoyé par SQLpro
Vous pouvez installer plusieurs instances de SQL Server; chacune utilisant 1 Go de RAM.
Ensuite vous pouvez utiliser SQL Server :
- version WEB qui est en mode SPLA (hébergeur) et peu couteuse (pas plus cher qu'un MySQL ou un PostGreSQL avec tous les outils équivalents) - limites : 64 Go de RAM et 4 CPU (sockets) avec un max de 16 coeurs
- Azure : mode cloud, sans aucune limitation. Paiement à la consommation. Haute dispo puisque répliqué de manière synchrone sur 3 machines simultanément.
A +
Ok Merci,
avec tout ça je pense que j'ai une solution a mon problème :)
Bonne journée .
Cette idée qu'il faut absolument un "fichier de clef" non protégé est une invention de ta part qui ne correspond à rien dans pgcrypto.Citation:
Le plus important est la sécurité des clefs. Dans PostGreSQL il n'y a aucune protection des clefs ce qui est une aberration. Ça ne sert à rien de crypter si tu laisse les clefs dans un fichier sur le serveur ou le poste de travail.
L'appelant des fonctions de chiffrement fournit la valeur de la clef, ces fonctions n'ayant pas à connaitre d'où vient cette clef.
Si tu n'es pas capable de concevoir qu'un opérateur peut mémoriser une passphrase et la saisir quand on lui demande sans jamais la mettre dans un fichier, pour ma part je pense qu'on peut se passer de tes conseils en sécurité informatique.
En ce qui concerne cette affirmation
également sortie de nulle part, tu auras sûrement l'amabilité d'expliquer à quoi sert la fonction gen_salt() si ce n'est à faire du salage.Citation:
le chiffrement n'étant pas "salé"
http://www.postgresql.org/docs/9.4/static/pgcrypto.html
Citation:
F.25.2.2. gen_salt()
gen_salt(type text [, iter_count integer ]) returns text
Generates a new random salt string for use in crypt(). The salt string also tells crypt() which algorithm to use.
Me prendrais tu pour un idiot ? gen_salt() n'est utilisable que pour du hachage car il n'y a pas de moyen de décrypter une fois le salage effectué !Citation:
Envoyé par estofilo
Regarde tous les exemples publiés, tu n'y verra aucune personne effectuant un chiffrement des données d'une table à l'aide de gen_salt() pour ensuite le décrypter....
http://www.postgresonline.com/journa...-pgcrypto.html
http://grokbase.com/t/postgresql/pgs...-in-postgresql
http://www.thegeekstuff.com/2009/05/...with-examples/
http://www.hagander.net/talks/Encryp...PostgreSQL.pdf
Même le MIT en parle :
http://web.mit.edu/jhawk/mnt/spo/pos...EADME.pgcrypto
Arrête de rêver !
Quand au fait de faire retenir à tous les utilisateurs une phrase de passe c'est sur... C'est une sécurité formidable !
A +
Salut
SQLpro, vos liens ont des contenus qui date de 2003 à 2010. pg 9.4 est de 2014 et 9.5 est sortie il y tout juste deux jours!
Je pense que vous devez arrêter de juger de "MERDE" un travail intellectuel dont vous n'avez même pas la capacité de le faire au dixième!
Respectez les autres et on continuera à vous respecter.
@+
Mais dans la version 9.5 il n'y a rien de neuf en matière de chiffrement mis à part ceci :Citation:
Envoyé par alassanediakite
Add pgcrypto function pgp_armor_headers() to extract PGP armor headers
Extrait de :
http://www.postgresql.org/docs/devel...lease-9-5.html
A +
Si on veut être précis, concernant le stockage des clés, on est tous d'accord que le stockage en fichier est dangereux.
L'utilisation d'une passphrase saisie par un utilisateur, outre représenter un danger en soi, n'est tout simplement pas envisageable pour des applications "industrielles".
En revanche, rien n'empêche l'application de se baser sur un HSM pour accéder à la clé de chiffrement des données.
La question du salage des données est effectivement un sujet par rapport à une analyse fréquentielle, mais cette technique n'est techniquement utilisable que dans un décodage d'un texte encodé avec un algorithme de type code césar ou faisant apparaître une correspondance systématique entre des patterns en clair et des patterns chiffrés.
Les chiffrements avec des algorithmes de type DES, RSA, AES ne sont pas sujets à ce type d'analyse.
Hé bien si. Nous savons par analyse statistique quelle est la fréquence des noms de famille en france ou dans d'autres pays. Comme le chiffrement d'un même nom me donne le même cryptogramme, alors je peut savoir rapidement quel sont les martin, dupont, Schmidt, etc.... Je n'ai pas besoin, en pratique, d'avoir cassé la clef !Citation:
Envoyé par yjuliet
A +
Il s'agît juste du readme du package d'installation de pgcrypto pour la version 8.2 (il y a 10 ans) qui traîne quelque part sur un de leur serveur ...Citation:
Envoyé par SQLpro
