Bjarno Oeyen

Hoe kan je geautomatiseerde e-mails uit je inbox weghouden door middel van Captchas, public key signing en wat APIs

Abstract

Door gebruik te maken van Captchas, APIs en een aangepaste vorm van Public Key Crytography (alleen Signing) kan geautomatiseerde spam volledig verdwijnen, zonder dat automatische notificatieberichten niet meer mogelijk zijn, en zonder dat er voor elke e-mail geverifieërd moet worden of deze afkomstig is van een mens. In deze uitleg stel ik een systeem voor hoe verschillende mailservers elkaar kunnen vertrouwen, en hoe gebruikers kunnen bewijzen dat ze een persoon zijn, en geen computer, met rekening te houden van technologische problemen en gebruikersgemak. Ook is er een uitleg hoe Captchas door mensen opgelost kunnen worden voor rogue redenen.

Introductie

Sinds ik ben overgestapt op mijn eigen e-mail, en niet meer op Gmail zit, heb ik van 1 ding enorm veel meer last gekregen. SPAM. Automatische berichten die in mijn inbox belanden omdat een van mijn zovele e-mailadressen ooit is opgepikt is geweest door een spamrobot. Je e-mailadres encoderen met (at) en (dot) is geen ideale oplossing meer. De enige oplossing om je e-mailadres niet automatisch zichtbaar te maken is door het te verstoppen achter een puzzeltje.

Een van de oplossingen die ik jaren geleden gezien heb was om je e-mailadres achter een captcha te zetten. Het werkte als volgt: je vult op hun website jouw e-mailadres in, ze genereren voor jou een pagina waar eerst een captcha moet opgelost worden om het e-mailadres te kunnen lezen. Het werkt ideaal om je e-mailadres verstopt te houden op het internet voor automatische crawlers, maar beschermt je helemaal niet tegenover e-mailadressen die gestolen zijn uit gehackte databases, virussen op computers van vrienden en kenissen die het adresboek van een mailclient gekopieërd hebben naar een server in een ver land, of gewoon de noodzaak voor bedrijven om je e-mailadres op visitekaartjes achter te laten, en op je website.

Je e-mailadres is nu “geheimer”, maar iemand kan handmatig, eenmaal, de captcha oplossen, en vervolgens automatisch een mail sturen voor Viagra, of over het feit dat je de Internationale Lotterij gewonnen hebt. Het is moeilijker om automatisch je e-mailadres te lezen, maar mails sturen, is even handig gebleven.

Waarom sturen mensen e-mails?

Waarom gaan we niet een stap verder? Waarom gebruiken we geen captcha als we een mail sturen? Geen probleem voor mensen om even een puzzeltje op te lossen door een paar karakters in te tikken, wel moeilijk voor automatische spambots. Laten we hier een iets diepzinniger onderzoek naar doen.

Waarom wordt e-mail legitiem gebruikt momenteel? Je hebt communicatie tussen mensen onderling, communicatie tussen computer en mens (nieuwsbrief, notificatie van een nieuw bericht op een social network site), en communicatie van mens naar computer (er zijn een paar websites waar je een bericht op een blog kan plaatsen door naar een “geheim” e-mailadres een bericht te sturen, de inhoud wordt in een nieuw blogbericht of notitie geplaatst, zonder dat je het dashboard hebt moeten bezoeken). Ik dacht ook even om hier communicatie tussen computers bij te zetten, maar ik denk dat hiervoor e-mail helemaal niet gebruikt wordt (althans niet bedoeld: ik heb al wel verhalen gehoord waarbij Out of Office e-mails een avalanche kunnen veroorzaken, of waarbij er een speciaal e-mailadres om iedereen in een organisatie op de hoogte te brengen, en combinaties ervan). We moeten ervoor zorgen dat de 3 “gewone” gebruiken van e-mail bewaard blijven met dit systeem.

Communicatie tussen personen onderling

Om te beginnen: mail tussen 2 personen. Dit kan zowel binnen dezelfde organisatie zijn, tussen 2 organisaties onderling, of misschien gewoon een mail om iemand uit te nodigen op een barbecue. Het belangrijkste is dat er 2 inboxen zijn op 1 of 2 servers en dat deze 2 personen ongerust een e-mail naar elkaar kunnen sturen. Het gewone verloop van mijn idee gaat in dat geval als volgt:

