DMARC.org un pas en avant dans la lutte contre le phishing?

[MacIntoc]

Teraoctet>Quand un client dépose une demande de contact via mail sur le site de ma boite, le serveur du site envoie un mail au nom du client. Pourtant, le client n'a pas envoyé de lui-même un mail.

Tiens, un petit script PHP que tu peux faire tourner sur n'importe quelle machine qui permet d'envoyer des mails au nom de n'importe qui :

$header= "From: teraoctet@totoland.com\r\n";//on indique que l'envoyeur est teraoctet@totoland.com
$header.= 'Content-type: text/plain' . "\r\n"; //là, on dit au qu'on envois du texte
$to=implode(',', $destinataires); //$destinataire est un tableau qui contient la liste de tous les mails à spammer
$object='important !!!!!!!! ces pas une arnac'; //là, c'est le sujet du mail. Alors bien sur, on dit surtout pas que c'est une arnaque, hein
$content='Yé souis pauvre, envoyer beaucoup argent a ma famille, syouplé.'; //un petit texte pour bien serrer le pigeon.
mail($to, $object, $content, $header); //on envoie le filet sur le net

Avec ces 6 lignes de codes, toutes les adresses contenues dans le tableau $destinataire recevront un mail envoyé par teraoctet@totoland.com
Donc tu vois bien qu'il est totalement inutile de pirater la moindre machine pour envoyer un mail à partir d'une adresse quelconque.

C'est dommage qu'il n'y ait pas de balise pour garder au moins l'indentation du texte :-/

[Teraoctet]

Tu as entièrement raison sur ce point.

Remember, Dmarc est fait pour lutter contre le phishing pas contre le spam

Ce qui semble être préconisé pour palier à ce que tu décris, c'est que la signature soit dans l'entête du message, dans le message mais aussi en queue du message.
Dans l'entête OK, en queue du message OK, le seul petit bémol c'est dans le corps du message 'what's to be done?...'
Dmarc dans ce cas, et si cette solution est retenue, apprendra à lister des mots clés dans la généralité (travail fastidieux...pas tant que ça dans la mesure ou il se servirait d'un dictionnaire chiffré, c'est réalisable).

Je le répète, les parties preneuses de ce système sont avant tout des banques, des entreprises dites sensibles ou de tailles supérieures.

Sur l'échange des mails que je reçois, puisque tout le monde de ce forum reçoit les mêmes mails , près de 60% émanent d'entreprises toutes catégories confondues des USA les autres sont d'Angleterre et d'Allemagne et pas une seule de France serions nous encore une fois à la traine?...

A ma connaissance, cela ne concerne pas l'utilisateur lambda pour qui rien n'est prévu actuellement.

[caméléon]

A ma connaissance, cela ne concerne pas l'utilisateur lambda pour qui rien n'est prévu actuellement.

Bah si puisque c'est implémenté dans Gmail, donc tous ces utilisateurs en profitent déjà. Voir mon 1er post:

Gmail a constaté que 15% des messages qui transitent par ces services utilisent déjà cette technologie!

[Teraoctet]

Bonjour Caméléon,

15% des utilisateurs de gmail OK mais des entreprises, car dans l'ensemble des utilisateurs, qui pense à signer numériquement ses message?... Ce qui laisse donc à penser que la technologie Dmarc est orientée pour les entreprises et non pour le particulier sauf cas exceptionnel, ou peut être dans un contexte particulier.
De plus il faudra éduquer le personnel des entreprises, ce ne n'est pas toujours une mince affaire.
Si j'ai bien assimilé le concept, il faut comme tout chiffrement de message une clé publique et une clé privée. Cela nécessite bien souvent même si c'est simple à réaliser entre 2 correspondants une petite éducation, crois tu vraiment que l'usager particulier va prendre cette routine en compte?...Personnellement je n'y crois guère .
Raison de plus pour étayer ma conviction, si Dmarc réellement se dirigera vers la solution d'une signature triple du document à envoyer, quelle cinéma pour l'usager particulier. Il y a de fortes chance qu'il se perde durant la manipulation.

[vulcain]

Le chiffrement dont tu parles n'est-il pas fait par le serveur smtp ? Je reçois des mail venat de @gmail avec une DKIM dans l'entête.
Bref, je ne crois pas que les utilisateurs de gmail soit au courant de la notion de clé, c'est transparent pour eux.

