Protection des adresses mail par unicite

{{Ingenie
 * titre=Protection des adresses mail par unicité
 * courte description=Réduire la diffusion de son adresse mail principale en utilisant des adresses intermédiaires pour réduire l’exposition au spam lors des piratages de sites où on est inscrit
 * description-fr=Il est proposé ici une méthode permettant de limiter le spam à très long terme sur une adresse mail nous appartenant.

Description rapide
Cette méthode demande de définir des adresses mail uniques (ou presque uniques), différentes d’un site à l’autre. Au prix d’un peu plus de complexité lors de l’inscription à un site web, cela permet de préserver son adresse principale du spam. À long terme, cela protège du risque de voir son adresse leakée, c’est-à-dire piratée sur un site web faible, récupérée par des spammeurs, et donc spammée sans possibilité d’arrêter la source du spam (le seul moyen de ne plus reçevoir de spam est de mettre en place des méthodes coûteuses, complexes et peu fiables de reconnaissance du spam) : la meilleure protection contre le spam est que l’adresse reste inconnue des spammeurs.

Par exemple, je pourrais utiliser les adresses suivantes sur les sites suivants (en remplaçant example.org par mon nom de domaine seb35.fr) : Et si jamais Twitter (par exemple) se fait pirater sa base de données d’utilisateurs, l’adresse de contact n’aura qu’à être changée en 45565ch@example.org.
 * sur wikipedia.org : 9daf0eg@example.org
 * sur ekopedia.org : b2d845g@example.org
 * sur twitter.com : 169e3ag@example.org

Modèle économique du spam
En préalable, voici une description sommaire du modèle économique entourant le spam. Envoyer un spam (ou un mail plus généralement) est très peu coûteux, il est donc possible d’en envoyer un grand nombre pour un montant très raisonnable. Le spam cherche généralement soit à vendre un produit (souvent du viagra) soit est une escroquerie (par exemple propose de faire transiter 100 000 € via son compte et d’en récupérer 10 000 € de commission). Si une infime partie des gens – par exemple 0,1 % – des gens qui reçoivent le spam achètent ledit produit ou répondent à l’escroquerie, et vu le faible coût de l’envoi du spam, les spammeurs peuvent gagner de l’argent.

Une difficulté majeure dans pour les spammeurs est que le spam atteigne l’utilisateur humain et ne soit pas bloqué par les systèmes anti-spam. Il y a un certain nombre de méthodes d’ordre tactique, par exemple écrire du texte dans une image car les systèmes anti-spam ne savent pas "lire" les images, mais une méthode d’ordre plus stratégique est de récupérer des adresses "qualifiées", c’est-à-dire des adresses dont on sait qu’elles existent d’une part (point extrêmement important) et qu’elles sont réellement utilisées et lues (elles n’appartiennent pas à une personne décédée et ne sont pas d’anciennes adresses oubliées et plus lues). Il faut préciser que les adresses peuvent être "qualifiées" avec un certain pourcentage de qualité (par exemple un utilisateur qui vient d’inscrire son adresse mail sur un site est plus susceptible de la lire qu’un utilisateur qui s’est inscrit il y a 10 ans).

Afin d’obtenir des adresses qualifiées, les spammeurs peuvent recourir à l’achat d’adresses mail qualifiées. Les fournisseurs d’adresses mail qualifiées peuvent être notamment des pirates ayant piraté des sites web (par exemple des sites de vente en ligne qui demandent l’adresse mail à leurs utilisateurs) et récupéré l’ensemble des adresses mail des utilisateurs du site piraté, et ils ont peut-être même récupéré les dates d’inscription des utilisateurs ou peut-être même une information "adresse vérifiée" si le site a une telle procédure, autant d’informations permettant de calculer la "qualité" des adresses mail, c’est-à-dire si l’utilisateur humain derrière l’adresse mail est susceptible de lire l’adresse en question.

Description générale de la méthode
Cette méthode – ou plutôt cette famille de méthodes – demande d’être pro-actif personnellement et n’est pas (en l’état) destinée à être une méthode générale de lutte contre le spam. En revanche, à l’échelle personnelle, elle est résistante aux leaks d’adresses mail (= lorsqu’un pirate pirate un site web, récupère la liste des adresses mail, et la revend à des spammeurs). Le principe repose sur une remise en question de l’unicité de l’adresse mail sur les très nombreux sites réclamant une adresse mail qui ne servira, dans la majorité des cas, qu’à envoyer un mot de passe temporaire en cas d’oubli et, parfois, à envoyer une lettre d’information ou des notifications. L’idée est de remplacer ces adresses mail par des adresses mail uniques. L’hypothèse sous-jacente que ce sont principalement des logiciels (et non des humains) qui envoient les mails de rappel de mot de passe, de lettres d’informations et de notifications, et qu’il est donc pas ou peu nécessaire d’avoir une adresse "compréhensible".

Par exemple, je pourrais utiliser utiliser les adresses suivantes sur les sites suivants (noter que example.org est à remplacer par le nom de domaine de l’utilisateur dans le cas où il en possède un) : Ces adresses répondent à une logique me permettant, si j’ai besoin de retrouver le mot de passe correspondant, de retrouver le nom de l’adresse mail utilisée. Je ne donne pas ici l’entièreté de la méthode utilisée, mais si vous voulez jouer c’est à base de MD4 (sic) et je précise que j’ai choisi une méthode à titre d’exemple que je n’utilise pas forcément en production. Cela illustre en même temps le principal risque à utiliser cette méthode (risque qui peut être mitigé voire annihilé) : perdre définitivement un ou plusieurs accès en l’absence d’une méthode fiable et documentée sur le très long terme. Si par exemple Twitter est piraté (et on pourra peut-être s’en rendre compte si on reçoit un spam sur l’adresse 169e3ag@example.org), il suffira de changer pour une adresse à la suite dans la logique de la méthode, ce qui serait ici, pour Twitter, 45565ch@example.org.
 * sur wikipedia.org : 9daf0eg@example.org
 * sur ekopedia.org : b2d845g@example.org
 * sur twitter.com : 169e3ag@example.org

Au-delà de la protection personnelle contre le spam, une propriété fortement intéressante à plus grande échelle est que, en cas de leak d’une base de données d’adresses mail et son l’utilisation, il suffit qu’une seule personne utilisant une telle méthode pour identifier la source du leak – à condition bien sûr que la ou les personnes en question rapportent le leak. On peut même imaginer l’insertion volontaire de telles adresses comme « traceurs » permettant de détecter le leak d’une base de données d’adresses : si l’adresse traceur reçoit un spam (et qu’elle est suffisamment compliquée pour que le spammeur ne soit pas tombé dessus par hasard), alors il y a eu un leak (en fait il n’y a pas forcément besoin de cette méthode pour tracer les leaks, cette méthode permet juste de distribuer le traçage).

La suite de cette page décrit une famille de méthodes permettant de créer des adresses uniques ou presque uniques, et décrit les risques opérationnels liés à l’utilisation de cette méthode, ainsi que les risques liés aux choix de la méthode spécifique (ceux-ci ayant une influence sur les risques opérationnels). Je ne décris pas intentionnellement une méthode précise pour plusieurs raisons :
 * décrire une méthode précise pourrait permettre à des spammeurs de contrecarrer ladite méthode,
 * selon les personnes, les contraintes de sécurité peuvent être très variables et une méthode unique ne conviendrait pas à tout le monde,
 * cette famille de méthodes en est seulement au stade de l’idée.

Noter que, contrairement à de la cryptographie standard, il n’est pas forcément question ici de rendre les méthodes cryptographiquement robustes (cela ne sert pas forcément à grand chose pour la majeure partie des utilisateurs) mais plutôt de méthodes pérennes et donc simples. En conséquence l’utilisation du mot « entropie » ci-dessous fera sourire (voire choquera) les cryptographes, on pourra alors remplacer par « variabilité ». Je dis cela car j’entends déjà les critiques comme quoi MD4 ou ROT13 ne sont pas cryptographiquement sûrs pour rester dans l’euphémisme : la robustesse de la sécurité devrait s’adapter au niveau de risque, et le risque à très long terme (10, 20, 50 ans) de perdre un accès à cause de la perte de mémoire (crash de disque dur, oubli de la méthode…) de l’adresse mail de secours permettant de recouvrer ledit accès est à mon sens supérieur au risque qu’un spammeur fasse l’effort de comprendre une méthode donnée dans le cas général (mais tout dépend du modèle de menaces bien sûr).

Techniquement, la création d’adresses uniques peut se faire à plusieurs niveaux. Il a été pour l’exemple un nom de domaine personnel, c’est probablement le plus robuste et fiable dans le temps à condition que l’utilisateur garde son nom de domaine sur le long terme. Si l’utilisateur n’a pas de nom de domaine personnel, il pourra utiliser, si son fournisseur d’adresse mail le permet, les extensions au nom principal, souvent ce qui suit le caractère "+" :  (où example.org peut être le fournisseur d’adresse mail, par exemple gmail.com).

Données de base possible

 * Numéro de schéma
 * Pour pouvoir changer de schéma de nommage sur du très long terme, par exemple "v1" puis "v2"


 * Nom du site / nom de domaine
 * Pour distinguer les adresses mail les unes des autres et ajouter de l’entropie


 * Identifiant
 * Pour distinguer différents personae au sein d’un même site / nom de domaine


 * Numéro de version
 * Pour ajouter de l’entropie qui permettra de changer d’adresse mail si besoin


 * Mot de passe ou sel cryptographique
 * Pour ajouter de l’entropie



Noter que les données de base devraient avoir une certaine stabilité, par exemple :
 * penser au cas où un site change de nom de domaine, voire change de nom, ou aux variations possibles dans le nom (avec ou sans espaces, etc.)
 * la notion d’identifiant est variable d’un site à l’autre : adresse mail (récursion!), pseudonyme, nom civil, numéro, et parfois même au sein d’un site : connexion avec l’adresse mail puis identification publique par un numéro
 * la notion d’identifiant peut être avantageusement remplacée par la notion de persona : au lieu d’utiliser le numéro arbitraire d’identification sur le site donné, utiliser la persona sous laquelle on s’identifie sur ce site, par exemple son identité civile "Clark Kent" (invariante quelle que soit la forme des identifiants du site) ou son identité secrète "Superman" (invariante quelle que soit la forme des identifiants du site), ou alors définir une persona "identité professionnelle" et une autre "identité personnelle".

Risques
(occurrence et criticité notées de 0 à 5 ; occurrence 5 = souvent ; criticité 5 = très grave)

Opérationnels
Risques au cours de l’utilisation de cette méthode, une fois la méthode particulière définie.


 * Perte de mémoire d’une adresse mail pour récupération d’un accès
 * occurrence : 3
 * criticité : 5
 * mitigation : schéma simple et déterministe
 * criticité après mitigation : 2


 * Leak de l’ensemble des adresses mail suite au piratage du serveur mail
 * occurrence : 2
 * criticité : 5
 * mitigation : avoir un numéro de version pour réinitialiser les adresses mail
 * criticité après mitigation : 3


 * Leak d’une adresse mail suite au piratage d’un site où on a enregistré l’adresse mail
 * occurrence : 5
 * criticité : 1
 * mitigation : avoir une variable dans le schéma (numéro de version et/ou mot de passe)
 * criticité après mitigation : 0

Liés au schéma
Risques liés spécifiquement à la méthode particulière que l’on choisit initialement. De façon générale, plus on choisit un schéma compliqué, moins les spammeurs vont retrouver les spécifications du schéma, mais plus on a de risques à titre personnel de retrouver soi-même ces spécifications, au moins sur le long terme (50 ans).


 * Perte de mémoire d’une adresse mail pour récupération d’un accès [si schéma non-déterministe]
 * occurrence : 3
 * criticité : 5
 * mitigation : aucune
 * criticité après mitigation : 5


 * Perte de mémoire d’une adresse mail pour récupération d’un accès [si schéma déterministe complexe]
 * occurrence : 3
 * criticité : 5
 * mitigation : essai des différents schémas et versions, long et sujet à erreurs
 * criticité après mitigation : 3


 * Perte de mémoire d’une adresse mail pour récupération d’un accès [si schéma déterministe simple]
 * occurrence : 3
 * criticité : 5
 * mitigation : essai des différents schémas et versions, court mais légèrement sujet à erreurs
 * criticité après mitigation : 2


 * Complexité d’utilisation
 * occurrence : 5
 * criticité : 4
 * mitigation : réduction du nombre et de la complexité opérationnelle des paramètres et méthodes
 * criticité après mitigation : 2


 * Méthodes de calcul non-courantes
 * occurrence : 3
 * criticité : 5
 * mitigation : utiliser des méthodes de calcul courantes (même si sans robustesse cryptographiques), création d’un site web permettant le calcul
 * criticité après mitigation : 0


 * Méthodes de calcul non-pérennes
 * occurrence : 1
 * criticité : 5
 * mitigation : utiliser des méthodes de calcul plus simples (même si sans robustesse cryptographiques), création d’un site web permettant le calcul
 * criticité après mitigation : 3


 * Adresse difficile à épeler, par exemple par téléphone
 * occurrence : 5
 * criticité : 3
 * mitigation : transformation (par exemple diceware) après calcul, n’utiliser que des lettres ou chiffres
 * criticité après mitigation : 1


 * Schéma devinable par les spammeurs
 * occurrence : 2
 * criticité : 4
 * mitigation : ne pas proposer de schéma standard mais des briques de schéma et/ou paramètres non-standards, adapter le schéma à la robustesse souhaitée
 * criticité après mitigation : 1

Schémas
Designs possibles :
 * hash : MD4, MD5, SHA1, SHA2…
 * modulo
 * addition
 * dictionnaire
 * troncation
 * ROT (ROT13, ROT1 ou autre)
 * diceware

Dimensionnement :
 * entropie suffisante (sans besoin d’être importante), par exemple 1 à 10 millions de combinaisons

Limitations : }}
 * restreint aux interlocuteurs répondant au schéma, par exemple ayant un nom de domaine canonique
 * description du gain=Limiter sa propre exposition au spam
 * exemple=Adresses mail intermédiaires :
 * sur wikipedia.org : 9daf0eg@example.org
 * sur ekopedia.org : b2d845g@example.org
 * sur twitter.com : 169e3ag@example.org, 45565ch@example.org
 * title=Protect email addresses using unicity
 * short description=Reduce diffusion of our own email address by using intermediairy addresses in order to reduce exposition to spam during hacking of websites where our address is registered
 * described gains=Reduce our own exposition to spam
 * example=Intermediairy email addresses:
 * on wikipedia.org : 9daf0eg@example.org
 * on ekopedia.org : b2d845g@example.org
 * on twitter.com : 169e3ag@example.org, 45565ch@example.org
 * author=Seb35,
 * author nationality=Française,
 * creation date=20170814180704
 * modification date=20170814200705
 * number of modifications=1
 * portal=Technology
 * what is it keywords=software, email, internet, backup, uniqueness, unique, collaboration,
 * what is it for keywords=improvement, collaboration, communication, spam, avoid,
 * primary key=1360
 * physical object=False
 * implemented=False
 * invented with coci=False
 * libre license=True
 * stub=True
 * subjective vote=0
 * ease of implementation rational vote=0
 * potential users rational vote=0
 * frequency use rational vote=0
 * frequency use rational vote=0