Rendre certaines données invisibles à l'utilisateur d'un script

Bonjour,

(Sous Linux) Je fais un script qui se connecte à une base de données.

Pour que la connexion se fasse je dois donner dans le script le login + PW. Donc ce login mot de passe apparaît en clair dans le script...

Je voudrais que l'utilisateur n'ait pas connaissance de ce mot de passe.

Ma première idée a été d'autoriser le script en exécution seule pour les utilisateurs mais le script ne s'exécute pas si l'utilisateur en question n'a pas le droit de lecture dessus.

Je voudrais savoir s'il existe un moyen (ou une technique) pour cacher ce mot de passe dans mon script.

Merci pour votre aide.

PS: Si comme je le crains cette question a été mille fois abordée dans ce forum merci de m'indiquer où car mes recherches n'ont rien donné...

La réponse est relativement simple*: ce n’est pas possible*!

La seule chose possible, c’est l’obfuscation des données, autrement dit écrire login et mot de passe de façon non-immédiatement lisible (par exemple sous forme de valeurs hexadécimales, ou autre “cryptage” plus ou moins exotique). Mais quoi que vous fassiez, s’il s’en donne la peine, celui qui aura accès au script pourra récupérer les données.

J'ai plus qu'à implanter mes gestions d'accès au niveau de mon SGBD...

Cependant les mots de passe sur Linux sont invisibles de l'utilisateur lambda. Il n'existe pas un moyen de reproduire ce mécanisme ?

Sinon je peux toujours écrire un algorithme super compliqué en C et en faire une fonction python. Si les droits en lecture sont nécessaires pour le fonctionnement d'un script peut-on empêcher l'affichage dans un éditeur d'une fonction compilé en C tout en permettant son exécution ?

Et puis me vient un autre exemple. Les navigateurs proposent de stocker nos mots de passe. C'est vrai que dans ce cas précis l'utilisateur du navigateur connait ses mots de passe (encore que...) mais si un intrus farfouille dans les dossier du dit utilisateur il ne trouvera nulle part les mots de passe en clair. C'est bien la preuve qu'il est possible de stocker des mots de passe sans les afficher en clair pour les utiliser ensuite au seul niveau du programme...
De plus il ne peut être question d'un algorithme obscur puisque certains navigateurs sont open-sources et propose la fonctionnalité.

ben non en fait...

Firefox stocke en clair et c'est le mot de passe unique qui est la clef de cryptage...

En effet la réponse est simple il n'y a que l'offuscation...

Merci pour la réponse

Citation:

---

La seule chose possible, c’est l’obfuscation des données, autrement dit écrire login et mot de passe de façon non-immédiatement lisible (par exemple sous forme de valeurs hexadécimales, ou autre “cryptage” plus ou moins exotique). Mais quoi que vous fassiez, s’il s’en donne la peine, celui qui aura accès au script pourra récupérer les données.

---

Je déterre ce topic que j'avais lancé... Je voudrais connaître un moyen simple et efficace de faire de l'offuscation en Python. J'ai déjà l'idée d'algorithme plus ou moins tordus mais comme je pense que d'autres ont dû se pencher sur le problème (pas forcément en python) je voudrais savoir s'il n'existe pas de la doc à ce sujet sur le net. En particulier je serais intéressé par des techniques de programmation en C qui rendrait la décompilation suffisamment difficile. Je suis conscient par ailleurs que tout est question de temps.

Citation:

---

Envoyé par PyNub

Je voudrais que l'utilisateur n'ait pas connaissance de ce mot de passe.

---

pourquoi ?

et surtout pourquoi un accès directe à la base ?

Bonsoir,

Il est possible d'incorporer des binaires (c, ...) dans du code Python (binascii/base64) et de récupérer la sortie (stdout) d'un subprocess... Que l’exécution du binaire donne ou pas le bon pwd peut être tributaire du nom du process parent dans le binaire.

?

@+

Citation:

---

Envoyé par josmiley

pourquoi ?

---

Oui en effet je peux gérer l'accès aux données directement de la base et le mot de passe utilisé alors dans le script serait lié à un utilisateur qui n'aurait que des droits restreints. En fait cette question m'est venue car je voulais n'autoriser qu'un seul type de mise à jour sur une colonne d'une table donnée et empêcher des mise à jour non désirée directement avec un autre outil que mon script (pgadmin, pgsql, etc...). En fait je voulais gérer ce qui est permis de faire sur la base directement depuis le programme. Il faut dire qu'à ce moment là je ne connaissais pas autant que maintenant les possibilités offertes par les triggers, les clauses de contrôle d'intégrité, les vues etc...

