Discussion :

[johnalias110]

Bonjour,

Je développe actuellement une application Python se connectant à une base de données situées sur un serveur distant. La connexion permet d'exécuter des fonctions pré-enregistrées. Jusque là, pas de souci si l'utilisateur entre son login / mdp.

L'application sera déployée et je suis en train d'ajouter une gestion des droits pour les requêtes effectuées. Imaginons : niveau 1, accès complet ; niveau 2, accès limité ; niveau 3, accès très limité. C'est donc l'application qui gère ces niveaux d'accès.

Je n'ai donc finalement besoin que d'un seul login / mdp pour me connecter de l'application à la BDD et l'application acceptera d'exécuter les fonctions ou non selon le niveau dans lequel l'utilisateur se trouve.

Pour ma part, le code source peut être distribué sans souci.
Mais mon problème se situe là : comment insérer ce login et mdp dans le code source sans que les différents utilisateurs puissent y accéder. En principe, l'application sera principalement utilisée sous Windows et j'utilise py2exe pour la création d'un exécutable.

Comment puis-je procéder ?

Merci d'avance !

[tyrtamos]

Bonjour,

Voilà comment je ferais:

1- le nom de référence est crypté et n'existe dans le programme que sous sa forme cryptée

2- le nom fourni à la connexion est crypté à la volée et comparé simplement, sous sa forme cryptée, au nom crypté de référence.

Exemple avec le cryptage Sha-1 du module hashlib:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from hashlib import sha1
 
def cryptsha1hex(t):
    """Calcul du SHA-1 du texte fourni """
    cle = sha1()
    cle.update(t)
    return cle.hexdigest()
 
# nom de référence
nom = "Durand"
nomcrypt =  cryptsha1hex(nom)
# résultat: "e7d3e6feda76099997f4b9c35bbd78ab71ed8e83"
 
print cryptsha1hex("Durand") == nomcrypt
True
 
print cryptsha1hex("Toto") == nomcrypt
False

La forme cryptée (e7d3e6feda76099997f4b9c35bbd78ab71ed8e83) se trouve dans le code du programme, mais pas le nom de référence ("Durand").

Pour l'exemple, je me suis contenté de prendre sha-1 du module hashlib de Python, mais je ne sais pas si c'est adapté et assez performant pour ça. Linux qui utilise ce principe a d'autres fonctions de cryptage. En tout cas, il faut utiliser un algorithme de cryptage permettant le cryptage dans un sens mais pas dans l'autre (type clé_publique/clé_privée dont on n'utilise jamais la clé privée).

Je crois que c'est utilisé aussi par les cartes bancaires pour les codes secrets. La puce contient la version cryptée du code et renvoie "oui" ou "non" à chaque demande de comparaison. D'où les cartes truquées appelées "yes-cards" qui répondent "oui" à n'importe quel code saisi...

Dernier point: attention aux encodages: un même nom comportant des accents se cryptera différemment selon son encodage (latin1, utf-8, ...). Il faut être sûr que les comparaisons se feront à encodage identique des noms.

[johnalias110]

Je crois que c'est utilisé aussi par les cartes bancaires pour les codes secrets. La puce contient la version cryptée du code et renvoie "oui" ou "non" à chaque demande de comparaison. D'où les cartes truquées appelées "yes-cards" qui répondent "oui" à n'importe quel code saisi...

Bonjour et merci pour la réponse,

Je crois que ce principe ne répond pas exactement à ce que je souhaite. C'est à peu près ce que j'utilise pour vérifier que l'utilisateur a bel et bien un compte permettant d'utiliser le logiciel. Mais une fois qu'il est connecté, son login/mdp personnel ne sert plus. Il y a un compte "général" pour l'ensemble des utilisateurs qui permet de se connecter à la BDD.

Un petit schéma :

| Pierre PC | <-------Compte Pierre--------> | Application | <----------Compte générique----------> | BDD |

L'utilisateur ne doit en aucun cas connaître ce compte générique, sinon il pourrait se connecter à la BDD sans restriction (niveau d'accès).
Et donc le compte générique ne peut être stocké en clair dans le code source.
L'application devient en quelque sorte le seul "utilisateur" de la BDD

