Vous n'êtes pas identifié(e).
Pages : 1
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 ! »
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).
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)...
Pages : 1
