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...
la communauté d'entraide francophone dédiée au PHP
Upload de fichiers "privés", Curl ?
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:
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 toto
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 mon_mot_de_passe_SECRET!
Alors, chiffrer ses mots de passe sur un client, se sentir protégé et puis faire du ftp normal, est-ce vraiment raisonnable?
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: Great power comes with great responsability...
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 : Tout sélectionner
# tcpdump -vvA host votre.host.ftp and port 2120: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 toto
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 mon_mot_de_passe_SECRET!
Alors, chiffrer ses mots de passe sur un client, se sentir protégé et puis faire du ftp normal, est-ce vraiment raisonnable?
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: Great power comes with great responsability...
ripat
Je disais juste que si c'était chiffré on n'obtenait pas les accès dans la seconde. 
Au passage :
Au passage :
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.Un collègue indélicat? Dans ce cas tu as des soucis à te faire sur ta politique de sécurité.