Protection de base

Question sodomie de lépidoptère :

En rapport avec mon boulot.

Je dois crypter (de façon réversible, bye bye md5) une foule d’informations dans la base de données mysql. (environnement linux/apache/php/mysql)

J’ai donc codé un cryptage bien vicelard, mais assez rapide pour crypter les données à la volée lors de l’enregistrement.
Seulement la sécurité n’est pas estimée assez élevée d’après mes interlocuteurs.

L’interlocuteur dit : si on rentre dans le serveur, le cryptage est mort, puisque les affreux auront accès au code source. (dans la version du code que je lui ai envoyé pour démo, la clé de chiffrement était dans l’include, mais pour demo uniquement, pour que ça marche, en somme)

C’est pour l’argumentation technique. Le monsieur voudrait au mieux (encore que…) qu’on utilise mcrypt, librairie de php. Faut recompiler (sur les serveurs de dev et test), j’aime pas, mais je peux m’y faire. Seulement mcrypt ça fonctionne, comme mon truc, avec une clé.

Or là, ce que je voudrais, c’est démonter l’argumentaire du gentillhomme. En somme, que la procédure de cryptage soit une fonction de php (réversible) ou du code tapé avec mes mains, s’il y a intrusion et main basse sur la clé, c’est ouvert de la même manière, non ? (Cela suppose que la clé soit dans un include dans un répertoire apache:apache avec du 700 pour être tranquille)

Voilà, si quelqu’un a un argument, une solution ou un produit qui fasse la même chose, merci.

Constructif.

Merci.

Déjà il faudrait en savoir plus. Le cryptage de la base, ok mais bon ca dépend pourquoi. Parce que plusieurs solutions sont enviseageables la de prime abord, mais ca dépend ce que tu veux faire.

Parce que a la limite tu peux donner la clef de cryptage au client qui la transmet avec chaque page, mais ca necessite que les pages soient en ssl. Mais au moins t’es assuré que la clef n’est pas sur le serveur. Malheureusement, ya 2 problèmes: si le client se plante de clef tu peux pas vérifier (pas de comparaison possible vu que tu dois pas avoir de copie de clef sur le serveur)

