Je disais juste que si c'était chiffré on n'obtenait pas les accès dans la seconde. :roll:

Au passage :
[quote]Un collègue indélicat? Dans ce cas tu as des soucis à te faire sur ta politique de sécurité.[/quote]
Tu crois sérieusement vivre dans un monde de bisounours ? Pas que je sois parano mais bon... On choisi pas ses collègues et on tombe rarement en parfaite harmonie avec toutes les personnes de notre boite. :)

Qui "on"? Quelque malware déjà résident sur ta machine? Auquel cas chiffré ou pas... Un collègue indélicat? Dans ce cas tu as des soucis à te faire sur ta politique de sécurité. Ton laptop volé. Oui ok. Là tu dois être plus rapide que les voleurs pour verrouiller tes sites ftp.

Par contre, combien d'entre-nous n'ont-ils jamais fait de FTP en wireless non chiffré (hotel etc...)? Ou sur un lan non sécurisé? Vous voulez vous faire peur? Alors, en terminal faites:
[code]# tcpdump -vvA host votre.host.ftp and port 21[/code]

Dans un autre terminal, lancez une connexion ftp normale avec votre client préféré (avec-mdp-chiffrés-et-tout-et-tout) et voyez ce qui bave sur le réseau:

20:41:06.576357 IP (tos 0x10, ttl 64, id 163, offset 0, flags [DF], proto TCP (6), length 51)
ibm.lan.38465 > *****************: Flags [P.], cksum 0x6d7d (incorrect -> 0x8b2c), seq 1:12, ack 58, win 229, length 11
E..3..@[email protected] .A...>h.>8
.P...m}..USER[color=#FF0000] toto[/color]
20:41:06.603880 IP (tos 0x0, ttl 50, id 45561, offset 0, flags [DF], proto TCP (6), length 72)
***************** > ibm.lan.38465: Flags [P.], cksum 0x7ce9 (correct), seq 58:90, ack 12, win 92, length 32
[email protected].)_T.X .......A>8
..>h.P..\|...331 Password required for toto
20:42:10.317540 IP (tos 0x10, ttl 64, id 165, offset 0, flags [DF], proto TCP (6), length 71)
ibm.lan.38465 > *****************: Flags [P.], cksum 0x6d91 (incorrect -> 0x1746), seq 12:43, ack 90, win 229, length 31
E..G..@[email protected] .A...>h.>8..P...m...PASS[color=#FF0000] mon_mot_de_passe_SECRET![/color]

Alors, chiffrer ses mots de passe sur un client, se sentir protégé et puis faire du ftp normal, est-ce vraiment raisonnable? :wink:

La sécurité ne vaut que par son maillon le plus faible. Pour la petite histoire, les fichiers de config de Filezilla étaient chiffrés au départ. La clé a rapidement été craquée, comme pour la plupart des autres clients d'ailleurs. Du coup, ils ont décidé de ne plus les chiffrer pour forcer les utilisateurs a faire face à la réalité de la sécurité. C'est un choix qui fait peur de prime abord mais qui a du sens. Dans tous les cas je n'irais pas jusqu'à dire qu'il s'agit là d'une grave faille de sécurité. C'est tout au plus un choix raisonné et assumé par les concepteurs. Comme celui que l'on fait quand on travaille sous root: [i]Great power comes with great responsability[/i]...

La différence est grande selon moi...
Sans cryptage on a les mots de passe dans la seconde.
Avec cryptage on est obligé d'attendre une connexion.
Personnellement j'ai un ou deux ftp auxquels je ne me suis pas connecté depuis 1ans et qui contiennent des données que je n'aimerai pas voir partout...

[quote="xTG"][quote="3akycka"]Est-ce que je peux vendre ça comme étant aussi sur que de passer par un client ftp comme filezilla ?[/quote]
A mourir de rire ! :lol:
Tu ne savais surement pas en postant cela que Filezilla est un client FTP stockant les informations de connexion en clair sur le disque dur (username, adresse et bien sûr mot de passe).[/quote]

Ce sujet a déjà fait couler beaucoup d'encre. Il ne s'agit pas d'une faille mais bien une volonté délibérée de ses concepteurs. Pour eux, le chiffrement du fichier de mdp est un leurre dangereux. On a la fausse impression d'un certain niveau de sécurité et on ne fait plus attention au reste. Comme utiliser le proto FTP pur par exemple, qui envoie en clair les données de connexion! Le chiffrement du fichier est inutile quand le client est contaminé par un malware. Il n'a d'utilité que si la machine cliente est volée. Ou si quelqu'un a accès à votre fichier de config Filezilla en lecture. Mais dans ce dernier cas le problème est l'utilisateur qui n'a pas protégé sa session avec un mdp suffisamment solide. Ou a laissé une session ouverte en son absence. Et puis, les jolis scripts PHP qui se trouvent sur votre machine de dev, ils ne contiennent aucun login en clair? Hmm? Aucun? :wink:

[quote]Let's assume all passwords are encrypted. Malware just waits till you connect to the server and then captures the password from memory. Protection gained by the encryption: None.
...
I will implement encrypted passwords if you can answer these simple questions:
Instead of reading the plaintext passwords, what prevents the malware from reading both the encrypted passwords as well as the user-supplied password as soon as the user enters it? What is the difference in the outcome?
http://forum.filezilla-project.org/viewtopic.php?f=1&t=11003[/quote]

Pour le reste Filezilla est un excellent client FTP. Mais c'est à nous à l'utiliser avec discernement.

Si l'hébergeur fait bien son travail, normalement il n'y a que toi qui peut accéder à ton espace web.
Sinon en variante il te reste la possibilité de mettre tes fichiers dans un dossier sur la racine du site et qui sera protéger par un .htaccess avec la mention "deny from all"

Bonjour,

J'avais un hébergement mutualisé ou j'avais du mal à lire les fichiers de la racine de mon site. En faisant des essais pour trouver une solution, je me suis rendu compte que je pouvais lire les fichiers de configuration du serveur depuis la racine (/etc...).

Dans une boite ou j'ai bossé, il y avait tout un tas de fichiers auxquels je n'avais pas accès. Par contre, j'avais accès au user admin ainsi qu'une grande partie de mes collègues...

ok, je vais voir ça
merci encore

Là on ne peut te répondre. Faut demander à l'hébergeur. ;)

Merci à tous les deux pour ces précisions.
En effet je ne connaissait pas cet faille de Filezilla.
A propos du "sniffage", étant donné le type de fichier qui seront envoyé, il y a très peu de raison que ça intéresse des admin de la même boite de les intercepter et au pire si ça arrive ça sera plutôt le problème de la boite qui envoi que le mien. Donc ça réduit déjà pas mal le problème, et avec https ça devrait le faire.

Une autre question, mon client dispose d'un serveur mutualisé (ça je ne pourrais pas le changer),
le dossier dans lequel seront stockés les fichiers sera hors web, donc seul un script php accessible après être logué y aura accès. Mais comme c'est un serveur mutualisé est-ce qu'il y a un risque que d'autres abonnés à ce même serveur puisse accéder au dossier hors web ?

[quote="3akycka"][quote]A mourir de rire ! :lol:
Tu ne savais surement pas en postant cela que Filezilla est un client FTP stockant les informations de connexion en clair sur le disque dur (username, adresse et bien sûr mot de passe).[/quote]
Bon c'est déjà bien si je t'ai fait rire :D
Mais je ne suis pas sur d'avoir bien compris ta réponse, est-ce que ça veut dire que d'utiliser un client FTP comme filezilla n'est pas plus sûr que transmettre un fichier via https + un formulaire dans un page html ?
Si Filezilla stocke les info sur le disque dur, c'est risqué si quelqu'un accède à l'ordinateur, mais ça ne fait pas forcement que le transfert des fichiers ne sera pas sûr ?[/quote]
En fait ce qui me faisait rire c'est que tu cites pour exemple de sécurité le seul client FTP possédant une énorme faille de sécurité, à savoir ne pas crypter les informations privées. :)
Il existe de nombreux "virus" (remplacez par le bon mot, je suis pas adepte de cette terminologie) qui récupèrent ce fichier non crypté. Et donc après ce n'est pas le fichier en cours de transfert qui est récupérable, mais tout ce qui se trouve sur les FTPs renseignés dans ce fichier.

Non c'est pas à la portée de tout le monde.
Mais par exemple l'administrateur réseau d'une entreprise d'où un client envoie ses fichiers pourrait le faire assez facilement.

Au delà (si le pirate n'est pas à proximité de la connexion) c'est beaucoup plus dur mais pas impossible.

Avec la méthode standard c'est donc assez sûr pour peu que le pirate ne se situe pas dans l'entreprise d'où est émis le fichier, ou que celui qui envoie les fichiers ne se connecte pas depuis un lieu public.

Mais si tu veux le maximum de garantie fais comme dit [b]xTG [/b] et propose à tes clients le https. Si leur fichiers sont vraiment très confidentiels le petit surcoût ne leur fera pas peur.

[quote]A mourir de rire ! :lol:
Tu ne savais surement pas en postant cela que Filezilla est un client FTP stockant les informations de connexion en clair sur le disque dur (username, adresse et bien sûr mot de passe).[/quote]
Bon c'est déjà bien si je t'ai fait rire :D
Mais je ne suis pas sur d'avoir bien compris ta réponse, est-ce que ça veut dire que d'utiliser un client FTP comme filezilla n'est pas plus sûr que transmettre un fichier via https + un formulaire dans un page html ?
Si Filezilla stocke les info sur le disque dur, c'est risqué si quelqu'un accède à l'ordinateur, mais ça ne fait pas forcement que le transfert des fichiers ne sera pas sûr ?

Je voudrais être certain que ce n'est pas une bêtise de transmettre des fichiers (qui ne devront pas être affichés sur le site) via un site et pas avec un client FTP.

[quote]Sniffer des paquets ? Oh allons, me dis pas que tu n'as jamais regardé un seul film impliquant la sécurité informatique. :wink:
Avant même la création des ordinateurs on interceptait bien les appels téléphoniques.[/quote]
Oui j’imaginais bien que ça devait se faire, mais ma question était plutôt de savoir si c'était à la portée de quasi tout le monde ou si c'était quand même compliqué et réalisé par des "hacker" confirmés, ce qui réduirait les chances que ça tombe sur le site de mon client.
Et du coup si la plupart des sites étaient quasi en permanence "snifés" ou si c'était plutôt rare ?

[quote="3akycka"]Est-ce que je peux vendre ça comme étant aussi sur que de passer par un client ftp comme filezilla ?[/quote]
A mourir de rire ! :lol:
Tu ne savais surement pas en postant cela que Filezilla est un client FTP stockant les informations de connexion en clair sur le disque dur (username, adresse et bien sûr mot de passe).

[quote="3akycka"][quote]N'importe qui en regardant les trames réseau verra en effet tout le transfert.[/quote]
Est-ce que c'est une pratique courante et simple à réaliser ?[/quote]
Sniffer des paquets ? Oh allons, me dis pas que tu n'as jamais regardé un seul film impliquant la sécurité informatique. :wink:
Avant même la création des ordinateurs on interceptait bien les appels téléphoniques.

ok,
donc https + un système classique de transfert de fichier via un formulaire et enregistrement du fichier dans un dossier hors web et personne ne pourra accéder au fichier ? Rien de plus compliqué ?

Est-ce que je peux vendre ça comme étant aussi sur que de passer par un client ftp comme filezilla ?

[quote]N'importe qui en regardant les trames réseau verra en effet tout le transfert.[/quote]
Est-ce que c'est une pratique courante et simple à réaliser ?

N'importe qui en regardant les trames réseau verra en effet tout le transfert.
Si tu veux le protéger il faudra passer par du https.