Persoon A wilt een e-mail sturen naar de inbox van persoon B. De mailserver van persoon A contacteert de mailserver van persoon B. Die mailserver genereert een captcha met bijhorende oplossing, en een unieke “handshake” id. De mailserver van persoon A stuurt deze captcha naar de mailclient van persoon A en die moet het antwoord geven DX4987. Het antwoord wordt samen met de handshake opgestuurd. Als het antwoord juist is, dan weet de mailserver van persoon B dat de mail door een echte gebruiker is goedgekeurd.

Het enige probleem is: een captcha invullen voor elk bericht dat je stuurt is nogal omslachtig, je wordt altijd er even aan herinnerd dat je moet bewijzen dat je geen computer bent. Daarom dat er een middel moet zijn waarbij gebruikers elkaar kunnen vertrouwen. Als je zeker weet dat die persoon de juiste persoon is, dan zou je bijvoorbeeld een e-mail kunnen ondertekenen. Een ondergetekende e-mail kan alleen maar van de juiste persoon komen, die al bewezen heeft dat hij geen computer is, en zou een captcha dus overgeslagen kunnen worden.

Er wordt alleen een captcha gegenereerd als de persoon onbekend is of als het bericht niet ondertekend is. Een persoon als “bekend” markeren zou automatisch kunnen gebeuren, als er op het bericht een reactie wordt gegeven, of als je de signatuur van de gebruiker als “menselijk” markeert.

Om te reageren op een bericht zonder captcha zou er een captcha op voorhand aangemaakt kunnen worden op de mailserver van persoon A. De oplossing van die captcha wordt in een header meegestuurd in de mail van persoon B. Als persoon B reageert dan stuurt hij de oplossing van de captcha, samen met een handle door. Dit proces kan iedere keer herhaald worden, zodanig dat er alleen een captcha ingevuld moet worden bij de start van een conversatie.

Iedere persoon kan natuurlijk op elk moment beslissen dat bepaalde mails niet meer welkom zijn (alle captcha’s blokkeren).

Wat bij verschillende ontvangers?

Een ander aspect als er communicatie tussen personen is, is dat er ook vaak berichten worden gestuurd van 1 persoon, naar vele anderen (met dezelfde boodschap). Hiervoor zou een gebruiker, in het slechtste geval, evenveel captchas moeten oplossen, als er ontvangers van het bericht zijn. Zoiets wordt al geminimaliseerd door bepaalde signaturen als “bekend” te markeren. Als alternatief (dat niet volledig waterdicht is, zie later) zou er een soort van vertrouwensrelatie kunnen ontstaan tussen mailservers onderling. Terwijl de e-mail een voor een naar elke ontvanger gestuurd wordt, en de captcha mee opgelost wordt, kan een mailserver tegen andere mailservers zeggen dat een specifiek bericht, met een bepaalde ondertekening, menselijk is. Neem het volgende als voorbeeld als er een mail gestuurd wordt van persoon A naar personen B en C (alletwee op verschillende mailservers), waarbij er nog geen vertrouwde relatie, maar de mailserver van persoon B en de mailserver van persoon C elkaar vertrouwen.

Mailserver A stuurt het bericht naar mailserver B. Mailserver B vertrouwt het bericht niet, en vraagt om een captcha op te lossen. De oplossing wordt door mailserver A aangereikt en doorgestuurd naar mailserver B. Mailserver B slaagt het bericht op in de inbox van B, en geeft als antwoord op B een token terug die gebruikt kan worden om andere mailservers te garanderen dat het bericht menselijk is. Mailserver A stuurt nu hetzelfde bericht naar mailserver C, samen met een identificatie van mailserver B en het token. Mailserver C vertrouwt het bericht niet, maar ziet het token van mailserver B. Mailserver C contacteert nu mailserver B en verifieërt dat het token bij het bericht hoort. Mailserver B geeft als antwoord naar mailserver C dat het token en bericht klopt, en dat hij daarvoor reeds een captcha opgelost heeft. Mailserver C vertrouwt het bericht nu wel en classificeert het ook als “menselijk”.

