Bonjour à tous et merci d'être présent pour m'aider :) 

Que je vous explique, je développe en ce moment un jeu en indépendant. Et pour ça j'ai besoin d'une base de donnée.

Tout se passe bien, je m'y connecte et communique avec sur le jeu. Mais voilà qu'un problème m'est apparu, comment dissimuler les identifiants ? 

Je vous explique, pour me connecter à la base de donnée, j'ai un fichier.h dans le quel j'ai fais des #define USER #define PASSWORD 

Et j'utilise ces define pour me connecter de manière classique. Mais donc dans le code, on voit le mot de passe en dur... Si quelqu'un vient me donner un coup de main au code, peut voir le mot de passe et donc pourra à tout moment faire des gros dégâts sur la base de données.

Alors voilà ma question, comme faire pour utiliser des identifiants, sans pour autant les mettre en dur, et donc les laisser invisible. 

J'espère avoir été assez clair, et pas trop confus. Je vous remercie d'avance de toute l'aide que vous pourrez fournir :) 

Bon, il manque pas mal de petits détails.

On est d'accord que c'est dans du code serveur que vous avez collé ces USER/PASSWORD ?

Parce que, sinon, sur le client, donc sur une machine hostile, votre USER/PASSWORD va se faire cracker en 2 seconde 12 centième par le moindre hacker du dimanche avec un peu d'outillage de reverse-engineering.

Le code binaire n'est pas un coffre fort !!!

En plus, on ne met pas les serveurs de bases de données accessibles depuis l'extérieur, pour limiter la surface d'attaque.

On n'est donc dans une configuration où le code Serveur et la machine serveur de base de données sont administrées par la même équipe.

Dans une configuration Windows habituelle, on fait tourner le code serveur avec un compte de service dédié à l'applicatif et on utilise les fonctionnalités qu'offre un domaine Windows pour de l'authentification intégrée sur le domaine.

Avec SQL Serveur, on peut définir les droits sur une base à partir d'un compte Windows.

Ainsi, un code serveur compromis ne devrait pas pouvoir faire de choses autres que les actions autorisées dans la base de données pour le compte de service dédié au code serveur.

De plus, seul les administrateurs du domaine ont besoin de connaitre le login/password du compte dédié.

Je ne connais pas la stratégie habituelle sous Linux/Unix mais elle devrait être assez proche.

Merci à toi de ta réponse. 

Alors oui, je ne l'ai pas préciser pensant que c'était induis. C'est bien le serveur qui se connecte à la base de donnée, et non le client. le USER/PASSWORD est sur le serveur. 

Alors pour le système de droits, je suis d'accord avec toi, j'y ai pensé. Mais j'ai trouvé un gros défaut: Un nouveau membre rejoins le projet, je lui créer donc un accès à la base de données avec ses coordonnés et je lui met les droits adapté. Bon jusque ici pas de problème. Si cette personne quitte le projet, je supprime son accès à la base de donnée. Mais si il a noté les identifiants du serveur il pourra au moins aller modifier toutes les variables (embêtant dans un jeu en ligne que quelqu'un puisse aller se promener dans la base de donnée, vous en conviendrez )

Alors j'avais pensé à mettre ces identifiants dans un autre fichier, qui sera crypté que seul le serveur peu décrypter. Est-ce possible ? Et si oui est-ce compliqué ?

Et puis en complément de ce qu'a dit Bacelar, un petit peu de paranoïa est bienvenue. En sécurité, on ne stocke jamais un mot de passe dans une base de données, on stocke juste un un truc pour vérifier qu'il est correct. Typiquement, on va utiliser un peu de cryptographie, par exemple, on va stocker le résultat d'une opération cryptographique (SHA,MD5...) dans la base, puis lorsqu'il faut authentifier, on fait le calcul à partir des données fournies par l'utilisateur et on les compare avec celles qui sont dans la base de données, si c'est pareil, tout baigne, sinon appeler la police. L'avantage, c'est que si un brigand vole la base de données, il n'aura pas les mots de passe des utilisateurs. Il n'aura au maximum qu'un moyen de vérifier que le mot de passe entré par l'utilisateur est bien le bon, pas plus.

-
Edité par int21h 22 septembre 2017 à 18:38:44

Je pense que vous avez des problèmes de méthode.

Un code bien conçu permet de travailler avec des couches logicielles inter-changeable.

L'accès aux données dispose généralement de sa propre couche logicielle.

Pourquoi ?

Pouvoir tester le projet avec différents provider de données, SQL Serveur, Oracle, MySQL, fichier XML, fichier plat, etc...

Pouvoir faire des tests unitaires avec une couche d'accès aux données "Mock" qui ne sont que des jeux de données dans des fichiers plats par exemple. Donc passage de tests plus rapide et gestion des données des cas de tests qui se résume à des copie de fichiers.

etc...

De même, dans le cas de l'utilisation d'une couche d'accès au données "SGBD", pour des développement de la couche d'accès proprement dite par exemple, les sources du projets (sous gestion de version SVN ou GitHub ou ...) doivent contenir les scripts SQL (ou autre) de création de la base (et des données des jeux de tests) pour créer la base FROM SCRATCH.

Donc, un environnement de DEV est complètement autonome, pas besoin de la moindre connexion réseau. Donc pas besoin de "créer un accès à la base de données", et encore moins à la base de production.

Pour des problématiques de reproduction de bug, vous pouvez utiliser un environnement de HOTFIX qui dispose d'une version J+1 de la base de production que votre cher DBA devrait déjà avoir au chaud dans ces plans de maintenance et de backup des bases de données qu'il gère.

Il suffit d'une routine de chargement de cette base J+1 vers l'environnement HOTFIX (cryptage des données personnelles, anonymisation, randomisation, etc... en fonction des contraintes légales). Dans cet environnement HOTFIX, vous utilisez un compte de service commun à tout les développeurs. Pas besoin de créer un compte par développeur, on s'en fout de tracer qui à fait quoi car cette environnement sera rincer par la mise à jour J+1 tous les soirs.

Idem pour la phase d'intégration, vous avez un environnement avec un compte de service commun à tous les développeurs.

Les outils modernes comme Visual Studio permettent de gérer facilement des environnements distincts, si vous collez pas vos cochonneries dans le code comme un gros sale.

Enfin, bon, ici, c'est les bases de pratiques nécessaires à l'utilisation de ce qu'on appelle couramment l'IC (Intégration Continue)

https://fr.wikipedia.org/wiki/Int%C3%A9gration_continue

En résumé, vous ne créez pas un compte dans la base de données pour chaque développeur, c'est toujours le même (pour un environnement donné), et les développeurs n'ont pas à connaitre le compte utilisé en production.