L'idée de cacher le code source me vient à l'esprit, mais c'est difficilement faisable en Python car il y a toujours moyen de décompiler les fichiers compilés. Même quand il s'agit d'un exécutable, il y a toujours moyen de revenir à une forme qui ressemble au code source. Je me trompe ?
Et puis, cacher le code source n'est pas signe de fiabilité...

Une autre idée ?

[tyrtamos]

A mon avis, la seule manière de gérer les droits de façon "solide" est de le faire dans le serveur lui-même. Sur les serveurs de type Unix, on peut gérer des groupes d'utilisateurs avec des droits différents.

Dans le programme d'appel lui-même, on peut utiliser des astuces pour éviter que le login d'accès au serveur n'apparaisse pas trop clairement dans le code, mais, dans un code Python, ça ne dépassera pas ce qu'un ado sera capable de trouver en quelques minutes...

Mais quelqu'un d'autre a peut-être d'autres astuces? (ça pourrait m’intéresser aussi )

[lilive26]

le compte générique ne peut être stocké en clair dans le code source.
L'application devient en quelque sorte le seul "utilisateur" de la BDD
L'idée de cacher le code source me vient à l'esprit, mais c'est difficilement faisable en Python
Une autre idée ?

Hello,
J'ai eu exactement le même probleme à résoudre.
Le plus simple pour moi fut de placer le couple Login/MDP dans un fichier externe du genre ".ini" de facon crypté.
les Login et MDP sont lus par le prog Python au moyen d'une DLL programmée dans un langage sur lequel on peut faire de l'obfuscation (pour éviter autant que possible le reversing).
Cette DLL se charge de lire (et eventuellement d'écrire si les codes changent au cours de l'utilisation du soft), au moyen d'un algoritme de cryptage/décryptage, les Login et MDP cryptés du fichier .ini et les retourne au prog principal qui est en Python.

Une DLL compilée et obfuscée est probablement assez verrouillée pour garantir une "certaine" sécurité, ou du moins une "certaine" discrétion. Mais il faut bien se dire que la rétro-ingénierie fait des "merveilles" et que rien ne tient face à un hacker décidé (et compétent) ayant un bon désassembleur.

Reste une faille très simple à cela : si le code source Python est accessible, il suffit au hacker d'executer le code source en insérant un "print login, mdp" après l'appel à la DLL ...

Au final, je crains qu'il n'y a pas de solution absolument sûr !

la question a été aussi abordée ici et là

Bon week-end

[wiztricks]

Salut,

L'utilisateur ne doit en aucun cas connaître ce compte générique, sinon il pourrait se connecter à la BDD sans restriction (niveau d'accès).
Et donc le compte générique ne peut être stocké en clair dans le code source.
L'application devient en quelque sorte le seul "utilisateur" de la BDD

Satisfaire cette contrainte de façon sûre me semble fort improbable.
Par contre, vous pourriez assez simplement côté serveur de base de donnée n'autoriser d'accès (pour ce compte) que depuis le serveur d'application.
Modalités fonction du serveur de BDD, à voir avec le DBA.

Après il faut blinder côté server d'application pour ne pas avoir "d'intrusion par injection" - mais cela est à faire dans tous les cas.

L'application sera déployée et je suis en train d'ajouter une gestion des droits pour les requêtes effectuées. Imaginons : niveau 1, accès complet ; niveau 2, accès limité ; niveau 3, accès très limité. C'est donc l'application qui gère ces niveaux d'accès.

