Bienvenue sur Web-News
Re: Qu'est-il arrivé ? 08/07/26 00:14 / Wed, 8 Jul 2026 00:14:21 +0200 Dedibox Discussions
| Sujet | Re: Qu'est-il arrivé ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| De | Thomas | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Date | Wed, 8 Jul 2026 00:14:21 +0200 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Groupes de discussion | proxad.free.services.messagerie | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Le 01/07/2026 à 15:14, Francois Petillon a écrit : > Bref, cela peut être exceptionnel pour certains fournisseurs de VPN et > récurrent pour d'autres. Merci pour toutes vos réponses. :-) Sur ce sujet, je laisse les personnes concernées creuser plus. > Certains fournisseurs proposent du "split tunneling" (router seulement > certains traffic via le tunnel). Cela permet de limiter la casse. À la fois intéressant, et dommage que ça soit à l'initiative du fournisseur. Mais je creuserai ça plus tard. > >> Je vous suggère fort d'ajouter ces explications à la page >> https://postmaster.free.fr/comptescompromis.html Parce que, vous m'avez >> appris quelque chose ce jour là (je ne l'avait lu nulle part ailleurs >> avant, je croyais que les mots de passe légèrement différents c'était >> suffisant pour être différents, et je ne dois pas être le seul), > > C'est suffisant pour être différent (les hashes sont radicallement différents) ... et le serveur ne répond pas "Essayez encore parce que vous n'en êtes pas loin !" C'est pour ça que je n'avais pas eu l’idée que "réutilisation" correspondait à "identique /ou légèrement différent/". AMHA ça serais mieux de formuler ça un peu différemment, genre "utilisation sur d'autres sites de votre mot de passe soit identique soit légèrement modifié" au lieu de "réutilisation de vos identifiants sur d'autres sites", pour que ça soit précisé d’emblée. (Changer "identifiants" pour "mot de passe" n'est pas gênant, puisqu'après tout, réutiliser le mot de passe de sa boite aux lettres sur un site auquel on n'a pas donné l'adresse de sa boite aux lettres n'est pas une pratique particulièrement recommandée. :-D ) > mais cela limite fortement la complexité réelle à deviner un autre mot de > passe construit sur la même base. Maintenant j'ai bien compris. :-) > J'ai modifié la page. Merci, il y a le plus important. Je vous laisse voir si vous trouvez une meilleure formulation plus tard. :-) > >> 2) >> Pourquoi avez-vous décidé que, quand un compte est compromis, les >> courriels entrants ne sont pas acceptés ? > > Cela reviendrait à accepter un mail alors que nous n'avons pas la moindre > idée de si le propriétaire de la boite mail sera en mesure de le > consulter. Il y a seulement une moitié des comptes compromis qui sont > débloqués. OK, je vois le problème pour les expéditeurs, et je suis d'accord qu'il faut en tenir compte. Le problème pour le destinataire, c'est de ne pas retrouver après déblocage les messages envoyés dans l'intervalle de temps du blocage. Surtout que les expéditeurs sont avertis, mais avec un message d'erreur "550 5.1.1 user unknown", qui est trompeur par rapport à la cause réelle. Comme le destinataire n'est pas au courant des messages non reçus, il ne peut pas avertir les expéditeurs de cette bizarrerie, de ne pas s'affoler, conserver l'adresse, ... Peut-on envisager d'indiquer un problème temporaire pour demander au serveur expéditeur de réessayer plus tard ? Ça permet à la fois de garantir que l'expéditeur sera prévenu si la boite aux lettres n'est pas débloquée, et de donner au destinataire des chances raisonnables de recevoir le message quand-même. (Vu ce que vous écrivez ensuite, si je comprends bien les pirates maîtrisent déjà leur affaire, donc ça ne changera rien pour eux d'avoir un message d'erreur différent.) Petit calcul : - Prenons l'ensemble des comptes qui ont été compromis, réduit à ceux qui sont débloqués. - Mesurons la durée du blocage. - Faisons la moyenne (ou la médiane, je ne sais jamais lequel des 2 est approprié). - Multiplions-la par (par exemple) 2. Est-ce que ça couvre, disons, au moins 90% des cas ? Est-ce que ce délai est raisonnable pour indiquer un problème temporaire, et passer à un problème permanent une fois que ce délai est dépassé ? Je pose cette question du point de vue du protocole, mais j'imagine aussi que le problème temporaire implique aussi une (légère ?) augmentation de la charge de tous les serveurs. Donc je pose aussi la question de ce point de vue là , lié au % de comptes compromis se trouvant dans cette situation à un instant donné. -- RAPID maintainer https://savannah.nongnu.org/projects/rapid/ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