[MacIntoc]

Teraoctet>Ça ne change rien au principe. Remplace le texte par "Salut les amis, je vous envois une vidéo qui m'a fait mourir de rire." avec un fichier exe vérolé en pièce jointe ou un lien vers un site qui exploite une faille du navigateur. Ou alors, remplace "teraoctet@totoland.com" par "service.client@amazon.com" et le texte par "Pour des raisons de sécurité, veuillez confirmer la validité de votre adresse mail en cliquant sur le lien suivant." avec un lien renvoyant vers un site reprenant la charte graphique d'Amazon demandant le login et le mdp de l'utilisateur. Après, tu fais ce que tu veux.

[calimo]

Dans la mesure ses clients n'ont pas tous le réflexe de vérifier en amont la signature avant de poster le mail.

C'est au niveau du serveur que ça se passe. On ne parle pas de signature client (SMIME ou PGP), mais de DKIM qui se configure sur le serveur (certes, le serveur de tes clients). Comme le dit vulcain, le client n'a rien à faire.
Je ne sais pas exactement si DMARC ajoute quelque chose à ce niveau.

Tiens, un petit script PHP que tu peux faire tourner sur n'importe quelle machine qui permet d'envoyer des mails au nom de n'importe qui :

Merci pour cet exemple très parlant

Ce qui semble être préconisé pour palier à ce que tu décris, c'est que la signature soit dans l'entête du message, dans le message mais aussi en queue du message.

La signature DKIM signe à la fois le corps du message et les entêtes (qu'est-ce que la queue du message ?) (les entêtes étant susceptibles d'être altérées lors du transfert, je ne sais pas exactement quelles règles sont utilisées).

Dmarc dans ce cas, et si cette solution est retenue, apprendra à lister des mots clés dans la généralité (travail fastidieux...pas tant que ça dans la mesure ou il se servirait d'un dictionnaire chiffré, c'est réalisable).

Hein ? Pas compris...

[Teraoctet]

> MacIntoc Encore une fois tu as raison sur le fond pour les usagers particuliers

Teraoctet>Ça ne change rien au principe. Remplace le texte par "Salut les amis, je vous envois une vidéo qui m'a fait mourir de rire." avec un fichier exe vérolé en pièce jointe ou un lien vers un site qui exploite une faille du navigateur. Ou alors, remplace "teraoctetXtotoland.com" par "service.clientXamazon.com" et le texte par "Pour des raisons de sécurité, veuillez confirmer la validité de votre adresse mail en cliquant sur le lien suivant." avec un lien renvoyant vers un site reprenant la charte graphique d'Amazon demandant le login et le mdp de l'utilisateur. Après, tu fais ce que tu veux.

Supposons un instant que ce sont des banques et leurs clients ou leurs correspondants, cela devient improbable au prime abord.

Je ne sais pas exactement si DMARC ajoute quelque chose à ce niveau.

Il est totalement différent car il agira en amont du serveur. Le serveur n'a plus rien à voir pour le phishing il ne sert que pour l'antispam et encore...
Ensuite le receveur du message devra faire une manipulation pour la vérification finale automatisée par la clé en sa possession, oui cela semble plus compliqué que DKIM . Les fonctions dans l'ensemble sont différentes. Je ne sais pas si DKIM travaille au niveau du phishing.
La signature sera triple dans un message donc dans l'entête, le corps et à la fin du message afin de confirmer le tout, voilà ce qui en ressort jusqu'à présent


Pour répondre à ton incompréhension pour cette partie:

Dmarc dans ce cas, et si cette solution est retenue, apprendra à lister des mots clés dans la généralité (travail fastidieux...pas tant que ça dans la mesure ou il se servirait d'un dictionnaire chiffré, c'est réalisable).

Il sera possiblement adjoint quelque chose qui permettra dès l'envoi de vérifier certains mots utilisés donc de classifier et de rejeter le message avant son arrivée chez le destinataire. Puisque bien souvent ce sont les mêmes mots ou synonymes qui sont utilisés dans les tentatives de phishing. Ok, tu vas me dire que cela semble arbitraire. Peut être oui au début mais ensuite cela peut rapidement devenir rentable.

Ne nous méprenons pas, ce n'est encore qu'en développement.

[calimo]

Il est totalement différent car il agira en amont du serveur. Le serveur n'a plus rien à voir pour le phishing il ne sert que pour l'antispam et encore...

