Discussion :

[mikedavem]

En fait ce n'est pas tant le fait que le DBA voit tout qui me gêne, c'est que le dba puisse se faire passer pour moi au niveau de la base vu qu'il a mon mdp

Je rajouterais qu'en sachant qu'un DBA a accès aux mots de passe en clair, cela peut induire qu'une personne malvaillante qui s'octroye les droits admin (donc devient DBA) a accès aux mots de passe en clair. Pour peu q'un audit soit placé sur les événements intervenant sur les logins celui-ci ne nous alertera pas sur les logins en échec (le hacker connaissant les mots de passe).

++

[Tofalu]

D'un autre coté, les "DBA" qui s'obstine à utiliser des modes de sécurisation clairement déconseillés dans la documentation sont aussi ceux qui ont le mot de passe admin inscrit sur un post-it collé sur la machine.

C'est vrai que ne pas corriger la faille c'est pas bien, mais je suis pas sûr que ça sécriserait d'avantage ce type d'infrastructure

[GrandFather]

D'un autre coté, les "DBA" qui s'obstine à utiliser des modes de sécurisation clairement déconseillés dans la documentation sont aussi ceux qui ont le mot de passe admin inscrit sur un post-it collé sur la machine.

Pour le post-it, tu pousses un peu quand même... La plupart des gens sont quand même capables de mémoriser le mot « toto » sans avoir à l'écrire quelque part...

[sidev]

Enfin, J'ai du mal à bien identifier le périmétre de la vulnérabilité. Le rapport n'est pas très clair. Dans une application lambda, il y'a souvent X utilisateurs de l'application mais utilisant le même compte SQL (compte purement technique avec un password aléatoirement généré). Cela ne doit impacter que le compte SQL qui est invisible pour un utilisateur.

Prenons le cas d'un service informatique qui doit gérer une base de donnée.
Si tous les développeurs n'ont pas les même droits sur la BDD alors le piratage du mot de passe de l'admin par l'un des développeurs peut devenir un danger pour les autres.

[sevyc64]

Si tous les développeurs n'ont pas les même droits sur la BDD alors le piratage du mot de passe de l'admin par l'un des développeurs peut devenir un danger pour les autres.

D'un autre coté, il a les droits admin, donc il n'a peut-etre plus rien à faire des droits des autres développeurs, au pire il peut se les rajouter sur son propre compte

[B.AF]

mouai...En même temps, je connais pplein de soft où les user est géré dans une table genre "TBL_USER", ou "TBL_UTILISATEUR", ou "LOGIN" ou machin ou il a invariablement la colonne "PWD", "PassWord","UserPwd", qui pourra invariablement être déplombé en utilisant un des snippets de MDA/SHA dans la liste des 10 premier googlés....

Alors bon...Et puis le mec qui se fait une infrastructure Windows sans AD, il a peut être oublié deux / trois trucs au passage non ????

[GrandFather]

mouai...En même temps, je connais pplein de soft où les user est géré dans une table genre "TBL_USER", ou "TBL_UTILISATEUR", ou "LOGIN" ou machin ou il a invariablement la colonne "PWD", "PassWord","UserPwd", qui pourra invariablement être déplombé en utilisant un des snippets de MDA/SHA dans la liste des 10 premier googlés....

Euh, s'il s'agit de SHA-2 il va falloir s'accrocher un peu quand même pour retrouver le mot de passe en clair...

[B.AF]

Euh, s'il s'agit de SHA-2 il va falloir s'accrocher un peu quand même pour retrouver le mot de passe en clair...

Où là, comme tu y vas...Comme m'a dit une personne un jour "c'est sécurisé, je vois les petites étoiles dans la boite".

[GrandFather]

Où là, comme tu y vas...Comme m'a dit une personne un jour "c'est sécurisé, je vois les petites étoiles dans la boite".

Ah, tu faisais référence au « piratage par ingénierie sociale », le nom savant désignant l'action consistant à faire les poches de quelqu'un pour mettre la main sur son agenda, et ainsi sur tous les mots de passe qu'il utilise puisqu'il y a 95% de chances qu'ils en proviennent... Ca, effectivement, il n'existe aucun algorithme de hashage qui y résiste.

[B.AF]

Ah, tu faisais référence au « piratage par ingénierie sociale », le nom savant désignant l'action consistant à faire les poches de quelqu'un pour mettre la main sur son agenda, et ainsi sur tous les mots de passe qu'il utilise puisqu'il y a 95% de chances qu'ils en proviennent... Ca, effectivement, il n'existe aucun algorithme de hashage qui y résiste.