Mailservers kunnen elkaar vertrouwen door verschillende organisaties onderling, alsook publieke mailservers. Ook al maakt een mogelijke spambot gebruik van een publieke server, zolang 2 mailservers elkaar vertrouwen dat de aangereikte captchas sterk genoeg zijn, dan zou er geen beveiligingsprobleem mogen zijn. Dat betekent dus dat zelfs de mailservers van Google (GMail), en de mailservers van Microsoft (Outlook) elkaar kunnen vertrouwen. De vertrouwensrelatie is op het technisch vlak, niet op de inhoud van berichten.

Het probleem van semi-automatische spam bij meerdere ontvangers

Als er maar 1 Captcha opgelost moet worden als alle mailservers elkaar vertrouwen, dan kan er nog wel sprake zijn van semi-automatische spam. Dat betekent dat er een bepaalde persoon is die naar een hele hoop gebruikers een bericht stuurd. Als hij 1 captcha oplost: en de mailservers vertrouwen elkaar onderling, dan kan hij nog steeds spam doorsturen. Er zouden bijvoorbeeld regels kunnen komen dat zoiets maar een beperkt aantal keren is toegestaan. Of dat minstens 70% van de gebruikers de afzender al als vertrouwd zien. Een ander mogelijkheid is door gebruik te maken van The Web of Trust om e-mailadressen elkaar publiekelijk te laten vertrouwen. Dit zou echter wel een computationele overload zijn waar ook misbruik van gemaakt kan worden in de vorm van DDoS-aanvallen, en kan ook de privacy schaden als het publiek duidelijk is welke persoon je vertrouwt.

De enige veilige manier is dus om Captchas in te vullen. Om te beargumenteren waarom dit misschien niet zo’n grote ramp is heb ik 2 argumenten.

  • Een mailserver waarop meerdere ontvangers staan moet maar 1x verifiëren dat jij de juiste persoon bent. Hier kan ook misbruik van gemaakt worden, maar verlaagt het aantal Captchas al wel. Dergelijke functionaliteit zou bijvoorbeeld kunnen uitgeschakeld worden op publieke servers.
  • De kans is groot dat je naar al deze ontvangers al eens een e-mail gestuurd hebt, en je elkaar al vertrouwt. Deze vertrouwensrelatie moet op voorhand ontstaan zijn.

Mailservers kunnen elkaar ook volledig vertrouwen. Dit kan bijvoorbeeld tussen bedrijven onderling met een eigen mailserver zijn, waarop alleen maar toegang is tot echte mensen, en er sowieso een lagere kans is op misbruik. Ook als er een interne mail gestuurd wordt dan is er geen nood aan verificatie, omdat de persoon in hetzelfde bedrijf zit.

Communicatie tussen computer en mens

Naast communicatie tussen 2 personen onderling is er ook nog communicatie tussen computer en personen. Mogelijkheden hiervan zijn nieuwsbrieven, notificaties op nieuwe berichten. Een oplossing waarbij niemand handmatig een captcha moet intikken voor elk automatisch gestuurd bericht is door eerst een afspraak te maken tussen de persoon en de automatische dienst, door middel van een token. Dit werkt als volgt.

Als persoon A zich registreert op website B en zijn e-mailadres intikt dan moet hij zijn e-mailadres goedkeuren, dit doet hij door naar zijn e-mailclient te gaan en een eenmalige code (een token) te genereren. Die code tikt hij tijdens de registratie in. Die code maakt het voor website B mogelijk om 2 zaken te doen: bewijzen dat de persoon die het e-mailadres ingetikt heeft de eigenaar is, en om zichzelf als betrouwbaar te geven (niet als menselijk). Neem het volgende als voorbeeld:

Persoon A tikt de code in website B, samen met zijn e-mailadres, in. Website B stuurt een request naar mailserver A met de code en het e-mailadres. Mailserver A verifieërt dat de code bij e-mailadres A hoort. Als dat zo is, dan wordt er een sleutel gegenereerd waarmee website B zich kan identificeren als vertrouwelijk. Hij kan zich niet identificeren als menselijk! Die sleutel wordt vervolgens door website B alle keren gebruikt als er een e-mail gestuurd moet worden. Persoon A kan op elk moment die sleutel opnieuw intrekken als er misbruik plaatsvindt.