Ce n'est pas du tout comme ça que je le comprend.

DMARC standardizes how email receivers perform email authentication using the well-known SPF and DKIM mechanisms.

« DMARC spécifie la manière dont les destinataires réalisent l'authentification des emails à l'aide des mécanismes SPF et DKIM. »
Ces deux mécanismes ne sont pas du tout des mécanismes client, mais implémentés sur les serveurs. Bien sûr à la fin c'est le destinataire qui prend la décision d'accepter ou non le message. Mais le but, clairement, est que ce soit le serveur destinataire qui prenne la décision (selon des règles à définir), en fonction des informations données par le serveur émetteur et des traitements (signature) effectués par celui-ci.
Bien sûr le client peut le faire mais fondamentalement la majorité du traitement se ait au niveau des serveurs émetteur et destinataire.

(NB : ici je parle de client dans le cadre d'une architecture client-serveur, pas d'une relation commerciale.)

Il sera possiblement adjoint quelque chose qui permettra dès l'envoi de vérifier certains mots utilisés donc de classifier et de rejeter le message avant son arrivée chez le destinataire.

Cela ressemble plus à de la fiction de ta part. Je ne vois aucune indication de cela sur le site de DMARC. De plus, ça n'aurait strictement aucune cohérence d'inclure une liste de mot clé dans ce genre de spécification qui parle d'authentification de l'émetteur par des méthodes de chiffrement asymétriques. C'est juste totalement ridicule

[Teraoctet]

Bonjour

Cela ressemble plus à de la fiction de ta part. Je ne vois aucune indication de cela sur le site de DMARC. De plus, ça n'aurait strictement aucune cohérence d'inclure une liste de mot clé dans ce genre de spécification qui parle d'authentification de l'émetteur par des méthodes de chiffrement asymétriques. C'est juste totalement ridicule

Attention cela n'apparait pas sur le site c'est logique, mais dans l'échange des messages cela fut proposé.

DMARC spécifie la manière dont les destinataires réalisent l'authentification des emails à l'aide des mécanismes SPF et DKIM. »
Ces deux mécanismes ne sont pas du tout des mécanismes client, mais implémentés sur les serveurs. Bien sûr à la fin c'est le destinataire qui prend la décision d'accepter ou non le message. Mais le but, clairement, est que ce soit le serveur destinataire qui prenne la décision (selon des règles à définir), en fonction des informations données par le serveur émetteur et des traitements (signature) effectués par celui-ci.
Bien sûr le client peut le faire mais fondamentalement la majorité du traitement se ait au niveau des serveurs émetteur et destinataire.

C'est pourtant bien ce à quoi les demandes ont été faites, soit en amont. Cela semble logique au niveau de banques et surtout de Paypal qui en fait la suggestion, sachant que dans le cadre du phishing elles se font plagier leur logo etc... elles ont émises ce désir.
Je n'avais pas écris cela sera ainsi d'une manière ferme mais toujours au conditionnel.

A cette heure nous savons ce qu'il en est

[MacIntoc]

Pour répondre à ton incompréhension pour cette partie:

Dmarc dans ce cas, et si cette solution est retenue, apprendra à lister des mots clés dans la généralité (travail fastidieux...pas tant que ça dans la mesure ou il se servirait d'un dictionnaire chiffré, c'est réalisable).

Il sera possiblement adjoint quelque chose qui permettra dès l'envoi de vérifier certains mots utilisés donc de classifier et de rejeter le message avant son arrivée chez le destinataire. Puisque bien souvent ce sont les mêmes mots ou synonymes qui sont utilisés dans les tentatives de phishing. Ok, tu vas me dire que cela semble arbitraire. Peut être oui au début mais ensuite cela peut rapidement devenir rentable.

Pour moi, ce que tu décris est un bête filtre bayésiens.

[Teraoctet]

tout à fait

[calimo]

Attention cela n'apparait pas sur le site c'est logique, mais dans l'échange des messages cela fut proposé.

Évidemment il y a toujours un hurluberlu pour proposer n'importe quoi.
Après il faut savoir faire la part des choses

[Teraoctet]

tout à fait

[caméléon]

ben dit donc, je ne me serais jamais douté qu'un sujet aussi pointu récolte 3 pages de commentaires passionnés (et dépassant largement mes modestes compétences) en aussi peu de temps
Geck o zone mérite toujours bien son nom