Et c'est une grosse part du piratage. La plupart des boites que j'ai vu avoir des pb de sécurité, c'est souvent des trucs assez stupides fait par un gars devant son poste.

Ex: s'envoyer ses mots de passe par email, faire une connerie dans l'application.

Depuis +de 10 ans maintenant, la réalité est plutôt qu'on me demande toujours un niveau de sécurité paranoïaque, mais que dans les faits, le principe de l'avoir est suffisamment rassurant et l'usage explicitement relou pour que personne ne s'en serve (historique, "piste d'audit", "golden copy", stratégies de mot de passe, cryptages, 4 eyes et bla bla bla)

[Leelith]

Il ne peut pas voir les mots de passe des utilisateurs Windows si l'authentification Windows est activé, en plus le fait pour un DBA de voir les mots de passe des utilisateurs n'est pas aussi drammatique que cela étant donné qu'il a le pouvoir de changer ce mot de passe s'il le veut.

bah si c'est dramatique. Un changement de mot de passe, ça se voit directement et tu sais que le DBA l'a fait (normalement). L'utilisation d'un compte X par le DBA grâce au mot de passe récupéré ne se voit pas.

D'ou la nécessité d'avoir le contrôle sur l'administration des comptes, mais non le contrôle sur les comptes eux-même.

[sevyc64]

Exusez-moi si j'ai rater quelque chose, mais je ne trouve pas comment un opérateur lamda, fait, depuis un poste client, pour changer le mot de passe d'un utilisateur SQL.

Pour les configs que je connais, c'est l'administrateur, et uniquement lui, qui peut changer ces mots de passe !!!

On parle bien d' "Utilisateur SQLServer" ici, et non pas d'utilisateur Windows

[GrandFather]

Pour les configs que je connais, c'est l'administrateur, et uniquement lui, qui peut changer ces mots de passe !!!

Le problème autour duquel tourne la discussion n'est pas celui-ci.

La possibilité qu'aurait un administrateur de connaître les mots de passe lui permet de se substituer à un utilisateur totalement à l'insu de ce dernier, sans avoir à modifier quoi que ce soit.

[sevyc64]

Le problème autour duquel tourne la discussion n'est pas celui-ci.

La possibilité qu'aurait un administrateur de connaître les mots de passe lui permet de se substituer à un utilisateur totalement à l'insu de ce dernier, sans avoir à modifier quoi que ce soit

Je suis bien d'accord, mais si l'utilisateur ne peut changer les mots de passe, si c'est l'administrateur qui les fixent, qu'il puisse les voir par la suite, je ne vois pas ou est le problème puisqu'il les connait déjà.

[john1]

pour moi le probleme est que le message est en clair,
que le dba puisse voir un mdp crypté soit, mais en clair, comme les gens utilisent la plupart du temps les mêmes mot de passe pour toutes leurs applis...

[scheu]

C'est un principe de base de la sécurité informatique : un administrateur d'un système doit avoir la main sur la gestion des mots de passe des utilisateurs (les invalider, etc.), mais il n'a pas à les connaître. Etant donné que la grosse majorité des utilisateurs emploient par commodité le même mot de passe pour accéder à différents systèmes, la moindre violation de confidentialité le rendrait immédiatement suspect.

Il est évident que ce principe est loin d'être respecté en toutes circonstances, mais dans le cas d'un SGBDR il le devrait...

Entièrement d'accord
Un administrateur (DBA ou système) doit pouvoir éventuellement se faire passer pour d'autres utilisateurs ou avoir les mêmes droits qu'eux (ex : "su - <user>" sur Unix) mais sans jamais pouvoir connaître le mot de passe en clair des users, car celui-ci pouvant être le même pour Windows, messagerie, etc ...
Donc pour moi c'est bien une faille de sécurité

[lukeni2]

Entièrement d'accord
Un administrateur (DBA ou système) doit pouvoir éventuellement se faire passer pour d'autres utilisateurs ou avoir les mêmes droits qu'eux (ex : "su - <user>" sur Unix) mais sans jamais pouvoir connaître le mot de passe en clair des users, car celui-ci pouvant être le même pour Windows, messagerie, etc ...
Donc pour moi c'est bien une faille de sécurité

Je suis d'accord que c'est une faille mais elle peut facilement être resolue en utilisant l'authentification windows.