Het token maakt het voor de website mogelijk om zijn eigen keys als “goedgekeurd” te laten zien. De token is uniek voor elke website. In het protocol waarbij een website en een mailserver met elkaar kunnen praten, zou het mogelijk moeten kunnen zijn om na te kijken of een bepaalde key dezelfde is als degene die reeds bekend is. Als dat niet zo is, dan gebruikt een gebruiker een bepaalde token voor 2 verschillende websites, en zou de tweede website een melding kunnen geven dat de token al gebruikt is.

De token maakt het ook mogelijk om keys te updaten, mocht een website deze veranderen.

De token kan ook een label gegeven worden.

Communcatie van mens naar computer

Communicatie van persoon naar computer gaat eigenlijk analoog als van persoon naar persoon. Hij lost een captcha of (of maakt gebruik van een andere manier om zich menselijk te tonen, analoog als tussen 2 personen) om een bericht te sturen.

Omdat captchas in sommige omstandigheden de productiviteit kunnen verlagen, zouden ze bijvoorbeeld ook omzeild kunnen worden als het op dezelfde mailserver is (dit kan bijvoorbeeld wel niet op publieke/openbare mailservers), of als 2 mailservers (bijvoorbeeld van 2 bedrijven die samenwerken) elkaar volledig vertrouwen. Dat betekent dat beide mailservers garanderen dat ze alleen maar menselijke gebruikers hebben, of elkaar verdragen als het over geautomatiseerde e-mails gaat.

Probleem: Analoog registreren

Een van de problemen die dit systeem heeft, als al de rest veilig geïmplementeerd is, het achterlaten van je e-mailadres in een hotel of een broodjeszaak. Ofwel het analoog registreren op een mailinglijst. De eerste keer dat dit bedrijf je een nieuwsbrief stuurt, zou de verstuurder voor elke nieuwe ontvanger opnieuw een Captcha moeten intikken. Een mogelijkheid zou zijn dat Captchas op voorhand uitgewisseld kunnen worden. Met andere woorden: er is een mogelijkheid om een lege e-mail te sturen die niet in de inbox geraakt, maar waarmee wel de verzender (het bedrijf) als vertrouwd gegeven wordt. Dit werkt dan zonder token.

Dit heeft natuurlijk als gevolg dat er misbruik gemaakt kan worden, omdat dit ook door spammers gebruikt kan worden (als iemand de Captcha kan oplossen). Je digitaal inschrijven heeft als voordeel dat je je onmiddellijk een token hebt waarmee je zelf goedkeuring kan geven om iemand toestemming te geven.

Gevolg: Analoog registreren wordt moeilijk, tenzij de token ook analoog opgeschreven kan worden. Wanneer iemand het analoge formulier digitaliseert, dan geeft die persoon het token mee. Die token kan onmiddellijk gebruikt worden, of pas bij het volgende bericht, om het bericht als “toegelaten” te markeren.

Kort samengevat

Kort samengevat zijn de volgende wijzigingen nodig om iets zoals dit te realiseren:

  • Servers moeten elkaar kunnen vertrouwen om een overload aan captchas te negeren. Dit kan zelfs met publieke/openbare mailservers onderling, zolang ze elkaars captchas vertrouwen.
  • Bij het sturen van een e-mail moet er een captcha gestuurd worden, alvorens de e-mail als “ontvangen” gemarkeerd kan worden.
  • Een captcha kan omzeild worden door op voorhand een oplossing door te sturen (kan eenmalig gebruikt worden).
  • Een captcha kan omzeild worden als 2 gebruikers elkaar al vertrouwen door middel van een keypair.
  • Een captcha kan omzeild worden als 2 mailservers elkaar ten volle vertrouwen.
  • Om legitieme automatische berichten toe te staan wordt er gebruik gemaakt van keypairs om berichten te blijven sturen (vertrouwen), een token wordt gegenereerd door de gebruiker om identificatie en om keypair toe te voegen.

Er zijn dus 2 mogelijkheden waarop servers elkaar vertrouwen:

  • Vertrouwen op captchas: een server vertrouwt een andere server, als de andere server betrouwbare captchas kan genereren
  • Vertrouwen in gebruikers: een server kan een andere server volledig vertrouwen, als we geloven dat alleen maar echte mensen legitiem van de server gebruik maken, geen geautomatiseerde bots