N1, N2, N3 sont éventuellement des droits que doit avoir l'utilisateur pour effectuer les opérations correspondantes (ou qui changeront leur comportement). En gros, à chaque utilisateur est associé un objet "session" dans lequel il y a un attribut "rights" dont la valeur est dans [ 1, 2, 3 ].

La question suivante est la gestion de l'association "utilisateur => rights" qui peut être globale s'il y a un SSO et une base de donnée distribuée style LDAP dans laquelle on pourra définir un champ "yourapp.rights" pour chaque utilisateur (quand c'est pas le défaut).
Soit c'est une base de donnée "locale"...
Dans tous les cas, on récupère la valeur à l'initialisation de la "session".

Bon courage,
- W

[wiztricks]

re-Salut,

Dans le programme d'appel lui-même, on peut utiliser des astuces pour éviter que le login d'accès au serveur n'apparaisse pas trop clairement dans le code, mais, dans un code Python, ça ne dépassera pas ce qu'un ado sera capable de trouver en quelques minutes...
...
Mais quelqu'un d'autre a peut-être d'autres astuces? (ça pourrait m’intéresser aussi )

Désolé mais pas "d'astuces" pour gérer la sécurité des informations et des accès: des algo. ouverts et robustes qu'on peut montrer, discuter, prouver...
D'autant que cela n'a rien avoir avec ce que fait le code ce sont généralement quelques contraintes à la périphérie.

- W

[chticricri]

En général, les bases de données disposent déjà d'une gestion efficace des droits d'accès. A mon avis, c'est là qu'il faut gérer intelligemment ceux-ci.

L'idéal serait que chaque utilisateur utilise son couple user/password de la BD et
non un utilisateur générique. Mais évidemment, ce n'est pas toujours possible.

J'ai déjà été confronté à ce problème, voici comment j'avais procédé. Dès que l'utilisateur devait avoir un certain niveau de pouvoir, que ce soit en modification voire en lecture, je demandais au DBA de lui créer un couple identifiant/mot de passe. Cela permet une gestion très fine de ce qu'il peut faire exactement.

Tous les autres utilisateur ("très limité") accèdent à la bd via un compte générique "obfusqué" (pardonnez mon franglais) correspondant à des droits intrinsèque à la BD très limités également.

En outre, c'est une procédure stockée, activée au logon qui identifie l'utilisateur par soft. Ladite procédure n'étant, évidemment, pas accessible à l'utilisateur limité.

Pour plus de sécurité, la procédure doit être capable de rejeter toute connexion qui n'a pas été authentifiée rapidement. Ainsi, un petit malin ne pourra pas se connecter à la bd à l'aide d'un outil générique. De toute façon, en faisant soigneusement les choses, à partir de se compte il n'aurait pas d'accès dangereux pour les données. (Pas de select sur les données sensibles, pas de modification ou d'effacement, juste peu-être de l'insertion dans certaines tables)

Ce n'est peut-être pas la panacée, mais cela devrait convenir.
Au pire, on peut imaginer que seuls les utilisateur avec un accès complet
aient leur propre couple identifiant/mot de passe vers la bd, les autres utilisant un utilisateur générique plus limité. C'est plus faible, mais ça marche aussi.

Dans tous les cas, il faut proscrire une connexion générique avec tout pouvoir.

[johnalias110]

Bonjour à tous,

Au final, après vos réponses et d'autres discussions, il est clair qu'il est impossible de cacher le code source et pas très sûr d'utiliser un mot de passe générique...

En général, les bases de données disposent déjà d'une gestion efficace des droits d'accès. A mon avis, c'est là qu'il faut gérer intelligemment ceux-ci.

L'idéal serait que chaque utilisateur utilise son couple user/password de la BD et non un utilisateur générique. Mais évidemment, ce n'est pas toujours possible.

En effet, il s'agit du meilleur moyen. Après conseils, il semble que le passage par un ensemble de vue semble le plus adapté. Je vais donc explorer cette piste.

Encore merci.