Cependant la possibilité (ou l'impossibilité) de pouvoir crypter des données sans l'usage d'une clef externe continue de m'intéresser. Je pense bien que tôt ou tard il est possible de décrypter et je cherche la façon la plus efficace pour que ce ce décryptage arrive le plus tard possible. Disons un programme capable de fournir le mot de passe lors de son exécution mais dont il est impossible en un temps déterminé, en explorant le code de découvrir celui-ci. Le fait que Python soit interprété et donc facilement lisible oblige à utiliser un langage compilé.

Citation:

---

et surtout pourquoi un accès directe à la base ?

---

En gros je voudrais qu'il utilise les ressources de la base de données par l'intermédiaire du script, mais sans qu'il puisse avoir un accès direct à celle-ci avec un autre outil, en connaissant le mot de passe et en utilisant le même poste. Je ne comprends pas le sens de votre question sur l'accès direct. Peut être pensez vous à une application n-tiers (un serveur web, un serveur de BD) ?

Citation:

---

Envoyé par PauseKawa

Que l’exécution du binaire donne ou pas le bon pwd peut être tributaire du nom du process parent dans le binaire.

---

En effet c'est un bonne idée je n'y avais pas pensé... Pour l'instant j'en suis plutôt sur l'algorithme générateur en lui-même. Mais je note cette idée. Merci

Bonjour,

Je n'ai pas essayé, mais j'entrevois une solution (le problème m'intéresse aussi).

1- Pour cacher le mot de passe, on peut dans un premier temps passer ses octets avec xor. On peut faire plus compliqué si nécessaire.

2- On crée une fonction qui contient le mot de passe ainsi caché, et qui va sur appel le décrypter et le renvoyer.

3- On intègre cette fonction dans un script à traiter par Cython: le résultat sera donc compilé en C, donc en binaire.

4- Comme c'est du Cython, il suffira d'importer le module et d'appeler la fonction qui reverra la mot de passe.

Comme on est en Cython, on peut même intégrer dans le module les fonctions pour assurer la connexion avec la base de donnée, ce qui permettrait de ne pas manipuler le mot de passe en clair sous Python.

Celui qui voudra connaitre le mot de passe devra décompiler le module binaire et comprendre le mode de cryptage. Ce qui n'est pas impossible, mais seulement très difficile.

Si cette solution intéresse, je peux proposer du code qui fait ça.

Citation:

---

Envoyé par tyrtamos

Bonjour,

Je n'ai pas essayé, mais j'entrevois une solution (le problème m'intéresse aussi).

1- Pour cacher le mot de passe, on peut dans un premier temps passer ses octets avec xor. On peut faire plus compliqué si nécessaire.

---

Vous voulez dire faire : PW xor CLEF.
Mais dans ce cas il faut stocker la clef quelque part. Celle-ci va se retrouver dans le programme le tout est de bien la cacher. A moins d'utiliser pour passer le mot de passe une clef connu du processus appelant et de celui appelé (celui qui donne le mot de passe). J'ai pensé a utilisé l'heure système on la stocke dans une variable avant le fork. Pour complexifier la chose on peut utiliser le nom de l'exécutable ou le numéro de processus...

Citation:

---

2- On crée une fonction qui contient le mot de passe ainsi caché, et qui va sur appel le décrypter et le renvoyer.

3- On intègre cette fonction dans un script à traiter par Cython: le résultat sera donc compilé en C, donc en binaire.

4- Comme c'est du Cython, il suffira d'importer le module et d'appeler la fonction qui reverra la mot de passe.

Comme on est en Cython, on peut même intégrer dans le module les fonctions pour assurer la connexion avec la base de donnée, ce qui permettrait de ne pas manipuler le mot de passe en clair sous Python.

---

Oui en effet c'est ce que je cherche à faire

Citation:

---

Celui qui voudra connaitre le mot de passe devra décompiler le module binaire et comprendre le mode de cryptage. Ce qui n'est pas impossible, mais seulement très difficile.

---

Oui c'était le sens de ma question trouver l'algorithme avec un bon compromis taille/difficulté.

Citation:

---

Si cette solution intéresse, je peux proposer du code qui fait ça.

---

En effet cette solution m'intéresse...

Bonjour,

Voilà le code et la méthode de la solution proposée.

Il faut, bien entendu, avoir installé cython, ce qui est facile: les Linux modernes ont un paquet cython, et il y a un binaire pour Windows.

Il faut d'abord créer la fonction qui cachera le mot de passe: elle sera utilisée uniquement dans les outils de développement. Dans cette solution, il n'est pas prévu qu'un utilisateur puisse changer le mot de passe, puisque cela nécessiterait une recompilation Cython.

La solution choisie ici est de faire un XOR de chaque caractère avec un masque. Mais comme le résultat sera binaire, il faut ajouter une conversion par base64 pour arriver à un texte qu'on pourra intégrer dans un script. Voir l'exemple qui suit.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#!/usr/bin/python # -*- coding: utf-8 -*- from __future__ import division # Python 2.7   import base64   ############################################################################# def cache_mdp(mdp, masque=137): """cache le mot de passe 'mdp' par un XOR avec le masque        et une conversion base64     """ ch = "" for car in mdp: ch += chr(ord(car)^masque) ch64 = base64.b64encode(ch) return ch64

---

Application:

Code:

---

1 2 3 4 5 6 7 8

mdp = "Paquerette99" masque = 137   print cache_mdp(mdp) 2ej4/Oz77P397LCw   print bin(masque) 0b10001001

---

Maintenant, on va créer le module qui sera compilé en Cython et qui retournera le mot de passe décrypté. Le module s'appellera, par exemple, "mdpasse.pyx".

Dans les différentes possibilités de syntaxe proposées par la documentation de Cython, j'utilise les décorateurs, ce qui me permet d'écrire en "pure Python" (http://docs.cython.org/src/tutorial/pure.html).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#!/usr/bin/python # -*- coding: utf-8 -*- from __future__ import division # Python 2.7   import base64 from cython import ccall, returns, locals   ############################################################################# @ccall # permet à cette fonction d'être appelée par C ou par Python @returns(str) # type de la valeur retournée @locals(mdp64=str, masque=int, ch=str, mdp=str, car=str) # arg. et var. locales def mdpasse(): """retourne en clair le mot de passe caché""" # mot de passe caché mdp64 = "2ej4/Oz77P397LCw" masque = 137 # décodage ch = base64.b64decode(mdp64) mdp = "" for car in ch: mdp += chr(ord(car)^masque) return mdp

---

On ajoute un fichier "setup.py":

Code:

---

1 2 3 4 5 6 7 8 9 10 11

from distutils.core import setup from distutils.extension import Extension from Cython.Distutils import build_ext   ext_modules = [Extension("mdpasse", ["mdpasse.pyx"])]   setup( name = 'mdpasse', cmdclass = {'build_ext': build_ext}, ext_modules = ext_modules )

---

Et on va compiler en console avec l'instruction suivante (il faut se mettre dans le répertoire qui contient le module mdpasse.pyx et son setup.py):

Code:

---

python setup.py build_ext --inplace

---

La conversion mdpasse.pyx => mdpasse.c se fait et la compilation de ce dernier donne le module compilé mdpasse.pyd sous Windows ou mdpasse.so sous Linux. Ce module compilé est le seul fichier à diffuser.

Pour savoir s'il est facile de retrouver le mot de passe, il suffit de lire ce fichier binaire avec un éditeur hexa: on voit bien que seule une décompilation (reverse engineering) permettrait de le retrouver, ce qui n'est pas à la portée du premier venu. Et il faudrait que l'enjeux "vaille le coup" d'un tel effort.

Il ne reste plus qu'à utiliser dans un autre script Python:

Code:

---

1 2 3 4 5 6 7 8 9

#!/usr/bin/python # -*- coding: utf-8 -*- from __future__ import division # Python 2.7   import mdpasse   print mdpasse.mdpasse() Paquerette99

---

Ok?

Bonjour,

Citation:

---

Envoyé par tyrtamos

Comme on est en Cython, on peut même intégrer dans le module les fonctions pour assurer la connexion avec la base de donnée, ce qui permettrait de ne pas manipuler le mot de passe en clair sous Python.

---

Cette solution est bien plus 'propre' car cela exclu la possibilité d'un print.

Pour ce qui est de la décompilation je me suis amusé avec gcc en ne travaillant qu'en int pour finir par retourner la correspondance dans la table des caractères, avec un décalage : Après avoir testé quelques décompilateurs difficile de retrouver le code c d'origine et l'asm n'est pas des plus explicites...

@+

Citation:

---

Envoyé par PauseKawa

Cette solution est bien plus 'propre' car cela exclu la possibilité d'un print.

---

Et dans ce cas, on pourrait changer le décorateur de la fonction mdpasse() par @cfunc (appel uniquement par le C) au lien de @ccall (appel par C ou par Python), ce qui interdirait à cette fonction d'être utilisée directement par le programme principal Python.

Salut,

L'intérêt d'un password est de pouvoir le changer de temps en temps et assez rapidement.

S'il est codé "en dur" dans l'application, devoir re-livrer tout ou partie de l'application va rendre cela plus "compliqué" et tendre à "changer moins souvent": l'intérêt de protéger l'accès via un "password" en sera réduit.

L'intérêt d'un identifiant sera de trouver facilement qui a foutu la grouille côté SGDB pour pouvoir lui demander quelle opération il a pu faire (on peut regarder dans les traces mais remonter au fonctionnel sera plus sportif).

Bien faire passe par la mise en place une infrastructure SSO, définir quels sont les utilisateurs ayant accès au SGDB, leur attribuer des droits,...

Une solution intermédiaire sera de donner un identifiant/password à chaque utilisateur lors de la première connexion avec un protocole plus ou moins sophistiqué, genre: renvoi d'un premier mot de passe dans la boite aux lettres utilisateurs.
note: la plupart des SGDB ont des protocoles ad hoc pour gérer les indentifiants/mots de passe.

Ce mot de passe là pourra être stocké dans les répertoires "utilisateurs" (en clair ou pas) et protéger le fichier correspondant contre les accès par d'autres que le "propriétaire" est quand même "simple.
On peut aussi utiliser une mécanique semblable pour distribuer des clés SSH.

- W

Citation:

---

Envoyé par tyrtamos

Ok?

---

Tyrtamos je te remercie infiniment pour la publication de ce code je vais pouvoir étudier ça. C'est ce que je pensais faire (un module compilé en C) mais je n'avais pas la méthode...

Citation:

---

Pour savoir s'il est facile de retrouver le mot de passe, il suffit de lire ce fichier binaire avec un éditeur hexa: on voit bien que seule une décompilation (reverse engineering) permettrait de le retrouver, ce qui n'est pas à la portée du premier venu. Et il faudrait que l'enjeux "vaille le coup" d'un tel effort.

---

Oui et on peut toujours compliquer un peu plus l'algorithme si on le souhaite...

Citation:

---

Envoyé par wiztricks

Salut,

L'intérêt d'un password est de pouvoir le changer de temps en temps et assez rapidement.

S'il est codé "en dur" dans l'application, devoir re-livrer tout ou partie de l'application va rendre cela plus "compliqué" et tendre à "changer moins souvent": l'intérêt de protéger l'accès via un "password" en sera réduit.

---

Dans l'exemple de Tyrtanos il suffit juste de livrer mdpasse.so pour mettre à jour le mot de passe.

Citation:

---

L'intérêt d'un identifiant sera de trouver facilement qui a foutu la grouille côté SGDB pour pouvoir lui demander quelle opération il a pu faire (on peut regarder dans les traces mais remonter au fonctionnel sera plus sportif).

---

Il vaut mieux prévenir que guérir cependant. Le fait de cacher le mot de passe n'implique pas non plus l'absence d'identification au niveau du SGBD. C'est toujours un utilisateur qui se connecte et les modifications opérées sur la base sont traçable autant pour lui que pour les autres.

Citation:

---

Bien faire passe par la mise en place une infrastructure SSO, définir quels sont les utilisateurs ayant accès au SGDB, leur attribuer des droits,...

---

On est d'accord et j'ai déjà signalé dans mes posts précédents que j'avais envisagé cette solution alors que je ne connaissais pas encore toutes les possibilités offerte par les SGBD du marché (en l'occurrence j'utilise Oracle et Postgre ainsi que SQLite) pour le contrôle de l'intégrité et la sécurité des données.

Il m'est évident maintenant qu'il est plus facile de gérer les accès directement du SGBD. Ceci dit la possibilité d'un login transparent pour l'utilisateur et par l'intermédiaire d'un mot de passe caché dans le programme continue de m'intéresser. Cela peut s'appliquer dans le cadre d'une connexion à un SGBD mais peut se concevoir pour d'autres types de cas.