Captchas zijn een manier om op terug te vallen, de voornaamste manieren om te weten dat e-mails van een menselijke actor komen, of van een toegelaten systeem, is door gebruik te maken van keypairs voor te signeren. Als zoiets niet bereikbaar is, dan moet er teruggevallen worden op captchas.

Om gebruikersgemak te bewaren moet er gebruik gemaakt worden van bepaalde sleutels. Wie betaalt met gebruikersgemak betaalt vaak met veiligheid, dus is het belangrijk om te zien welke veiligheid we verliezen als een sleutel verloren gaat, of misbruikt wordt. In dat geval kan er toch nog spam aankomen. Maar een sleutel kan, ongeacht of het van een persoon afkomstig is, of van een automatisch systeem, ook als niet-menselijk aangeduid worden. In dat geval is er terug een captcha nodig, of moet een website bij het volgende bezoek een melding geven dat een vorige e-mail niet gestuurd kon worden, omdat de sleutel niet meer geldig is, in dat geval moet er terug een token gegenereerd worden.

Het is belangrijk dat deze sleutels niet verplicht gebruikt moeten worden voor encryptie, en alleen gebruikt mogen worden om aan te tonen dat de afzender menselijk is, of goedgekeurd automatisch. Deze sleutels dienen niet als encryptiemechanisme om berichten versleuteld te hebben. Dezelfde sleutel zou hiervoor theoretisch mogelijk zijn, maar dit vereist sterkere beveiliging, omdat bij het verliezen van een sleutel er vervolgens meer afhankelijk is dan alleen maar verificatie of een e-mail door een mens gestuurd is of niet.

Betrouwbaarheid en haalbaarheid

Ik vermoed dat deze oplossing 99.9% van alle geautomatiseerde spam kan tegenhouden, zonder gebruik te maken van filters. Het is ook beter dan black- en whitelisten, omdat ze niet handmatig geüpdate moet worden (en eigenlijk een vereenvoudigde vorm zijn van een filter).

Het is ook beter dan alleen maar geëncrypteerde e-mail ontvangen. Omdat je publieke key publiek is kan iedereen je nog spam sturen. Als je alleen maar geëncrypteerde e-mail wil ontvangen van mensen die je vertrouwt en hun mails signeren, dan ben je even veilig. Maar dit is niet voor iedereen technologisch weggelegd om een keypair te generen om een e-mail te sturen. Een Captcha kan iedereen oplossen, en vanaf dan wordt er voor die specifieke communicatie tussen de 2 partijen een aparte sleutel gegenereerd.

De enige zwakke plaats is als het aantal captchas verminderd wordt als servers elkaar captchas vertrouwen. Semi-automatische spam zou nog steeds mogelijk zijn als er maar een handvol captchas opgelost moeten worden.

Het enige negatieve aan het verhaal is dat e-mail al goed ingeburgerd is, en deze manier van aan e-mail doen zou alleen mogelijk als er een geheel nieuw e-mailprotocol zou ontstaan (dat eventueel gebouwd wordt boven het bestaande protocol). Het is niet mogelijk om de twee systemen zij aan zij te laten werken (in de vorm van een klassieke mailserver die naar deze mail van mail sturen een bericht stuurd en vice versa), maar wat in de realiteit wel mogelijk zou kunnen zijn is dat 1 inbox beide manieren kan ondersteunen. Een klassieke mailserver zoals die nu al bestaat, en een eentje die gebruik maakt van keys en captchas voor zeker te zijn dat het door een persoon ingevuld is. Dit betekent dat deze technologie op een manier verenigbaar is met bestaande technologie, omdat alleen maar het transportprotocol veranderd. Het dient als een abstractielaag bovenop public key cryptography wat zeer omslachtig is.

Beveiligen van Captchas

Een ander probleem, wat sowieso standaard een probleem van Captchas is, is dat een Captcha ook opgelost kan worden door een persoon, en het antwoord vervolgens misbruikt kan worden door een geautomatiseerde spammer. Neem het volgende als voorbeeld.

