Salut,
 
est-il possible de dire à MySQL que l'on veut que telle ou telle base de données soit cryptée?
(sans avoir à passer par des fonctions de cryptage décryptage à chaque fois qu'on insert ou récupère des données).
 
Merci pour vos réponses.

 
Oh, un terroriste.  

???
J'avoue ne pas comprendre...

il te faudrai dévelopé une ptite page php qui cripterai directement tes champs que tu lui envoi et elle se connecterai a une base sql en injectant tes données ... et dans ta page d'admin , tu met requete de décryptage ...

 
Pourquoi tu veux crypter toute ta base ?    C'est un peu une histoire de dingue quand même...  
 
Et puis ça change quoi de la crypter entièrement ? De toutes manières, au bout du compte, c'est le serveur qui va la décrypter, le script de décryptage sera lui aussi dans le serveur...
 
Bref, question inutile. Fin du sujet.

Ok donc ce n'est pas possible de dire à MySql tu cryptes tout ce que tu reçois et tu décryptes avant de renvoyer : faut tout faire à la main...
C'est bien ça?
(Par exemple avec une base Notes, tu peux lui dire qu'elle est cryptée : c'est un peu différent certes, mais j'espèrais que ça existe avec MySQL)

 
Ce n'est pas parce que tu ne connais pas et ne peut imaginer la raison de ce souhait que c'est une question inutile.
Enfin, si tu ne te sens pas concerné, tu n'as qu'à passer ton chemin.

 
A quoi bon la crypter puisque le script de décrytpage est dans le serveur ? Tu vas faire un module de décryptage en AJAX pour le client ? Non ?
 
Bon, donc, tu as la réponse à ta question. Fin du sujet.

non. utilise une partition cryptée en dessous, genre avec luks

J'y pensais un peu effectivement.

 
Il peut crypter tout ce qu'il veut, y compris les DD du serveur, tant que celui-ci continue à renvoyer de manière standard ce qu'on lui demande, il reste tout autant attaquable. A partir du moment où quelqu'un rentre dedant, il récupère la base et les scripts. Si la base est cryptée, il a de toutes manières le script pour la décrypter.
 
La seule solution serait donc des champs entièrement cryptés et décodés par LES CLIENTS EUX-MÊMES après réception des données (Il faut donc créer un programme de décryptage externalisé par rapport au serveur).
 
En dehors de ça, il est complêtement inutile de crypter toute une BDD.
 
Le cryptage des MDP n'est intéressant QUE parce que les CLIENTS sont les seuls à avoir le MDP original.

 
Tu pensais à rien et tu n'as visiblement rien compris concernant les relations clients/serveur dans le cadre d'un site internet. Tant que ce qui sort de ton serveur est standard et non crypté, crypter ta base ne sert à rien.

Hermes, tu es tellement sympathique, doux dans tes propos, respectueux etc... c'est un vrai bonheur.
Je t'invite à aller te masturber un coup pour faire retomber ton agressivité qui déborde.
Pour les relations client/serveur dans le cadre d'un site internet, y a un truc très bien qui s'appelle SSL (https). Ensuite, le but est donc comme tout le monde l'avait compris que même l'administrateur de la base ne voit pas les données (enfin ne les comprenne pas) stockées dans la base, d'où le besoin de crypter les données avec une clé qu'on ne mettra pas dans la base => donc le gars qui récupère la base sans avoir la clé, ben il ne pourra rien en faire.
 

tunnel ssh sinon.

 
Tu es bête ou tu le fais expres ?
 
Tant que l'OUTIL DE DECRYPTAGE de tes données est sur le seveur, il est INUTILE de crypter la base.
 
   

Il y a un moyen utilisé par phpBB par exemple, il permet de crypter toutes les données saisie par un user, les envoyées cryptés sur une table..
Si tu regarde ta table tu as des champs avec des mots crypté 128 bits où tu peu rien y comprendre !!!
mais c'est "irréversible", a "moins" d'avoir comme tu le souhaite, la clef de décryptage
Des que tu saisi des mots dans un champ pour l'envoyé sur le server sql, ca crypte directement grace a une fonction php de cryptage et ca l'envoi crypté sur la bdd..
Renseigne toi, et test phpBB les forum et voi comme ils utilisent leur mode de cryptage
 
Je peus rien trouver de + pour t'aider la lol
++

ça craint sévère de pas stocker les mots de passe en clair.

=> taz : ma profession est de créer des sites internet pour des clients , et si je leur laissaient les mots de passe en clair , je peux etre sur que un jour , un client regardera les mots des utilisateurs inscrits sur son site et testera le meme mot de passe et le meme login sur d autres sites , et là , c est le drame !!!!
 
il faut pas oublier que dans bien des cas , des masses d'argent considérables sont en jeux derriere un simple mot de passe , il est donc NECESSAIRE de crypter les mots de passe en BDD
 
 
 
 
 
pour ma part , j ai le meme probleme que LeMicky : j ai également le besoin de crypter l'ensemble d'une base mysql
 
en faite , je loue des boutiques en ligne à mes clients ( infos : http://www.vendre-en-ligne.fr )
 
 
et je voudrait donner la possibilité à mes clients de modifier leur boutique OFFLINE (en gros , créer un logiciel ou tu importe les informations de la boutique , tu les modifie , et  
les exporte pour mettre à jour ta boutique )
 
et je vais donc utiliser la meme structure de base , mais je ne veux pas que mes clients y aient acces ...
 
 
Hermes le Messager => ce qu essayait d'expliquer LeMicky , c est qu'il voudrait passer par un cryptage par clef ( tout comme moi )
 
avec un cryptage par clé , tu peux avoir l' "outil de decryptage" , mais pas la clé ( ce qui sera le cas de mes clients ) , et il t es donc quand meme IMPOSSIBLE de décrypter les informations ... (à part en force brute , mais sur une clé de 128 bits , il faut soit un supercalculateur , soit un mega cluster , soit 8 ans à tuer sur un PC en 24/24)
 
 
la clé étant dans le logiciel ou directement stockée sur internet en HTTPS , et donc nécéssitant un désassemblage du logiciel , ou un hack du SSL ( ce qui n a jamais été réussi par AUCUN hacker )
 
 
 
 
 
 
evidement , dans mon cas , il reste la faille du flux des données entre la boutique et le logiciel offline ( le client peux analyser les trames réseau qui sont envoyées et recues ) , mais pour ca , il y a SSL qui corrige cette faille.
 
 
 
 
 
 
par contre , j ai beaucoup cherché , et j ai rien trouvé pour crypter une base ...

 
Ce que tu ne comprends pas (au fait on se connait ?    J'ai pas l'impression, t'es nouveau twoua.   ) c'est que la seule manière d'avoir un outil de décryptage qui échappe à celui qui maintient le serveur, c'est de l'installer sur les CLIENTS et donc d'installer un logiciel SPECIAL chez LE CLIENT.
 
Que tu utilises du SSL ou n'importe quoi d'autre, de toutes manières, si ton logiciel de décryptage est sur le serveur, il devient alors complêtement inutile. Point.
 
 

Evidemment, tu auras compris que chopper la cle est un jeu d'enfant si on a la main sur le serveur. Et si tu ne le comprend pas, ben je peux rien pour toi. (d'autant que ce sera la même clé pour tout le monde, et qu'il faudra bien l'envoyer depuis le client, puisqu'on ne peut pas la stocker sur le serveur).
 
Bon bref, j'ai assez discuté avec toi. (et pour l'incompétence, tu repasseras, hein... reste un peu plus longtemps par ici et on en reparle dans quelques semaines...)

 
il y a deux serveurs :
- un dont les données sont cryptés ( pour le offline )
- un dont les données sont claires ( pour le online )
 
le but : le client a acces aux données cryptés et au logiciel de décryptage , mais pas à la clé.
 
 
pour pas qu il ai acces à la clé :
- soit la clé est dans le source du logiciel ( qui est compilé , il faut donc le décompiller pour retrouver la clé , ce qui est concidéré par les plus grosses firmes du monde etre une protection suffisante )
- soit la clé est sur un serveur dont le client n'a pas directement acces : seul le logiciel y a acces en SSL , et de maniere entierement transparente , il faut donc analyser les trames réseau et les décrypter ( alors qu elles sont crypté en 128 bits )
 
 
 
c est exactement le meme principe que les mots de passes sur les fichiers compréssés par winrar ou winzip : sans le mot de passe , tu passe des mois de force brute , et à la fin , t es pas sur d avoir ton mot de passe ...
 
 
 
j ai beau me torturer l esprit , je vois pas en quoi c est un jeu d'enfant !!!
 
 
 
et meme si le client a acces aux données , il a acces à :
- la structure ( et doit donc faire un reverse ingeneering dessus pour pouvoir en faire quelque chose )
- les données ( auxquelles il a déjà acces , donc sans aucun interet )
 
 
effectivement , il est toujours possible de hacker quelque chose , tout comme il est possible de s'amuser à enlever la protection d'un logiciel , ou à se faire un petit kernel perso , ou à s'amuser à faire du force brute sur toutes sortes de serveurs ssh , ftp ou autres ....
 
 
on est jamais à l abris d'une personne peu regardante sur les droits d'auteurs ou particulierement motivée ...
 
 
 
 
 
 
mais bon , il faut qu'il soit vraiment motivé dans ce cas précis ...
 
 
 
 
 
et pour ce qui est des compétences des membres de ce forum , je ne vois pas en quoi elles seraient proportionnelles avec leur implication sur ledit forum ...

le cryptage ça n'existe pas. (le chiffrement oui)
Une clé de 128 bits ? ok, mais pour quel système ? symétrique ? asymétrique ?  
Vu la taille de la clé, ça doit être symétrique : Triple DES ? DES  ? AES ? ça doit être AES (tjrs selon la taille de la clé...) parce que bon...8 ans avec un PC 24h sur 24, en AES, euh...bof quoi   à vérifier
 

Source ?
 
Parce que bon, garantir le secret d'une clé sur le fait qu'elle est compilé avec le logiciel, bof quoi...
 

euh...la dessus, je m'avancerais pas là dessus...Je ne sais pas c'est quoi la taille de la clé d'une archive RAR ou ZIP, mais ça doit pas être un truc de dingue, donc bon, un mois de force brut, bof...

halte à la branlette :
- tu mets ta base de données sur une partition cryptée
- tu fais des VPN IPSEC avec tes clients
 
et voilà.

J'adore entre Hermes dont l'égo n'a d'égal que la prétention et zapan666 qui ne dit que "bof" mais qui n'apporte réellement aucune avancée. Parce que si c'est juste pour dire "vous êtes vraiment trop cons", ce n'est pas vraiment la peine de poster une réponse.

  C'est surtout pour dire que ofal raconte n'importe nawak et on voit bien qu'il ne maitrise pas le sujet
 
Les conseils de Taz ont l'air tres bien

 
Mais dégage twoua, va crypter ta base de merde, va faire péter ton serveur et fous nous la paix, ok ? Si tu veux pas comprendre que c'est complêtement débile de crypter une base de données entières (t'as même pas parlé de crypter des champs), tant pis pour toi et pi vala hein...    

Mais bordel Hermes, tu captes jamais rien toi!  
Si je veux pas que mon admin il puisse voir ce qu'il y a dans la base (parceque c'est super important et que même si c'est l'admin je lui fais pas confiance ...), je zip la base avec un mot de passe (un sha1() du nom de ma maman concaténé avec l'age de mon chat) et voila, il peut même taper du pied mais il verra jamais ce qu'il y a dedans! Bon après je peux plus enclancher mo appli, mais au moins la bdd est safe ... Faut toujours tout t'expliquer ...

Qui a décrété cela à part toi? Comme je le disais, tu me parais bien prétentieux jeune homme, plein de certitudes, agressif et franchement étroit d'esprit.
Allez comme je suis gentil, je te donne la phrase que tu aurais dû écrire :
"Je ne comprends pas l'intérêt de crypter une base de données entière" -hors sujet mais pour ta culture personnelle, c'est la base entière et non les données entières donc sans s à entière- au lieu d'émettre un jugement sur l'opportunité, qui manifestement t'échappe malgré les divers interventions ayant eu pour but de t'expliquer un tant soit peu l'intérêt d'une telle chose, et même si tu n'es pas d'accord, il n'est pas dit que ton opinion soit meilleure que la mienne ou celle des autres, de crypter une base de données dans sa totalité.
 
J'ose espérer que tu n'as pas de collègue de travail.

Ce message est juste destiné à LeMicky (et à ceux qui ne mangent pas de la mauvaise humeur au petit déjeuner) :
 
 
 
voilà ce que j ai trouvé pour crypter les données d'une base entiere : http://www.safelogic.com/cryptographie_references.html
 
 
 
et moi , pour avoir le cryptage des champs avec , je vais utiliser ca , je pense : http://msdn2.microsoft.com/fr-fr/library/ms172901.aspx
 
 
et ouiiiii , microsoft propose de chiffrer une base de données entiere dans certaines versions de SQL server ....
 
comme quoi , ca doit pas etre si débile que ca de vouloir une base de données crypté ....

 
Pour le premier lien que tu donnes, je dois être aveugle, mais je vois rien qui permet de crypter une base de données.
 
Ensuite pour lesecond lien, apprend à lire :
 

 
A ton avis, qqu qui a la main sur le serveur, tu peux m'expliquer quel problème il va avoir pour lire ta BDD ? Etant donné qu'il aura de toutes manières le password pour lire les données ?
 
Bref, tu relis tout ce que j'ai écrit et peut être qu'avec un peu de chance tu comprendras le problème.
 
La seule solution est d'avoir une solution totalement externalisée comme par exemple disposer d'un serveur SQL chez un hébergeur X et de PHP ou autre langage serveur chez un hébergeur Y, et même comme ça, il y a toujours manière de lire les trames... Ensuite, l'hébergeur Y pourra de toutes manières et quoi qu'il arrive lire les données sur la BDD de l'hébergeur X. Par contre l'hébergeur X ne pourra pas "facilement" lire les données de la BDD sur son propre serveur.
 
La seule VRAIE solution donc, et c'est ce que je dis depuis le début, c'est d'avoir un outil de décodage EXTERNE CHEZ LE CLIENT et non plus au niveau du serveur.

Hermes, tu fais des progès: y a pas "débile" dans ton poste.
Ensuite, l'outil peut-être sur le serveur, il suffit que la clé simplement soit sur le client (car sans clé, tu ne fais rien).

 
Ben non, ça suffit pas que la clé soit chez le client. Ta clé tu la transmet et elle est aisément récupérable. On le voit parfaitement avec l'exemple pour SQL server et le code qu'ils emploient.
 
La seule manière, je le répète, c'est d'externaliser l'outil de décodage.    

A quoi sert l'outil sur le serveur s'il n'a pas la clef qui est sur le client?
A quoi sert le client avec sa clef s'il n'a pas l'outil sur le serveur?
 
Quand la clef ne rencontre jamais la serrure, bah il ne se passe pas grand chose (et la version sans fil d'une serrure, genre "plip", ça envoie des ondes à la serrure qui lui répond etc si on reste dans les analogies physiques et tangibles)

La clé client aisément récupérable... oui et non , le SSL ça fonctionne plutôt bien et c'est costaud tout de même.
Après le système parfait n'existe pas, le but est de rendre la base non consultable par quelqu'un qui l'ouvre (admin ou qqun qui a fait un extract/copie). Après c'est sur que tout est possible mais il faut une réelle volonté de percer la sécurité mise en place : on n'a plus à faire à la même population.
 
Comme vous aimez les analogies  
C'est comme quand tu achètes une voiture, tu prends l'abs et les airbags pour sécuriser tes trajets avec ta voiture, mais ça n'empêche en rien le fait que tu puisses tout de même avoir un accident mortel, tu diminues juste les risques (alors est-ce débile - pour reprendre Hermes- de vouloir diminuer ces risques, en sachant que tu ne peux les annuler? ). Si tu veux réellement ne pas avoir d'accident mortel avec ta voiture... ben t'en achètes pas (de voiture), mais bon ça sert tout de même.
Là c'est pareil, on cherche à réduire les risques tant que faire ce peut, tout en sachant qu'on ne peut les annuler, en cryptant la base (=airbag), en plaquant la clé ou autre sur un autre serveur dans du code (on splitte la clé par exemple: elle n'apparait nulle part en entier) etc... (=abs+esp+pneus neufs+ nouvelles lunettes+arrêt de la picole).  
Et tout ça, même si ce n'est pas parfait, ça me semble loin d'être débile.

 
Et ta clé elle est où ? Tu la stocke où ?

 
up, je suis curieux d'entendre la réponse...

 
Dans du code, c'est ultra-facile à retrouver donc non déjà... Et puis quel code ? Et puis comment tu l'appelles ta clé ? Forcément avec un script PHP ou autre langage serveur, et là, ben ouai, elle doit apparaitre dans ton code, ou sinon, la manière d'appeler ta clé apparait et ce, d'où que provienne ta clé.

En fait, ce que tu ne comprends visiblement pas, c'est qu'il est complêtement différent de crypter son mot de passe pour un forum que de crypter une base entière. Dans le cas du mot de passe, c'est le CLIENT qui transmet son mot de passe codé.
 
C'est pour cela que la seule manière de lire une BDD cryptée sans que l'admin puisse la lire en ayant la main sur le serveur est d'externaliser le décryptage chez le client. ça fait au moins 10 fois que je l'écris...      
 
Donc, encore une fois, NON ce n'est pas possible.  

J'aime quand on me prend pour un con...
Au contraire de toi, j'ai très bien compris ce que tu disais.
 
Tu peux planquer une clé dans du code de façon assez efficace, en faisant par exemple une fonction qui appelle une autre fonction pour créer ta clé à la volée, si tu noies ça dans du code, ce n'est pas si évident à retrouver : je l'ai dit plusieurs également et je le répète, le but n'est pas de trouver la solution parfaite mais limiter les risques autant que faire ce peut avec les moyens disponibles. Quelque chose de pragmatique et non de la branlette intellectuelle.

 
Je vois que tu ne comprends toujours pas ce qu'on te dit :
 
Quand tu fais ta requête vers ta Base de données, tu dois FOURNIR LE CODE. Que ce soit en PHP, en ASP ou n'importe quel autre langage, tu appelles donc ta BDD. Cette page d'appel est TOUJOURS DISPONIBLE pour l'admin du serveur et il n'a aucunement besoin de connaitre ta clé, il lui suffit de récupérer la ligne d'appel à la BDD.
 
Peut importe que dans ton code tu aies par exemple :  
 
sql_blabla(user, exec(blablabla...) (ou exec(blablabla) serait le résultat d'un appel à une fonction secrête, protégée).
 
Tu saisis ? T'es un peu borné comme mec quand même...