Jerome Moliere wrote:
> At 12:08 PM 5/15/2002 +0200, you wrote:
>
>> Salut,
>> je pense que m�me avec un offuscateur ton client (avec plus de mal)
>> arrivera encore � acc�der � l'application.
>> Les codes offusqu�s peuvent �tre d�compiler surtout si c'est juste
>> une classe qui est en cause et au pire il peut remplacer la classe
>> par une autre.
>>
>> Je pense que tu as plus un probl�me de conception de ta securit� pour
>> le d�marrage. Si j'ai bien compris tu rentres un mot de passe au
>> d�marrage qui est valid� par ta base et l'appli se lance.
>> Ton client a fait sauter cette validation et l'appli c'est lanc�. Ce
>> qui m'�tonne c'est que la connection � la base se r�alise sans
>> authentification ou si elle a lieu cette authentification est en dur
>> dans le code.
>> Le mieux est de prot�ger toutes les donn�es de connection � la base
>> dans un fichier encrypt� prot�g� par un mot de passe qui est founit
>> au d�marrage. Ainsi si le mot de passe n'est pas fourni aucune
>> connexion � la base ne peut �tre r�alis�e. Pour cela regarde JCE et
>> JSSE. Il te permette de cr�er des espaces de stokage de cl� et de
>> certificat qui seront utilis�s pour encrypter et d�crypter. Si tu
>> utilises des certificats regarde OpenSSL pour g�n�rer tes certificats
>> sans passer par un fournisseur qui est payant.
>> La d�marche a suivre en g�n�ral est de r�aliser un certificat/cl�e
>> priv�e qui fait autorit�, de g�n�rer un certificat/cl� priv� sign�
>> par l'authori�.
>> De g�n�rer un cl� temporaire utilisant un algo s�re (utilisant des
>> cl�s tr�s tr�s longue) et rapide comme Blowfish par exemple.
>> D'encrypter ton ficher de donn�es secr�te avec cette cl�e,
>> d'encrypter la cl� avec la cl� public du dernier certificat et
>> d'ecrire cette cl�e encrypt�e dans le fichier contenant les donn�es
>> encrypt�e.
>> Pour la lecture tu demande le mot de passe de la cl� priv�e, tu
>> utilise la cl� priv� pour d�cript� la cl� Blowfish (par exemple), tu
>> utilise la cl� blowfish pour d�cripter les donn�es que tu utilises
>> pour r�aliser la connexion � la base de donn�es. Ainsi sans mot de
>> passe de la cl� priv� tu ne peux pas te connecter � la base.
>> De temps en temps tu peux reg�n�rer la cl� blowfish et r�encripter
>> tes donn�es.
>>
>> Tu n'est pas oblig� de passer par des certificats et juste utilis� un
>> algo d'encryptage comme Blowfish mais la proc�dure normal pour
>> prot�ger des donn�es par mot de passe est de les utiliser.
>>
>> De plus de temps en temps il est bon de changer les mots de passe de
>> la connexion � la base de donn�es
>
> t'as raison sur le principe philippe, mais le middleware (protocole)
> importe peu puisque le probleme fondamental vient du fait que tu peux
> desactiver purement et simplement la couche d'authentification...
>
>
> Jerome
>
En fait en utilisant ma m�thode il n'y plus de couche
d'authentification puisque la connexion physique avec la base n'est
possible que si les donn�es de connexion ont bien �t� d�crypt�es. Par
contre je pensais que l'application �tait du type server / base de
donn�es et non client / DB ou client / server.
Dans les deux derniers cas pour s�curis� le client il y a deux
possibilit�s (pour s�curis� le serveur on peut utiliser le moyen
pr�c�dent) :
- utiliser un PKI (system de gestion de certificat / cl� priv�e)
pour obtenir un certificat / cl� priv�e par login utilisateur et
utiliser une connexion (physique) avec la base ou le serveur du type SSL
(avec validation des certificat). Dans ce cas si le mot de passe n'est
pas rentr� (quelque soit les changement sur les classes du client) la
connexion ne pourra se faire (le serveur ou la DB rejette les
connexion). Cette solution a l'avantage d'�tre la plus normaliser et
sans d�veloppement sp�cifique mais c'est aussi la plus lourde � mettre
en place (le PKI)
- utiliser un serveur avant la DB et mettre en place un protocol qui
valide � chaque requ�te que le client c'est bien authentifier. L'id�e
est d'utiliser un package d'authentification par challenge comme (JAAS).
Si l'authentification a r�ussit, le serveur g�n�re un id unique associ�
au login qu'il renvoie au client. Dans toute les requ�te le client
envoie le login/id qui est valid� par le serveur. Ainsi m�me si
authentification est by-pass�e par un moyen X ou Y, aucune requ�te ne
pourra �tre r�aliser sur le serveur. Pour r�aliser cela, c'est
relativement facile avec CORBA et les intercepteur.
Philippe Delrieu
