Discussion :

[AsH.fr]

Bonjour, bonjour.

Tentons de mettre les choses au clair:
J'ai un site en php5, avec quelques applet. Un de ces applets et un petit client FTP, permettant l'envoi de fichiers sur un serveur FTP.

Hors, ce serveur ftp ne sera pas le même sur tout les sites, ainsi que sa configuration. Rien ne pouvant (et ne devant) être coder en dur, je dois donc passer un certain nombre de paramètres à l'applet (client FTP) pour la connexion: IP, port, login, password du server FTP.
Pour l'IP, c'était facile INetAdress et c'est généré par l'applet.
Pour les autres, ben il n'y a pas de miracles: les paramètres doivent passés dans l'appel de l'applet... en clair dans le code source HTML.
Je me dis :"Bon, ben on va crypté tout ça!", je sais crypté en PHP, il y a des fonctions toutes faites, pas de soucis. Mais je décode comment de l'autre côté, c'est à dire dans mon applet? J'aimerais autant évité de coder une clé en dur, qui serait donc la même partout.

Je suis preneur d'idées, de pistes voir de solutions

AsH codeur-décodeur

[BugFactory]

Devez-vous cacher les paramètres de connexion également à l'utilisateur final de l'application?

Si ce n'est pas le cas, utilisez simplement HTTPS pour transmettre la page : les codes apparaîtront dans le code HTML, mais comme celui-ci aura été transmis de manière chiffrée, seul l'utilisateur final pourra le voir. Il n'y aura rien à changer pour l'appel de l'applet. (Mais j'avoue ne pas avoir essayé.)

Si vous devez les lui cacher, le problème est plus délicat. En effet, il faudra bien que l'applet connaisse les paramètres de connexion. Et si l'utilisateur est assez bon, il peut carrément extraire les codes à l'intérieur même de l'applet, puisque celle-ci s'exécute sur son poste. Si vous devez cacher les mots de passe à l'utilisateur final, l'utilisation d'une applet est une mauvaise idée, et il faudra gérer la connexion depuis le serveur.

[AsH.fr]

Le site est déjà en HTTPS et sécurisé au niveau des pages php.
Mon problème actuel est de ne pas facilité la tache à l'utilisateur final (éventuellement malveillant, ou trop curieux) en lui donnant en clair dans le code source de la page HTML, ou dur dans le code, les identifiants ou les clés permettant de les retrouvés. Dans l'absolu, les données sensibles devrait rester sur le serveur.

Mes seuls impératifs sont:
- permettre à l'utilisateur d'uploader des fichiers facilement, en quelques clics sans connassaces aucunes d'un client FTP (tel l'upload des fichiers joints d'un webmail, maintenant que j'y pense)
- et une sécurisation du serveur, surtout en évitant de donner les mots de passe en clair à l'utilisateur.

N'étant pas des plus aux faits des techniques de sécurités, surtout sur ce point, je suis preneur d'idées.
J'avais commencé par pensé Hashé tout ça, mais après un peu de lecture, je m'aperçois que ce n'est pas possible, ou alors je ne vois pas encore comment. Avec des clés, il me faudra les transmettre d'une façon, ou d'une autre...
Je pensais aussi que je pourrais peut-être utilisé mon jar signé, mais je ne vois pas comment.
J'ai pensé aussi généré un clé dans un fichier sur le serveur, fichier qui aurait comme duré de vie le temps de la connexion FTP.
J'ai pensé aussi passé par une connexion à ma BDD, mais ça ne fait que déplacé le problème, l'empirant même.

AsH triturateur de sécurité foireuse.

[BugFactory]

Eh bien, je peux imaginer plusieurs solutions, mais je ne suis pas moi-même expert en sécurité.

1. Laisser tomber FTP. Faire transmettre le fichier directement par le serveur WEB via HTTPS.
2. Si le serveur FTP est incontournable, c'est le serveur WEB qui va y lire le fichier puis le transmet via HTTPS.
3. Générer un compte à usage unique sur le serveur FTP, tout spécialement pour l'utilisateur qui doit télécharger, et ne lui laissant l'accès qu'aux fichiers auxquels il a droit. Dans ce cas, on peut utiliser l'applet : les codes transmis par HTTPS seront visibles par l'utilisateur final, mais ils ne lui permettront d'accéder qu'à des fichiers auxquels il a droit de toute façon.

La meilleure solution dépend de vos contraintes (bande passante, existant, etc...).