Discussion :

[celeborn56]

Bonjour,
j'utilise un wiki portable Framasoft, mais malheureusement, ne l'ayant pas utilisé pendant un moment, j'ai perdu le mot de passe admin.
J'ai regardé s'il y avait une manière de faire mais les solutions données sont pour une base locale.
Quand je récupère mes fichiers sous une autre base, les users sont en hexa et mot de passe en blob, du coup impossible de les lire ni d'y accéder nativement sans copie de la base...
Quelqu'un aurait-il une solution ?

[al1_24]

Quel serait l'intérêt de poser un mot de passe sur une base de données si n'importe qui peut y accéder ?

[celeborn56]

je ne pensais pas que la base était cryptée, le mot de passe était surtout pour que n'importe qui ne puisse pas créer des pages n'importe comment.

je précise qu'il n'y avait pas de mot de passe root pour MySQL.

[Artemus24]

Salut celeborn56.

Si tu as perdu le mot de passe du user root, il existe une procédure pour le récupérer.
Mais pour cela, tu dois être en local sur ton SGBDR MySql et être en mode administrateur sur ton serveur (je parle de l'ordinateur).

Si c'est celui d'un compte quelconque, il suffit de demander à l'administrateur de t'en donner un autre.

Mais si tu n'es pas en local, tu ne peux rien faire !

je ne pensais pas que la base était cryptée

De quoi parles-vous ?

Si c'est du mot de passe de votre compte user qui permet d'accéder à MySql, il est stocké dans le coeur du SGBDR MySql.
Et en effet, il est chiffré en MD5. Lire ce lieu au sujet de la fonction MD5() :
--> https://dev.mysql.com/doc/refman/5.7...l#function_md5

Si c'est le mot de passe applicatif, il est stocké dans votre base de données, et il est chiffré.
Maintenant avec quelle méthode, je n'en sais rien car il en existe plusieurs.

@+

[celeborn56]

non non il n'y pas de mot de passe root pour accéder à MySQL.
C'est bien le mot de passe admin de MediaWiki que je cherche à extraire mais effectivement il est crypté.
Je n'ai juste qu'un compte/pwd d'un user pouvant modifier les pages du wiki.
Je n'ai pas accès à toutes les tâches de l'admin.

[Artemus24]

Salut celeborn56.

Et qu'elle est le rapport avec MySql ?
Nous sommes dans un forum consacré uniquement à MySql.
De ce fait, nous ne résolvons pas les problèmes des autres produits, sauf si cela à un rapport avec MySql.

C'est bien le mot de passe admin de MediaWiki que je cherche à extraire mais effectivement il est crypté.

Dans ce cas là, on ne peut rien pour vous. Désolé !

@+

[celeborn56]

Ma discussion a été déplacée par un admin qui pensait que c'était le bon endroit.
Le lien avec MySQL c'set que les users sont bien sous MySQL à priori cryptés.
Je ne comprends pas qu'en tant que root je ne puisse pas réinitialiser les mots de passe même si ceux-ci sont cryptés.
ceci dit, vu qu'il me reste un user qui peux créer, modifier les pages du wiki, je vais m'en contenter.

Si personne n'a une idée lumineuse, je mettrais le post en résolu bien qu'il n'y ait pas de solution d'ici la fin du we.

[SQLpro]

Il est parfaitement normal qu'un admin système fusse t-il "root"ou Dieu le père n'ait pas accès à des données en outrepassant la sécurité des données ! Un admin système s'occupe du système et n'a rien à faire à lire les données des utilisateurs. Imaginez un seul instant que les informaticiens de l'armée ou de la Présidence de la république aient accès aux données des plans de guerre des généraux ou aux rapport des services secrets destinés à la présidence !!!

Une base de données sert à se protéger des indiscrétions des informaticiens ! Et ce n'est pas du luxe quand on sait que 80% des attaques informatiques viennent de l'intérieur...

A +

[celeborn56]

je pensais que le root MySQL était plus considéré comme un admin BDD comme sous oracle. Il ne peut effectivement pas lire un mot de passe mais il peut le réinitialiser.
C'est juste ce que je lui demande.

Si les données sont en base, un admin bdd a parfaitement les droits pour tout lire et, pour ce qui est de l'armée, est accrédité secret défense selon ce à quoi il a accès.
Donc ne passons pas dans la paranoïa...

Tous les informaticiens de l'armée n'ont pas accès à toutes les bases de données...

[SQLpro]

je pensais que le root MySQL était plus considéré comme un admin BDD comme sous oracle.

Je ne pense pas que sous Oracle le compte système, même root, ait un pouvoir aussi grand, en vertu d'un principe de base qui est la séparation des données et celle des programmes. Mais je vais me renseigner auprès de mon collègue...

Il ne peut effectivement pas lire un mot de passe mais il peut le réinitialiser.

Jene pense pas nonplus que cela soit vrai, car ce serait catastrophique. Cela voudrait dire que les utilisateur connecté à ce compte ne pourrait subitement plus accéder à leurs données

C'est juste ce que je lui demande.

Si les données sont en base, un admin bdd a parfaitement les droits pour tout lire et

Absolument pas !!! Cette posture est parfaitement débile. Cela voudrait dire que vous pourriez lire des courrier diplomatique ou des discussions diplomatique... Heureusement et là j'en suis sûr, Oracle permet d'interdire tout accès aux données aux DBA !

, pour ce qui est de l'armée, est accrédité secret défense selon ce à quoi il a accès.
Donc ne passons pas dans la paranoïa...

Tous les informaticiens de l'armée n'ont pas accès à toutes les bases de données...

Heureusement !

A +

[Artemus24]

Salut à tous.

Vous confondez le "compte système" qui dans le jargon de Windows se nomme "le compte administrateur de votre session utilisateur" avec "le compte DBA" qui se nomme "root" et qui se trouve défini en standard dans MySql, et qui lui est un compte utilisateur.
Vous n'avez pas le même niveau de sécurité qui s'applique entre le "compte système" qui est un "compte administrateur", et le "compte DBA" qui est un "compte utilisateur", sur l'ordinateur.

C'est ce niveau de sécurité qui fait la différence entre ce que vous pouvez faire et ce que vous êtes autorisés à faire.

Même si le DBA, en théorie, peut lire et détruire une base de données, l'autorisation de le faire est octroyé par le "compte système".

Le "compte système" a les autorisations pour installer et modifier votre SGBD
Il a le niveau de sécurité "control total" sur le répertoire contenant l'installation du SGBD.
Et donc, il peut autoriser en lecture, écriture, modification, suppression, ... sur les fichiers système de votre base de données.

Tandis que le "compte DBA" a juste le pouvoir d'octroyer les permissions aux autres utilisateurs qui sont définies dans le SGBD, voire administrer le cœur même du SGBD.
De ce fait, même en ayant un "compte DBA", il ne peut faire que ce que le "compte système" lui autorise à faire.

C'est pourquoi, par simplicité de gestion, on donne à la session utilisateur de ce "compte DBA", le rôle administrateur.
Et du coût, il a tous les pouvoirs, ce qui est une énorme connerie, comme celle, par une fausse manipulation, de détruire une base de données.

C'est pourquoi, en cumulant les deux niveaux d'autorisations (système et permission dans SGBD), un DBA peut donner plein pouvoir à un utilisateur pour faire du piratage.
Il est indispensable de ne pas mettre en les mains d'une personne, même bien intentionné, tous les pouvoirs.

Personnellement, je trouve que le niveau sécuritaire sous windows est faiblard, comparé à UNIX, et aux gros système IBM.

@+

[SQLpro]

Personnellement, je trouve que le niveau sécuritaire sous windows est faiblard, comparé à UNIX, et aux gros système IBM.

@+

Parce que certains logiciels comme MySQL autorise et même agissent par défaut dans ce sens ce qui n'est pas le cas par exemple de MS SQL Server ou les adminsitrateurs système n'ont pas défaut aucun droit sur le serveur SQL....

Encore une connerie de MySQL liée à son installation par défaut !

A +

[Artemus24]

Salut SQLPRO.

Je ne parlais pas d'un quelconque SGBD, comme MySql ou Microsoft SQL Server, mais bien du niveau de sécurité de Windows.

@+

[SQLpro]

Salut SQLPRO.

Je ne parlais pas d'un quelconque SGBD, comme MySql ou Microsoft SQL Server, mais bien du niveau de sécurité de Windows.

@+

Alors raconte moi en quoi est moins bon que Linux !

A +

[Artemus24]

Salut SQLPRO.

Sous Unix, la sécurité système est partie intégrante de l'OS, tandis que sous Windows, c'est une surcouche.
Au départ sous Windows (dans les version 3.1 ou 3.11), si je me souviens bien, la sécurité n'existait pas.
Et je rappelle que Windows est apparu après Unix, dans les années 80 (70 pour Unix).
Le premier semblant de sécurité est apparu sous Windows XP.

C'est pourquoi, on utilisait beaucoup les serveurs Unix (comme debian) au niveau professionnel, car bien plus fiable et plus facile à configurer que les serveurs Windows qui ont tances à fréquemment buguer.
Aujourd'hui, c'est moins le cas car Microsoft a fait de gros efforts.

Du coup, et tu me le confirmes, pour palier à ce manque, Microsoft SQL Server ajoute un niveau sécuritaire.

Après, c'est une question d'habitude et de ce que l'on veut faire. Pour ainsi dire, je n'ai jamais travaillé sur un serveur Windows.
Tandis que j'ai déjà utilisé des serveurs Unix, qui selon moi sont plus intuitifs que Windows, même avec la doc.

--> https://framablog.org/2008/09/02/dif...ux-et-windows/

@+

[SQLpro]

Salut SQLPRO.

Sous Unix, la sécurité système est partie intégrante de l'OS, tandis que sous Windows, c'est une surcouche.

Cela fait bien longtemps que la sécurité Windows, notamment celle des serveurs n'est pas une simple surcouche... Cela date du début des années 2000.

Au départ sous Windows (dans les version 3.1 ou 3.11), si je me souviens bien, la sécurité n'existait pas.

La sécurité à toujours existé dans toutes les versions de Windows, même si dans ces versions datant de début 90, elle était embryonaire, car destinée à des postes client ! Pas la mème chose que Linux destiné à faire des serveurs... L première "vrai" version serveur a été Windows 2000.

Et je rappelle que Windows est apparu après Unix, dans les années 80 (70 pour Unix).
Le premier semblant de sécurité est apparu sous Windows XP.

Pas du tout. EN fait avec Windows xp patch 2, la sécurité a été inversée... Auparavant la sécurité était dédiée à des postes utilisateurs dans lequels tout était par défaut ouvert et l'administrateur système, pouvait refermer ce que bon lui semblait. Le patch SP2 a inversé cette façon de faire en fermant d'office tout ce qui était ouvert d'un point de vu sécuritaire et en obligeant à ouvrir un par un les modules accédant à l'extérieur. Pour info la notion de domaine est apparue avec windows 3.1 et la notion de forêts (ensemble de domaines) est apparue avec la version 2000.

C'est pourquoi, on utilisait beaucoup les serveurs Unix (comme debian) au niveau professionnel, car bien plus fiable et plus facile à configurer que les serveurs Windows qui ont tances à fréquemment buguer.

Plus fiable à l'époque c'est indéniables. Plus facile à configurer alors ça c'est du grand n'importe quoi.... La convivialité des IHM étant le fort de MS, il est plus facile et plus rapide de cliquer que de taper un texte incertain... En revanche moins pratique à industrialiser qu'un script...

Aujourd'hui, c'est moins le cas car Microsoft a fait de gros efforts.

C'est même totalement l'inverse car les études montrent depuis 7 à 8 ans que Windows est en avance sur les serveurs Linux en terme de fiabilité (nombre de pannes) et mobilisation (durée cumulatives des pannes)...

Du coup, et tu me le confirmes, pour palier à ce manque, Microsoft SQL Server ajoute un niveau sécuritaire.

Depuis longtemps la sécurité est pleinement intégrée à tous les niveaux...

Après, c'est une question d'habitude et de ce que l'on veut faire. Pour ainsi dire, je n'ai jamais travaillé sur un serveur Windows.
Tandis que j'ai déjà utilisé des serveurs Unix, qui selon moi sont plus intuitifs que Windows, même avec la doc.

--> https://framablog.org/2008/09/02/dif...ux-et-windows/

Cette étude date de 2008... Soit 8 ans ! En informatique 8 ans c'est long !!!!

Il est vrai qu'avant l'arrivéee des serveurs version 2008, Linux était plus fiable :
http://www.iaps.com/2008-server-reliability-survey.html

Voici maintenant la situation :
https://corepointhealth.com/windows-...bility-surveys
On y voir clairement que les dernières versions de Windows ont dépassées les Unix les plus costauds laissant loin derrière le monde Linux !!!!
Voyez les études d'ITC corp sur le sujet...

A +

[Artemus24]

Salut SQLPRO.

Cela date du début des années 2000.

C'est bien ce que j'ai dit, avec l'arrivé de Windows XP.

La première "vrai" version serveur a été Windows 2000.

Je n'ai jamais travaillé sur ce Windows 2000.

Plus fiable à l'époque c'est indéniables.

Nous sommes d'accord !

Plus facile à configurer alors ça c'est du grand n'importe quoi....

Je me rappelle que le fort d'Unix était justement de faire des scripts adaptables pour chaque type d'utilisateur.
Windows ne proposait rien d'équivalent.

C'est même totalement l'inverse car les études montrent depuis 7 à 8 ans que Windows est en avance sur les serveurs Linux

Je te signale que tu dis exactement la même chose que moi.
Windows a fait de gros efforts vis-à-vis de Linux et de ce fait offre plus de fiabilité par rapport à Linux, aujourd'hui.

Depuis longtemps la sécurité est pleinement intégrée à tous les niveaux...

A tous les niveaux de Microsoft SQL Server, pas nécessairement même dans le dernier OS, qu'est Windows 10.

En ce qui concerne les serveurs Windows, je suis d'accord que l'effort a été au rendez-vous.
Mais pour les OS utilisateur, comme Windows 10, je trouve que c'est mieux qu'avant (Windows XP, ou Windows 7, j'ai pas connu les autres OS), mais c'est parfois un peu léger.
Par contre, je déplore des bugs de sécurités lors des mises à jour pour Windows 10, entre autre, je n'ai plus accès aux paramétrages de certains composants sur mon ordinateur.
Mais ça, c'est un autre problème !

@+

[skuatamad]

@celeborn56, si je comprends bien vous avez accès à la base de donnée.
Vous souhaitez réinitialiser un mdp utilisateur (profile administrateur) du Wiki.

Il est probable qu'il y ait une table des users du wiki dans la bdd. Trouvez là et modifier le mdp du user admin en prenant le mdp du user que vous connaissez.

En effet le problème principale est le salage et méthode de hash du mdp, vous ne pouvez donc probablement pas en créer un nouveau sans passer par l'application.
Il faut copier/coller un mdp chiffré existant dont vous connaissez la valeur non chiffrée.

[celeborn56]

@skuatamad : c'était une bonne idée mais le champ password est un Tiny Blob, du coup je ne peux pas le copier sous phpadmin.

Tant pis je ferais avec le compte utilisateur que j'ai, après avoir regardé d'un peu plus près les fonctions admin, à part créer des utilisateurs sup il n'y a pas de différence.

Merci de vous être intéressés à mon problème, même si ça a dérapé un peu ;-)

Bon dev à tous

[skuatamad]

Tu doit pouvoir faire un update, style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
update table_user 
   set colonne_pwd = (select colonne_pwd from table_user where id = <id du user connu>)
where id = <id du user admin>