Comment masquer des informations sensibles comme les mots de passe en texte brut dans les journaux?


10

Je n'ai pas accès à une installation Postgres, donc je ne peux pas vérifier.

Je suis un responsable de la sécurité et je vois des mots de passe en clair dans les journaux:

create user user1 with password 'PLAINTEXT PASSWORD'

Comment les administrateurs de base de données peuvent-ils modifier ou créer leurs mots de passe sans le mot de passe en clair dans les journaux?

J'ai vu cela , qui indique que vous pouvez utiliser un hachage md5 du mot de passe, mais le hachage est également en clair. Y a-t-il une meilleure façon?


1
Si vous faites confiance à vos DBA (car vous ne pouvez pas les appliquer), dites-leur d'utiliser la \passwordcommande de psql.
dezso

Réponses:


11

On dirait que log_statementc'est réglé sur all.

Si vous souhaitez empêcher les mots de passe d'apparaître dans les journaux alors que log_statementest défini sur une valeur qui capture ALTER USER/ ALTER ROLEalors vous voudrez remplacer cela lors du changement de mots de passe. par exemple

BEGIN;
SET LOCAL log_statement = 'none';
ALTER USER ... SET PASSWORD ...;
COMMIT;

Vous devez être un superutilisateur pour ce faire. Les utilisateurs normaux ne peuvent pas remplacer les règles de journalisation.

Ce serait bien si PostgreSQL a soutenu certains paramètres à signalant des états (ou fonctions même) que les utilisateurs sensibles à la sécurité et autorisés à demander qu'ils soient masqués dans les journaux, pg_stat_statements, pg_stat_activity, etc. Il n'y a pas une telle fonctionnalité - mais bon, des patches Bienvenue. Si vous êtes vraiment intéressé, postez sur pgsql-hackers avant d'écrire tout code réel afin de pouvoir obtenir des conseils et des commentaires. Alternativement, parlez à quelqu'un qui contracte le développement.

En général, PostgreSQL s'attend à ce que vous traitiez les journaux comme sensibles.

Il existe d'autres domaines où l'exploitation forestière est un grave problème de sécurité. Par exemple, certaines pgcryptofonctions prennent des clés de chiffrement comme paramètres.


3

La réponse actuellement acceptée ne fonctionnait pas pour moi sur Postgres 9.4, car elle empêchait le mot de passe en clair d'apparaître dans les journaux.

Ce qui a fonctionné pour moi à la place était de générer le hachage de mot de passe localement:

$ username='some_user'; dbpass='some_pass'; echo -n "${dbpass}${username}" | md5sum | awk '{print "md5" $1}'
md5dcca63c0632e24746a19448231cac29c

Puis en insérant cela:

ALTER USER some_user WITH UNENCRYPTED PASSWORD 'md5dcca63c0632e24746a19448231cac29c';

(Note de sécurité: selon l'endroit où vous générez ce qui précède, vous souhaiterez peut-être empêcher votre shell de se connecter à son historique, ou sur un système partagé, vous voudrez peut-être utiliser un utilitaire * nix qui demandera le mot de passe au lieu de l'inclure réellement dans le Il se trouve que je n’étais pas sur un système partagé, ce n’était donc pas un problème pour moi.)


1
Très bien. Une chose que j'ajouterais avec un certain accent est qu'il ne faut tout simplement pas définir les mots de passe en texte clair.
dezso

2
Oui, j'ai considéré cela et l'ai mentionné dans la question. Ce n'est pas encore suffisant pour mes besoins.
schroeder
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.