Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 9 sur 9
  1. #1
    Invité régulier
    Inscrit en
    février 2007
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 17
    Points : 5
    Points
    5

    Par défaut Déploiement avec accès BDD

    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 !

  2. #2
    Expert Confirmé
    Avatar de tyrtamos
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    2 285
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 2 285
    Points : 3 780
    Points
    3 780

    Par défaut

    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 :
    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.
    Ne rien ranger permet d'observer la loi universelle d'entropie: l'inévitable convergence vers le chaos...
    Mes recettes python: http://www.jpvweb.com

  3. #3
    Invité régulier
    Inscrit en
    février 2007
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 17
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par tyrtamos Voir le message
    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 ?

  4. #4
    Expert Confirmé
    Avatar de tyrtamos
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    2 285
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 2 285
    Points : 3 780
    Points
    3 780

    Par défaut

    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 )
    Ne rien ranger permet d'observer la loi universelle d'entropie: l'inévitable convergence vers le chaos...
    Mes recettes python: http://www.jpvweb.com

  5. #5
    Membre du Club
    Profil pro Olivier
    Inscrit en
    avril 2010
    Messages
    31
    Détails du profil
    Informations personnelles :
    Nom : Olivier
    Âge : 43

    Informations forums :
    Inscription : avril 2010
    Messages : 31
    Points : 50
    Points
    50

    Par défaut

    Citation Envoyé par johnalias110 Voir le message
    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

    Bon week-end

  6. #6
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    5 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 5 381
    Points : 7 535
    Points
    7 535

    Par défaut

    Salut,

    Citation Envoyé par johnalias110 Voir le message
    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
    Architectures Post-Modernes

  7. #7
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    5 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 5 381
    Points : 7 535
    Points
    7 535

    Par défaut

    re-Salut,

    Citation Envoyé par tyrtamos Voir le message
    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
    Architectures Post-Modernes

  8. #8
    Membre confirmé
    Homme Profil pro Christian Havard
    Développeur informatique
    Inscrit en
    mai 2011
    Messages
    149
    Détails du profil
    Informations personnelles :
    Nom : Homme Christian Havard
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2011
    Messages : 149
    Points : 223
    Points
    223

    Par défaut Analyse correcte du problème

    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.

  9. #9
    Invité régulier
    Inscrit en
    février 2007
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 17
    Points : 5
    Points
    5

    Par défaut

    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...

    Citation Envoyé par chticricri Voir le message
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •