Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je commence à utiliser PostgreSQL depuis peu et j'ai une question par rapport à la sécurité.
Comme je n'ai vu personne d'autre soulevé la question, il soit seulement avoir quelque chose que je ne saisi pas correctement.
Comment PostgreSQL peut-il être sécuritaire alors que la fonction de hachage est MD5 qui n'est plus sécuritaire depuis quelques années déjà?
Y a-t-il une autre de méthode de cryptage des données qui n'est pas mentionné dans la doc?
Merci
Hors ligne
Bonjour,
PostgreSQL support le SSL, vous pouvez donc avoir une connexion entièrement chiffrée. Il support également l'authentification par certificat. Tout se trouve dans la doc : http://docs.postgresql.fr/9.2/ssl-tcp.html
Julien.
https://rjuju.github.io/
Hors ligne
Quant est-il du chiffrement de la base de données même? Par exemple, la table des utilisateurs et des mots de passe?
Tout ce que j'ai par rapport au chiffrement (http://docs.postgresql.fr/9.0/encryption-options.html) mentionne seulement md5.
Est-il possible d'utiliser une autre fonction de hachage cryptographique plus sécuritaire tel que SHA-256?
Hors ligne
Le fichier de la table des utilisateurs comme tous les objets sont stockés dans le répertoire PGDATA, qui n'est accessible qu'à l'utilisateur système postgres. Pour lire le contenu de la table en sql, il faut être super utilisateur sur la base de données.
Le md5 ne concerne que le chiffrement du mot de passe lors de la connexion, encore une fois si vous voulez chiffrer tous les échanges il faut utiliser une connexion ssl. Vous avez également le module pg_crypto qui permet le chiffrement des données coté postgres, ou vous pouvez encore utiliser une partition chiffrée sur le système, les deux solutions ayant leurs avantages et leurs inconvénients. Toutes ces informations sont mentionnées dans le lien que vous indiquez.
Julien.
https://rjuju.github.io/
Hors ligne
Quant est-il du chiffrement de la base de données même? Par exemple, la table des utilisateurs et des mots de passe?
Tout ce que j'ai par rapport au chiffrement (http://docs.postgresql.fr/9.0/encryption-options.html) mentionne seulement md5.
Est-il possible d'utiliser une autre fonction de hachage cryptographique plus sécuritaire tel que SHA-256?
Effectivement c'est un des points faible de PG... Les mots de passe des connexions ne sont pas cryptés... Les algorithmes de hachage n'ayant rien à voir avec du cryptage !
Dans un audit pour une base de données de santé accessible en ligne nous avons soulevé ce point qui est incompatible avec les directives nationales sur le cryptage des données de santé.
Pire, pgcrypto ne permet pas de gérer les clefs de cryptage de manière externe (par boitier HSM par exemple) ce qui induit fatalement de les conserver en local, et comme les comptes de connexion sont des passoires...
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Il va sans dire que je ne suis pas du tout d'accord avec SQLpro mais, bon, c'est habituel. Il a toujours tendance à s'emballer 
Le md5 n'est certes pas du chiffrement mais du hachage. En dehors de ce problème de sémantique, cela ne pose pas de problème en soi. Le gros intérêt du md5 est qu'il est très difficilement réversible. Cependant, si vous voulez ne pas utiliser md5, ce n'est pas un soucis. Passez un outil d'authentification externe. Cela n'est pas les options qui manquent : LDAP, Kerberos, Active Directory, Radius, etc. Il y a de fortes chances qu'une de ces options sache gérer le boîtier dont il parle.
Concernant pgcrypto, il connaît un certain nombre de techniques de chiffrement mais pas celle dont vous parlez. L'un des gros intérêt de PostgreSQL est d'être extensible. Rien n'interdit l'écriture d'une extension qui tirerait parti d'autres solutions de chiffrement, comme l'utilisation de boîtier externe.
Guillaume.
Hors ligne
Je reviens sur cette discussion parce que j'en ais un peu marre de voir la confusion qu'il y a entre hachage et cryptographie...
Donc j'ai écrit un article à ce sujet qui montre la différence entre les deux et montre les solutions de chiffrement avec comparaison entre PG et SQL Server.
Hachage n’est pas cryptage ! De la sécurité des données chiffrées dans les SGBDR
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Effectivement c'est un des points faible de PG... Les mots de passe des connexions ne sont pas cryptés...
Bonjour,
Je tiens à revenir sur ce point car il y a aujourd'hui une grosse confusion sur le stockage des mots de passe. Non!
Premièrement, les mots de passe ne doivent pas être cryptés (ou chiffrés)! C'est une erreur. En effet, un chiffrement est associé à un déchiffrement sans quoi celui-ci n'a aucun intérêt. Pour pouvoir déchiffrer, il faut disposer de la clé de déchiffrement (qu'il soit symétrique ou asymétrique). Le système (Linux ou PostgreSQL) devrait ainsi le stocker (cette clé) et rendrait ainsi complètement caduque le principe même de "cacher" les mots de passe (puisqu'il suffit à l'administrateur système d'avoir accès à cette clé de déchiffrement et de voir tous les mots de passe en clair). Alors non, les mots de passe ne sont pas chiffrés, cela n'a aucun intérêt. C'est absolument dangereux. Par contre, on ne conserve que les hachés des mots de passe dans un système d'où l'usage de MD5 (par exemple) ! Là, l'administrateur système ne peut pas avoir accès à ces mots de passe en clair car aucune clé de déchiffrement n'existe...
Deuxièmement, cela vaut à la fois pour le stockage mais aussi la transmission. C'est-à-dire que si Alice veut se connecter sur le serveur de Bob, elle n'enverra que le haché du mot de passe entré dans son terminal. Alors, vous me direz, « Mais il suffit de prendre la fonction inverse de la fonction hachage pour retrouver le mot de passe... ». L'ensemble des antécédents d'une fonction de hachage cryptographique est très difficilement calculable et est aussi difficile que le décryptage en termes de calculabilité...
Par conséquent, le chiffrement de mot de passe n'est absolument pas recommandé et son absence n'est encore moins un point faible (bien au contraire)...
Dernière modification par empty (21/02/2014 22:25:57)
Hors ligne
Je précise également que cette explication est une grossière simplification des protocoles existants de transmission/communication et que de nombreux autres mécanismes sont utilisés afin de contrer les attaques de type homme-du-milieu (man-in-the-middle attack) si quelqu'un tente d'usurper l'identité d'une personne en utilisant d'un haché de mot de passe qu'il a intercepté (voir protocoles d'échanges de clés avec El Gamal et Diffie-Hellman).
De même, pour le procédé du stockage de mots de passe. En pratique, ce qui est stocké n'est pas le haché du mot de passe (à proprement dit) mais le haché du mot de passe avec une graine (voir seed).
En ce qui concerne le « boîtier externe ». J'en déduis que SQLPro voulait stocker des clé de chiffrement/déchiffrement. Cela est inutile et dérisoire dans ce cadre car l'admin sys peut avoir accès aux mots de passe en clair... Pourquoi rajouter plus de complications pour autant de dangers...
Enfin, ne tentez pas de refaire chez vous l'implémentation des algorithmes de hachage et chiffrement ! C'est la porte ouverte aux failles de sécurité. Il faut toujours utiliser des implémentations existantes qui ont été certifiées et vérifiées formellement (mathématiquement je dis bien tels qu'avec CryptoVerif développé par l'INRIA).
Hors ligne
En ce qui concerne le « boîtier externe ». J'en déduis que SQLPro voulait stocker des clé de chiffrement/déchiffrement. Cela est inutile et dérisoire dans ce cadre car l'admin sys peut avoir accès aux mots de passe en clair... Pourquoi rajouter plus de complications pour autant de dangers...
Ceci est totalement faux.... Visiblement vous n'avez jamais eu à utiliser ce genre de boitier. Une fois générée la clef ne peut être ni ouverte ni détruite par un admin système tant qu'il ne connais pas le mot de passe ou ne détient pas le certificat.
De même d'ailleurs pour les clefs générées dans le SGBDR et qui sont stockées dans les bases.
Encore une fois ce n'est pas parce que PostGreSQL fonctionne d'une manière absurde en matière de sécurité qu'il faut affirmez que les autres SGBDR comme Oracle ou SQL Server fonctionne de la même façon !
Ce qui est triste, c'est que ça fait peur de lire dans votre "CV" de ce forum que vous travaillez au "Laboratoire de Sûreté des Logiciels, CEA LIST" à Saclay... Encore heureux que vous ne soyez qu'un stagiaire... Bref, vous avez encore de nombreuses choses à apprendre !
A +
Dernière modification par SQLpro (22/02/2014 00:48:00)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Une fois générée la clef ne peut être ni ouverte ni détruite par un admin système tant qu'il ne connais pas le mot de passe ou ne détient pas le certificat.
De même d'ailleurs pour les clefs générées dans le SGBDR et qui sont stockées dans les bases.
Tout d'abord, je tiens à remarquer que vous ne faîtes aucune remarque sur le reste de mon message, j'en conclus donc que vous reconnaissez avoir tort sur tous les autres points.
Ensuite, pour l'utilisation d'un boîtier de chiffrement externe, il ne s'agit pas du tout de stockage de mots de passe chiffrés mais d'un système physique de clés publiques/privées. On en revient donc à ce je disais dans mon premier message, les mots de passes ne doivent pas être retrouvables par le serveur. C'est le cas avec de tels boîtiers, il n'y a plus d'utilisation de mot de passe entre le client et la base de données, mais des certificats et une autorité de certification. Au final, les problématiques de sécurité ne se retrouvent que déplacées entre l'utilisateur et ce boîtier.
Encore une fois ce n'est pas parce que PostGreSQL fonctionne d'une manière absurde en matière de sécurité qu'il faut affirmez que les autres SGBDR comme Oracle ou SQL Server fonctionne de la même façon !
Je parlais de sécurité de manière générale et non pas de PostgreSQL, et je n'ai absolument rien affirmé sur les autres SGBDR. Merci de ne pas détourner mes propos à vos propres fins, ni d'affabuler ainsi.
PS. Wikipédia : « L’argument d'autorité consiste à invoquer une autorité lors d'une argumentation, en accordant de la valeur à un propos en fonction de son origine plutôt que de son contenu ». Pour répondre à votre invective, je tiens à souligner qu'après quelques recherches, il m'a semblé drôle d'apercevoir que vous vous proclamiez « Conférencier » à l'Université Paul Sabatier. Cependant, peut-être faudrait-il rappeler ici que le titre de « Conférencier » n'existe pas. « Lecturer » dans la littérature anglo-saxone, correspond au titre de maître de conférences en France qui est un titre attribué par la titularisation d'un poste avec un niveau doctorat. Je ne trouve aucune page Internet de l'Université Paul Sabatier vous recensant en tant qu'un de ses personnels. L'université peut faire appel à des intervenants (terme officiel: vacataire) mais cela n'a rien à voir avec « maître de conférences » car ceux-ci sont appelés à faire des prestations. Je vous prierais donc de bien vouloir éviter de critiquer votre prochain, si vous n'êtes pas honnêtes... De plus, il ne me semble pas que vous soyez expert en cryptologie alors plutôt que d'invoquer un argument d'autorité, préférez plutôt le débat constructif. « Bref, vous [aussi] avez encore de nombreuses choses à apprendre ! »
Hors ligne
Pages : 1
