Discussion :

[sheridan08]

Bonjour à tous ,
comme le titre l'indique ,je cherche à sécuriser les mot de passe de ma base de donnée postrgres .
j'ai remarqué qu'en tant que administrateur tout mes mot de passe sont en clair .
ma question est la suivante : y'a t-il une configuration à faire pour que ces mots de passe soit crypter? ou doit je utiliser un algorithme de cryptage dans mon application (crypte et decrypte).
je veux toutefois avoir la possibilité de recuperer ces mots de passe pour des tests d'authentification.
merci de m'orienter

[SQLpro]

il existe une contribution nommé pg_crypto pour chiffrer les données. Cependant j'ai démontré que c'était une vrai passoire qui ne résistait pas à l'analyse fréquentielle car il n'y a pas de "salage" des données à crypter, contrairement à un SGBDR professionnel comme SQL Server . À me lire : http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr

A +

[Invité]

Pour répondre à Sqlpro, prendre une seul étape et dire qu'elle n'est pas sécurisante c'est un peu du troll non ? Ou t'as juste répondu sans connaître le SGBD et les pratiques de mise en production qui vont avec ?

Pour les étapes de cryptage il faudra faire des recherches sur :

• Chiffrement du mot de passe stocké (attention à sens unique, on ne peu pas le décrypter)
• Chiffrement de colonnes spécifiques
• Chiffrement de la partition de données
• Cryptage des mots de passe sur le réseau
• Chiffrement des données sur le réseau (SSL)
• Authentification de l'hôte SSL
• Chiffrement côté client (Merci Meter Wayne)

@+

[sheridan08]

pour le premier point , si je chiffre sans pouvoir récupérer après le mot de passe en clair .
comment faire alors des test de vérification entre ce que j'ai dans mon application et ce qui se trouve dans la base données?

[estofilo]

L'erreur est de vouloir comparer le mot de passe saisi avec une version en clair.

Cette méthode est essentiellement abandonnée en faveur des fonctions de hachage à sens unique.
Le principe est:
- ce qu'on stocke en base, c'est chaque résultat de la fonction de hachage appliquée à chaque mot de passe. Le mot de passe initial n'est stocké nulle part, ni en clair, ni en chiffré.
- lorsqu'un mot de passe saisi doit être testé, on compare son hachage avec celui stocké en base.

Si quelqu'un vole les données de la base, il ne peut pas retrouver les mots de passe en clair puisque ces fonctions de hachage sont réputées à sens unique (impossible de retrouver l'entrée en partant de la sortie).

De plus pour éviter une comparaison en masse avec des dictionnaires spéciaux de mots de passes pré-hachés, toujours en cas de vol de toute la base, on combine la fonction de hachage avec un sel aléatoire qui multiplie les possibilités pour un même mot de passe en clair. L'article rainbow tables de wikipedia explique ça assez bien.

[SQLpro]

L'erreur est de vouloir comparer le mot de passe saisi avec une version en clair.

Cette méthode est essentiellement abandonnée en faveur des fonctions de hachage à sens unique.
Le principe est:
- ce qu'on stocke en base, c'est chaque résultat de la fonction de hachage appliquée à chaque mot de passe. Le mot de passe initial n'est stocké nulle part, ni en clair, ni en chiffré.

ça c'est faux, parce que le risque de télescopage existe. On utilise donc la fonction de hache pour aller vite et en cas de pluralité de réponse, alors on compare le clair en décrypté, tout cela dans une session SSL au minimum.

A +

[estofilo]

Non il n'y aucun téléscopage puisqu'on cherche si un seul mot de passe haché est égal à exactement le même mot de passe haché.

Si x=y alors H(x)=H(y), c'est la propriété de base d'une fonction au sens mathématique, et ça permet de tester un mot de passe haché avec 100% de confiance.

Il se trouve qu'il y a une autre utilisation du hachage en tant que signature numérique qui s'appuie sur le fait que si H(x)=H(y) alors il y a une grande probabilité que pour x=y. C'est dans ce cas de figure qu'on s'inquiète des collisions où justement x n'est pas égal à y alors qu'ils ont les mêmes H. Pour les mots de passe c'est hors sujet.

Qui plus est, des utilisateurs différents peuvent choisir le même mot de passe, donc les mots de passe hachés n'ont pas vocation à être uniques.

[SQLpro]

Tu as raison, j'ai dit une connerie... C'est le couple user + mdp qu'on vérifie...

A +