Spambot A wil een bericht plaatsen op website B. Website B genereert een Captcha. Spambot A kan deze niet zelf oplossen en stuurt deze Captcha door naar een rogue website C. Rogue website C ziet er voor gebruikers uit als een legitieme website. Een gebruiker D wilt graag een account aanmaken op deze website en moet een Captcha invullen om te bewijzen dat hij geen Spambot is. Gebruiker D lost de captcha op die website B heeft aangeleverd. Spambot A ontvangt via Rogue website C het mogelijke antwoord, stuurt het antwoord naar website B, website B reageert om te zeggen dat het antwoord correct is. Als het antwoord correct is reageert spambot A naar Rogue website C om te zeggen dat de Captcha correct was, dus gebruiker D kan zijn account aanmaken op website C.

Zoiets is in de praktijk momenteel al mogelijk, maar heb ik nog nooit zien toegepast worden op grote schaal. Een eenvoudig haalbare oplossing is door timeouts af te dwingen (dit gebeurt in de praktijk al). Maar minimaliseert het probleem alleen maar.

Glossary

  • Black- en whitelist: Een lijst waarbij voor elke gebruiker op een mailserver een lijst aanwezig is van e-mailadressen die vertrouwd zijn, en helemaal niet toegelaten. E-mailadressen die op geen enkele lijst staan worden door een spamfilter gelaten, op de zwarte lijst worden automatisch genegeerd en op een witte lijst worden automatisch doorgelaten.
  • CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart: een manier hoe een computer zelf een test kan generen waarbij een onbekende gebruiker (een computer of een persoon) moet bewijzen dat hij deze kan oplossen. Een captcha is een goede Captcha als alleen een mens dit kan doen.
  • Geautomatiseerde spam: Spam die volledig geautomatiseerd gestuurd wordt.
  • Handshake: Een token (zie Token) die eenmalig gebruikt wordt voor 1 enkel bericht goed te keuren.
  • Mailserver: Een server die verantwoordelijk is voor het versturen en ontvangen van e-mail, dit moet niet noodzakelijk een reeds bestaande implementatie van een mailserver zijn.
  • Public Key Crytography: Een bestaande manier hoe 2 personen veilig e-mails naar elkaar kunnen sturen door middel van een publieke en een private sleutel, deze kan gebruikt worden voor encryptie, alsook voor het digitaal ondertekenen van berichten.
  • Rogue: Gebruik ik hier als kwaadaardig, met slechte bedoelingen.
  • Semi-geautomatiseerde spam: Spam die door door een slechtwillende gebruiker handmatig naar veel ontvangers gestuurd wordt
  • SPAM of Spam: Beter bekend als Junk mail of ongewenste berichten.
  • Token: Een unieke random gegenereerde string van characters die gebruikt kan worden om allerlei doeleinden.

Reacties op "Hoe kan je geautomatiseerde e-mails uit je inbox weghouden door middel van Captchas, public key signing en wat APIs"

Bjarno:

Note to self: Wat ik misschien nog wel moet doen in dit artikel is diagrammen erbij plaatsen, maakt het begrijpen ervan misschien iets belangrijker in plaats van al die A's, B's en C's...

Luc:

"[na Gmail] heb ik van 1 ding enorm veel meer last gekregen. SPAM."

Probleem bij Gmail is dat je niet weet dat je last hebt van spam. Ooit geprobeerd met een random IP-adres e-mail te sturen naar een gmail adres? Of naar een bedrijf dat gmail gebruikt met een custom domein? In een goed geval kom je in de spambox, waar nooit iemand kijkt omdat Google het goed verbergt. Heel veel mensen weten niet dat Gmail überhaupt een spambox heeft. In een slecht geval (in te stellen in google apps voor business of zoiets, met zo'n custom domein) wordt het volledig geweigerd door de mail server. Door hun bijna monopolie kunnen ze hiermee wegkomen, want het kan toch zeker niet Google's fout zijn als jij een e-mail vanaf een eigen server stuurt en het niet werkt?

Hierbij moet gezegd worden dat gmail waarschijnlijk het beste spamfilter in de wereld heeft. Dit komt doordat ze een gigantische dataset hebben (maakt het best makkelijk) en doordat ze een paar false positives (gegenereerd door hippies met eigen mail servers) geen probleem vinden. Vervolgens zijn ze niet helemaal duidelijk over de mogelijkheid van false positives en worden de kleinere spelers uit de markt gedrukt. Maargoed, als gewoon persoon met gewone vrienden heb je hier vrij weinig last van.

Laat een reactie achter

Naam: Bericht: Bewijs dat je geen robot bent: