Sauvegarder le mot de passe MySQL lors du développement en Python ?

Réponse courte

Vous ne pouvez pas.

Si le mot de passe est stocké dans l'artefact qui est envoyé à l'utilisateur final, vous devez considérez-le comme compromis ! Même si l'artefact est un binaire compilé, il existe toujours des moyens (plus ou moins compliqués) d'obtenir le mot de passe.

La seule façon de protéger vos ressources est de n'exposer qu'une API limitée à l'utilisateur final. Créez une API programmatique (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) ou n'exposez que certaines fonctionnalités dans votre base de données via des SPROC (voir ci-dessous).

Quelques choses d'abord...

La question ici ne devrait pas être de savoir comment cacher le mot de passe, mais comment sécuriser la base de données. N'oubliez pas que les mots de passe seuls constituent souvent une protection très faible et ne doivent pas être considérés comme le seul mécanisme de protection de la base de données. Utilisez-vous SSL ? Non? Eh bien, alors même si vous arrivez à cacher le mot de passe dans le code de l'application, c'est quand même facile de le sniffer sur le réseau !

Vous avez plusieurs options. Le tout avec différents degrés de sécurité :

"Rôle d'application"

Créez un utilisateur de base de données pour l'application. Appliquer l'autorisation pour ce rôle. Une configuration très courante consiste à n'autoriser que les opérations CRUD.

Avantages

• très facile à configurer
• Empêche DROP requêtes (par exemple dans les injections SQL ?)

Inconvénients

• Toute personne voyant le mot de passe a accès à toutes les données de la base de données. Même si ces données sont normalement masquées dans l'application.
• Si le mot de passe est compromis, l'utilisateur peut exécuter UPDATE et DELETE requêtes sans critères (par exemple :supprimer/mettre à jour une table entière d'un coup).

Au&auth. atomique

Créez un utilisateur de base de données par application/utilisateur final. Cela vous permet de définir des droits d'accès atomiques même sur une base par colonne. Par exemple :l'utilisateur X ne peut sélectionner que les colonnes far et baz de la table foo. Et rien d'autre. Mais l'utilisateur Y peut SELECT tout, mais pas de mises à jour, tandis que l'utilisateur Z a un accès CRUD complet (sélectionner, insérer, mettre à jour, supprimer).

Certaines bases de données vous permettent de réutiliser les informations d'identification au niveau du système d'exploitation. Cela rend l'authentification de l'utilisateur transparente (il suffit de se connecter au poste de travail, cette identité est ensuite transmise à la BD). Cela fonctionne plus facilement dans une pile MS complète (OS =Windows, Auth =ActiveDirectory, DB =MSSQL) mais est - pour autant que je sache - également possible dans d'autres bases de données.

Avantages

• Assez facile à configurer.
• Schéma d'autorisation très atomique

Inconvénients

• Peut être fastidieux de configurer tous les droits d'accès dans la base de données.
• Utilisateurs avec UPDATE et DELETE droits peuvent encore accidentellement (ou intentionnellement ?) supprimer/mettre à jour sans Critères. Vous risquez de perdre toutes les données d'un tableau.

Procédures stockées avec atomic auth&auth

Écrivez non Requêtes SQL dans votre application. Exécutez tout via les SPROC. Créez ensuite des comptes de base de données pour chaque utilisateur et attribuez des privilèges aux SPROC uniquement .

Avantages

• Mécanisme de protection le plus efficace.
• Les SPROC peuvent forcer les utilisateurs à transmettre des critères à chaque requête (y compris DELETE et UPDATE )

Inconvénients

• je ne sais pas si cela fonctionne avec MySQL (mes connaissances dans ce domaine sont fragmentaires).
• cycle de développement complexe :tout ce que vous voulez faire doit d'abord être défini dans un SPROC.

Réflexions finales

Vous ne devez jamais autoriser les tâches d'administration de la base de données à l'application. La plupart du temps, les seules opérations dont une application a besoin sont SELECT , INSERT , DELETE et UPDATE . Si vous suivez cette directive, il n'y a guère de risque que les utilisateurs découvrent le mot de passe. Sauf les points mentionnés ci-dessus.

Dans tous les cas, gardez des sauvegardes. Je suppose que vous voulez projeter votre base de données contre les suppressions ou les mises à jour accidentelles. Mais les accidents arrivent... gardez cela à l'esprit;)