Une autre solution envisageable est une clef dynamique (par exemple basée, sur le Unix timestamp de lorsque la requete a été effectu&#233. Mais ca n’empeche pas, si on a acces au sources, de pouvoir décrypter les messages dans la BDD, étant donné qu’on connait l’algo de cryptage.

Euh, merci de ta réponse, mais la clé envoyée par le client c’est pas possible.

La clé dynamique non plus.

En gros ce que dans ma boite on me demande, c’est : Charabia
indéchiffrable dans la base, et pas le mode d’emploi pour le décrypter
sur le site.

Le souci c’est qu’il s’agit de données sensibles.

ET que la paranoia est terrible.

Je dois crypter l’intégralité des champs d’une table.

Cryptage à clé donc.

Où mettre la clé ?

Sur le serveur ? Mais où sur le serveur pour que ça soit tranquillement “sécurisé” et “protégé” come on me le demande ?

Je pensait à un rep accessible uniquement par l’user apache. On
peut peut être négocier un endroit plus haut sur l’arborescence de
fichiers (type /home/key/cle)

Et encore, je ne leur ai pas dit que le login et le password de l’user de service mysql était lui aussi sur le serveur.

En gros le chef sécu chez moi se borde et dit : s’il y a intrusion, il aura accès aux données de la base.

Et moi à part répondre “oui, s’il est dedans, il est pas dehors” ou une baliverne du genre, je ne sais pas trop quoi faire.

La clé côté client ça ferait un mot de passe en plus à gérer… Et
c’est loin d’être certain que la confidentialité/discrétion quant à cette clé soit respectée.
Ce message a été édité par good_boy le 23/10/2003

Mouhai ton mec de la secu il est pas tres logique.
Si se sont des données si sensible, pkoi les mettres sur un server ?
Vous ne pouvez pas mettre ca sur un server alone ?
Car il faut je pense revoir le processus. Mais si les données doivent etre vue à partir de n’importe ou, la c’est sur. Mais bon, il est vrai ce que tu dis : si il est sur le server, c’est qu’il a reussi à passer toutes les securités, donc tu pourras faire ce que tu veux, si il veut les données il les aura.

Bon pour mysql je crois (pas sur) que t’as une option pour que toutes les requetes ne se fassent que de la machine meme. Ca evite déjà qu’un user extérieur tape dans la base.

ensuite, pour ta clef, je te conseille d’utiliser des leurres. Cad tu utilise bien la clef dans ton programme mais dans un endroit bien planqué en fait t’en utilise une seconde, et le fait d’utiliser la premiere clef préviens quelqu’un…

enfin j’ai pas d’autres idées la sur le coup…

[quote]Mouhai ton mec de la secu il est pas tres logique.
Si se sont des données si sensible, pkoi les mettres sur un server ?
Vous ne pouvez pas mettre ca sur un server alone ?
Car
il faut je pense revoir le processus. Mais si les données doivent etre
vue à partir de n’importe ou, la c’est sur. Mais bon, il est vrai ce
que tu dis : si il est sur le server, c’est qu’il a reussi à passer
toutes les securités, donc tu pourras faire ce que tu veux, si il veut
les données il les aura.[/quote]

Là où il est pas logique c’est “ton cryptage maison est pas bien, essaie mcrypt” alors que le souci serait rapport à la clé.

On va dire que sensible… Euuuh, tu vois, le nom et le prénom de
l’utilisateur ça doit être crypté. Enfin, inexploitable si le monsieur
vilain est sur le serveur.
Et si la base est sur un serveur à part, oui, c’est très bien,
mais je ne vois pas comment avec login et password un mec qui a accès
total au serveur amont ne puisse pas réaliser un dump ou une lecture
(poster un .php qui rapatrie…).

"ensuite, pour ta clef, je te conseille d’utiliser des leurres. Cad
tu utilise bien la clef dans ton programme mais dans un endroit bien
planqué en fait t’en utilise une seconde, et le fait d’utiliser la
premiere clef préviens quelqu’un…"
Pas bête. Déjà sur le projet j’avais un roi du java qui a collé
des objets dans tous les sens, je m’y retrouve à grand peine dans les
héritages (chelous en passant) donc je crois qu’un affreux il
pleurerait s’il arrivait à afficher le code source.
Bah là je demande comment ça vous le feriez. Je n’ai pas appris
de méthode à l’école, vu que dans mon école on apprenait pas à se
servir de programmation.

Il y a encore la solution de mettre la clé de cryptage dans la base elle même.

Enfin, c’est le stockage de la clé sur le serveur qui me chagrine…
Ce message a été édité par good_boy le 23/10/2003

C’est ca les données sensible… Bizarre.
Bon en gros le mec veut un truc Corporate avec un logiciel que tout les pirates connaissent ( les vrais dit) bref les solutions maisons sont tjs les meilleurs car les pirates ne les connaissent pas.
C’est comme prendre un coupe circuit de serie ou maison,
serie => on sait qu’elle fil il faut couper.
maison => bah ?? c’est quoi tout ces fils de meme couleur. ( tester et approuver) on a esseyer de voler ma voiture, bah il a tout couper , bah elle a pas demarrer titine

Mais bon si il est borné c’est vraiment dommage.

Une astuce pour les leurres : faire appel à des fonctions dans d’autre fichier qui ne servent à rien, et creer des chemins en dure et relatif.

Ce message a été édité par silka le 23/10/2003

Hahahahahaha. T’as fait ton cryptage maison toi meme?!?!

C’est mort. Ca vaut rien, c’est 100% non securise. C’est crackable en 30 secondes par quelqu’un qui s’y connait.

Le monsieur a raison, ton cryptage c’est pas mieux qu’un XOR. Personne que je connais, personne ne s’amuserait ne serais ce qu’a IMPLEMENTER un algo de cryptage connu et reconnu comme de tres bonne qualite. D’autant plus que c’est ecrit dans un langage interprete… Ne parlons meme pas (de pres ou de de loin) d’en inventer un, c’est meme pas la peine si t’as pas un doctorat en cryptographie et encore, de tout les gens qui en ont un, seul un ou deux algo tout les 5 ans sont reconnus comme valables et resistent a l’inspection des autre collegues.

Non sans deconner. Vire moi cette crypto maison ignoble et mets un truc serieux.

Je rejoins l’avis de GloP, un code interprété est toujours “crackable”.
Tôt ou tard tu écris en plus ou moins clair la méthode de décryptage.

Par ailleurs, que foutent des données importantes sur une base mysql ?

Ok je suis un peu mauvaise langue sur le coup, mais pour mon premier point je suis sérieux. Peut être en faisant appel à un module compilé à la activeX ou CGI/BIN ?

Mais non mais non. Y a des librairie crypto tres bien pour PHP. Pas la peine de reinventer la poudre. C’est le pire qui puisse etre fait. La DB et le frontend doivent etre separes. La clef sur le front end doit etre ultra verouille au niveau des droits sur le filesystem pour que seul le process du webserveur puisse y acceder. Enfin on peut jamais faire beaucoup plus apres avec un systeme en 2tier, voire 1tier C’est pour ca qu’on a invente les systemes n-tier ou au pire 3-tier, parceque c’est pratique, scalable et plus securise…

Hmm, a mon avis y a pas trop d’autre solution que bien securiser la machine.

Si tu stock la cle sur le serveur, le pirate pourra la recuperer, et se servir de ton code pour l’utiliser.

Si la clé est envoyé a chaque fois par le client, celui qui passe root sur la machine peux toucher au serveur web pour qu’il logue tout ce qui sort.

La solution ca serait sinon de decrypter le truc du coté du client, la clé reste chez le client.

Non mais la securite absolue n’existe pas. La clef chez le client, ca peut etre une idee mais seulement pour identifier celui ci, comme un certificat en fait (il a la moite de clef “publique&#8221 la clef privee doit toujours etre sur le serveur. Comme sourceforge gere ses acces CVS par exemple. Dans tout les cas la securite c’est un systeme a plusieurs niveau. C’est pas un mur impenetrable, ca existe pas. C’est une serie bien longue de murs tres durs a franchirs. Firewall, services exposes faibles, services bien mis a jour, droits du services limites, clef de crypto bien protegee au niveau filesystem, base de donnee sur une autre machine, fichiers php non editables par le process du webserveur (meme si il a la clef et qu’il peut executer ton code, comme un utilisateur lambda il pourra faire que dommages limites si le seul point d’entree c’est ton code et qu’il peut pas le modifier). Apres sur la base de donnee on recommence, et si on crypte c’est que si il arrive a choper un dump de la base il puisse pas l’exploiter chez lui mais doive AUSSI pirater ton frontend, voire pour te proteger des attaques interne des employes qui se connectent et lisent la base direct en clair. C’est loin d’etre simple et honnetement ca s’invente pas ou ca s’approxime pas, c’est un metier et meme pour des pros c’est loin d’etre evident de ne rien laisser passer…

Question con sans doute… Mais les données, elle vont transiter sous forme cryptée ou non ? Parce que crypter uniquement à l’arrivée  avec le php qui va cracher gentiment le contenu “sensible” en html, c’est pas top non plus. Ou alors j’ai pas bien compris…

J’ai l’impression qu’il faut blinder l’accès à la base et crypter ce qui en sort plutôt que de s’escrimer à crypter le contenu de la base (Sachant que si un guss arrive jusqu’à la base, question crédibilité sécurité ça fait un peu lège)

Les donnees sensibles elle sont cryptees dans la base, elles sortent de la base et elles se font decrypter par un autre machine. Dans un systeme 2 tier t’as pas le choix c’est le front end, donc ton serveur web. Dans un systeme 3 tier les donnees vraiment sensibles tu les envoies meme pas au front end et si elles se font decrypter c’est par la couche de buisness logic en backend,  juste au dessus de la DB. Faut penser que les attaques viennent pas que de l’exterieur non plus et que qqn qui chope le compte pour avoir un droit en lecture sur la DB si il peut juste se balader en 30 secondes et noter les numeros de carte bleu par exemple c’est MAL. Il faut faire chier pour rendre la vie difficile a n’importe qui.

[quote]Non
mais la securite absolue n’existe pas. La clef chez le client, ca peut
etre une idee mais seulement pour identifier celui ci, comme un
certificat en fait (il a la moite de clef “publique”
la clef privee doit toujours etre sur le serveur. Comme sourceforge
gere ses acces CVS par exemple.

Sur sourceforge (comme a beaucoup d’endroits) l’acces au cvs se fait
par ssh. Et tu deposes ta clé publique ssh sur le serveur pour pouvoir
t’y connecter en utilisant ta clé privée. Après tout se fait à travers la connection ssh.

[quote]
Dans tout les cas la securite c’est un
systeme a plusieurs niveau. C’est pas un mur impenetrable, ca existe
pas. C’est une serie bien longue de murs tres durs a franchirs.
Firewall, services exposes faibles, services bien mis a jour, droits du
services limites, clef de crypto bien protegee au niveau filesystem,
base de donnee sur une autre machine, fichiers php non editables par le
process du webserveur (meme si il a la clef et qu’il peut executer ton
code, comme un utilisateur lambda il pourra faire que dommages limites
si le seul point d’entree c’est ton code et qu’il peut pas le
modifier).[/quote]
Enfin ca c’est le truc qui est de base partout depuis pas mal de temps
(sous Unix/Linux en tout cas), je connais personne qui met les fichiers
web appartenant a www, ou qui fait tourner apache en root.

On peux aussi rajouter la separation des privileges (un processus qui a
besoin d’etre root pour faire certains trucs, qui se separe en 2
processus, l’un en root, le plus petit/simple possible, chargé de faire
uniquement les actions qui nécessitent ces droits, l’autre chargé du
reste, avec peu de droits), ou bien le chroot (un processus que l’on
enferme dans un repertoire, et qui ne peux acceder a aucun fichier a
l’exterieur du chroot), etc …

[quote]
Apres sur la base de donnee on recommence, et si on crypte
c’est que si il arrive a choper un dump de la base il puisse pas
l’exploiter chez lui mais doive AUSSI pirater ton frontend, voire
pour te proteger des attaques interne des employes qui se connectent et
lisent la base direct en clair. C’est loin d’etre simple et honnetement
ca s’invente pas ou ca s’approxime pas, c’est un metier et meme pour
des pros c’est loin d’etre evident de ne rien laisser passer…[/quote]
Je vois pas trop l’interet (pour la securité ) de mettre la base de donnée sur une machine
differente du frontend. Dans les 2 cas il faut pirater le frontend (celui qui sait decrypter et qui a accès au données cryptés).
Ce message a été édité par BokLM le 23/10/2003

[quote]Je vois pas trop l’interet (pour la securité de mettre la base de donnée sur une machine differente du frontend. Dans les 2 cas il faut pirater le frontend.[/quote]C’est dommage tu rates un element important… Si tu ne peux acceder a la base de donnee que par le stored proc qui te sont accessibles depuis le front end (encore faut il que la base supporte les stored proc) tu peux faire ENORMEMENT moins de degats que si tu as un acces illimite aux fichier de la base de donnee. Le droits du front end sur la base et les fonctionalites exposees par les stored proc sont tres limites et ne contiennent en general aucun droit d’effacement de donnees sensibles par exemple. Si ton systeme est bien architecture tu as meme plusieurs niveau de hierarchie dans la gestion de tes droits sur le front end qui correspondent a autant de niveau d’acces au stored proc sur ta base de donnees. Les stored proc etant le moyen de le faire dans un systeme 2 tier. La couche de buisness logic dans un systeme n-tier vient s’interposer. Si tu as qqn qui rentre sur une de tes machines tu as deja perdu une grosse bataille et tu vas en chier mais maintenant tu es en mode “damage control“ c’est pas parceque tu t’es deja fait niquer qu’il faut que ca soit facile non plus. Il faut pas tout faire pour limiter les degats.

J’ai une certaine experience dans ce domaine (architecture des solutions web), ayant passe les 4 dernieres annees a etudier dans le detail tout ces problemes d’architecture qui mettent en jeu securite, scalabilite et disponibilite sous linux/solaris et sous windows. Et honnetement il y a aucune difference fondamentale sous aucun de ces systemes. Je vois pas l’interet de rappeller que certaines choses sont “de base“ sous l’OS X, Y ou Z, a part a faire du proselitisme pour pas cher. Deja, c’est completement normal que ca soit de base, et aujourd’hui tout les OS font les memes choses, ensuite rien n’empeche la connerie de tel ou tel utilisateur de le changer, avec un gros chown par la, ou un ‘ca tourne mieux en root’ par ci. Ca ne fait aucun mal de rappeller tout ce qui est important dans une chaine de securite. Le “truc de base“ c’est loin d’etre suffisant pour faire une systeme fiable ou meme securise, et c’est tout une architecture qui doit etre pensee en fonction de tes besoins de securite.

Ce message a été édité par GloP le 23/10/2003

[quote][quote]Je
vois pas trop l’interet (pour la securité de mettre la base de donnée
sur une machine differente du frontend. Dans les 2 cas il faut pirater
le frontend.[/quote]C’est triste tu rates un element
important… Si tu ne peux acceder a la base de donnee que par le
stored proc qui te sont accessibles depuis le front end (encore faut il
que la base supporte les stored proc) tu peux faire ENORMEMENT moins de
degats que si tu as un acces illimite aux fichier de la base de donnee.

Enfin, si tu controle le front-end, tu as accès aux données, puisque
c’est le front-end qui devait les traiter (et il doit donc avoir un
accès). C’est vrai qu’il n’a pas forcement les droits de modification, mais la on parlait plutot de proteger des données secrètes.

[quote]Mais
non mais non. Y a des librairie crypto tres bien pour PHP. Pas la peine
de reinventer la poudre. C’est le pire qui puisse etre fait. La DB et
le frontend doivent etre separes. La clef sur le front end doit etre
ultra verouille au niveau des droits sur le filesystem pour que seul le
process du webserveur puisse y acceder. Enfin on peut jamais faire
beaucoup plus apres avec un systeme en 2tier, voire 1tier C’est pour ca qu’on a invente les systemes n-tier ou au pire 3-tier, parceque c’est pratique, scalable et plus securise…[/quote]

Je suis plus ou moins d’accord.

Donc on reprend.

La base séparée, c’est hors de propos. Ce n’est pas le cas. La base
tourne sur le serveur web, c’est comem ça, je ne peux rien y changer.
Ensuite il n’est pas de mon ressort de dire “c’est sensible” ou pas. On
me dit “si quelqu’un accède au serveur, il faut qu’il ne puisse rien
voir”. Bon, là je commence à grimacer, bientôt il va me parler de
sécurité totale.

Pour le verouillage de la cle via les droits du système de fichiers, je suis bien d’accord, c’est ce que j’imaginais.

Ensuite, mon algo “maison” est effectivement pas beaucoup mieux
qu’un xor. Enfin, trois ou quatre xors. Mais j’imagine que mcrypt (une
lib php de cryptage) c’est pas énormément mieux (comprendre : en
disposant de la clé et du code qui appelle la fonction mcrypt). Enfin,
sans la clé, je ne sais pas s’il est possible de réXORer facilement et
simplement, relativisée par rapport à un cryptage mcrypt (BLOWFISH,
TWOFISH, DES, TripleDES, 3-WAY, SAFER, LOKI97, GOST, RC2, MARS,
RIJNDAEL, SERPENT, CAST, ARCFOUR and WAKE).

Ce que j’aimerais savoir, c’est s’il existe une différence
significative entre : j’ai la clé, le nom et la méthode de la lib de
cryptage et : j’ai la clé et l’algo de cryptage.

Et si mon chiffrage pour enfants sans prétention, à base de xor et
d’encode64, a une valeur si le monsieur n’a pas la clé. (Différence
entre faire une résolution par la force brute sur un blowfish ou sur
mon chiffrage maison).

Tout à fait d’accord avec Glop (en moins véhément tout de même) sur le fait de réinventer la poudre.

C’est juste que ça m’a pris 20 minutes, que c’est portable sans sueur. C’est ce qui m’a mené à le faire de cette façon. C’est aussi le fait que les lib de cryptage que j’ai trouvé en 10 minutes de googling me sont apparues moins faciles à déployer, encore une fois c’est subjectif.

Merci de vos réponses.

Constructif
Ce message a été édité par good_boy le 24/10/2003

Si tu tiens à utiliser ta solution, tu peux toujours intégrer tes propres fonctions sous MySQL en créant un .so :

http://www.mysql.com/doc/en/CREATE_FUNCTION.html

Ca peut éviter que quelqu’un tombe sur ta clé, mais d’un autre côté, faut ajouter ta self made function sur tous les champs à masquer lors des insert/replace/update/select.

Y’a peut-être d’autres inconvénients, mais je ne peux pas t’en dire plus.