Hoe omzeilt een spammer een anti-spam vraag?

[Tweaker36]

@ Mods: ik zet het even hier, omdat ik niet echt weet waar het net hoort. Mijn excuses als het verkeerd staat... Ik weet het, het is niet client-side, maar toch ook geen programming? Waar hoort dit?

Sinds zeer kort kreeg ik via het contact formulier op een van mijn websites spamberichten. Viagra enzo. Boeiende stuff. Zo boeiend, dat die berichten op zeer regelmatige basis kwamen (om de 3 uur en 10 min).

Dat begon zo na een dag of 2 te irriteren, en dus heb ik mijn contact formulier aangepast. Ik heb onderaan het contact formulier het volgende toegevoegd: "1 + 1 = *tekstvakje*", waarbij ik logischerwijs een "2" in het tekstvak verwacht. Ik heb het getest (niks invullen, iets anders dan 2 invullen, 2 invullen) en gaf in elk geval het gewenste resultaat (resp. niet verzenden, niet verzenden, verzenden ).

Ik gerust. Maar ondanks dat, 3u 10min na de vorige spammail, kwam de volgende binnen.
De "2" was dus succesvol ingevuld! (want het werkte foutvrij)

Ik heb inmiddels de vraag veranderd naar "De vijfde letter van het alfabet is: *textvakje*", en dat schijnt dus wel te helpen. De spammer zijn Nederlandse taal skills zijn dus niet denderend.

Nu vraag ik mij enkel af: hoe heeft die spammer dat correct ingevuld?

* Handmatig? Lijkt zo onslachtig / onlogisch...
* OCR technieken, om ook bvb een CAPTCHA te kunnen omzeilen?
* Random input (soort 'brute-force' dus )?
* Gokken (mijn vraag is zo courant)?

Wie is er hierin thuis, en kan me dat vertellen?

[HyperioN]

Tweaker36 schreef op vrijdag 04 september 2009 @ 23:06:
@ Mods: ik zet het even hier, omdat ik niet echt weet waar het net hoort. Mijn excuses als het verkeerd staat...


* Handmatig? Lijkt zo onslachtig / onlogisch...
* OCR technieken, om ook bvb een CAPTCHA te kunnen omzeilen?
* Random input (soort 'brute-force' dus )?
* Gokken (mijn vraag is zo courant)?

Jep, alle van de hierboven door jezelf genoemde antwoorden!

Tekst kunnen ze vaak al lezen; rekensommetjes begrijpen ze ook. Maar naar het schijnt worden nu zelfs mensen ingezet om captcha's in te typen in een database.
Toevallig werd vanmiddag een topic hierover gekickt:
Hoe test je een zelfgemaakte Captcha? *

pim schreef op vrijdag 04 september 2009 @ 13:40:
* kick *

Ondertussen is het me duidelijk geworden dat _elke_ captcha gekraakt kan worden, want het overtypen gebeurd door mensen in India China, voor +/- $5 voor 1000 captcha's..
Eerst probeert een BOT het, lukt dat niet, dan gaat word het door mensen gedaan.
Er is een API voor op: decaptcher.com en beatcaptchas.com

Het kat&muis spelletje is tot zover dus gewonnen door de spammers..

[mithras]

Je moet ook niet meer captcha's gebruiken tegenwoordig. Überhaupt forms waar je als gebruiker meer voor moet doen dan nodig moet je niet meer gebruiken. Alles wat je als human kan invullen kan ook door bots.

Captcha's en rekensommetjes kunnen inderdaad al automatisch, maar algemene kennis vragen zullen er ook wel komen. Zeker als je website belangrijk genoeg is komen ze met geautomatiseerde berichten er nog steeds doorheen.

[Tweaker36]

Bedankt voor jullie berichten!

@ HyperioN:
Toch? Had niet gedacht dat het echt zo 'erg' (geavanceerd) zou zijn.
Als er zelf mensen aan gezet worden (kinderarbeid?), dan wordt het wel erg moeilijk. Klassieke Captcha's zijn dan ook niet meer voldoende...

@mithras:
Nee, dat is waar. Door grotere / moeilijkere beveiliging jaag je alleen je echte klanten weg, natuurlijk..


Wat zijn dan nog goede oplossingen?
* Vragen in je eigen taal, als die niet een veelgesproken taal is, weliswaar. (zoals nu op mijn site)
* Beter nog: verschillende vragen, random 1 uit weergeven
-> nog ideeën? Het gelinkte topic dus.

[Gomez12]

Uberhaupt altijd verschillende vragen gebruiken en een redelijk bak vragen hebben die niet standaard zijn, Standaard rekensommetjes ( numeriek of textueel ) zijn ondertussen gewoon onderdeel van de spambots geworden.

Dus iets echt origineels bedenken of gewoon een standaard iets als recaptcha ( wat redelijk werkt ).

Het probleem met texuele vragen etc is dat om het niet te gebruikersonvriendelijk te maken je algemene vragen moet gebruiken, de meeste algemene vragen zijn al eens eerder op grotere spamtargets geprobeerd en daardoor onderdeel van de spambot geworden...

[Verwijderd]

CSA>WEB

[Tweaker36]

In het geval van de site waar ik het over heb, is het vrij eenvoudig. De doelgroep is enkel de Benelux, en de enige taal is dus Nederlands. Kan je eenvoudig een NL vraag stellen, zoals ik nu gedaan heb.
Heb ook een andere site, met een internationaal publiek en dus Engelstalig. Daar gaat dat minder eenvoudig...

Een goede tip, aangehaald in het hiervoor gelinkte topic, is om een veld aan je formulier toe te voegen, dat verplicht leeg moet blijven. Je verbergt dit veld met externe css. Je zet er eventueel nog een *Required bij, eveneens verborgen. Mensen zien het niet en vullen het dus niet is, spambots vullen het in, uit schrik een verplicht veld te missen.

Zowat alle andere dingen schijnen "gehackt" te worden. Lees het topic verder vanaf hier:
pim in "Hoe test je een zelfgemaakte Captcha? *"

Verwijderd schreef op zaterdag 05 september 2009 @ 00:00:
CSA>WEB

Dankje.

[ Voor 7% gewijzigd door Tweaker36 op 05-09-2009 00:03 ]

[Gomez12]

Tweaker36 schreef op zaterdag 05 september 2009 @ 00:01:
Een goede tip, aangehaald in het hiervoor gelinkte topic, is om een veld aan je formulier toe te voegen, dat verplicht leeg moet blijven. Je verbergt dit veld met externe css. Je zet er eventueel nog een *Required bij, eveneens verborgen. Mensen zien het niet en vullen het dus niet is, spambots vullen het in, uit schrik een verplicht veld te missen.

Als je site groot genoeg is om boven de simpelste spambots uit te stijgen dan is deze ook al gehackt.

Niet al te simpele spambots doen tegenwoordig periodiek een verkenningsrun met een fullblown browser en kijken daarmee welke velden de gebruiker wel/niet kan/moet invullen, hiermee maken ze ongeveer 99% van de JS / CSS trucjes ongedaan.

[EnderQ]

Verander de invoer in plaats van een patroon als letters en of cijfers in een veld invoeren, maak draaischijven of sliders die je grafisch met muis moet bedienen. (captcha de invoerwijze)

[HyperioN]

EnderQ schreef op zaterdag 05 september 2009 @ 00:42:
Verander de invoer in plaats van een patroon als letters en of cijfers in een veld invoeren, maak draaischijven of sliders die je grafisch met muis moet bedienen. (captcha de invoerwijze)

Tsja, hoe ver wil je gaan. Ik vind dat al behoorlijk gebruikersonvriendelijk worden eerlijk gezegd.
Bovendien zou je dat dan in Flash of zo moeten gaan ontwikkelen wat weer een hoop problemen kan opleveren voor mobiel gebruik, blinden (braille-readers) etc..

[_Thanatos_]

Dat rekensommetje is best een goeie, maar ik zou er twee dingen aan veranderen:
1) Maak het random, maar houd het toch simpel genoeg voor je bezoeker zodat je em niet lastigvalt. Alleen als je publiek kleine kinderen is, moet je een rekensom natuurlijk sowieso niet doen
2) Schrijf het sommetje als woorden op. Bijvoorbeeld "wat is twee plus drie". In dit voorbeeld zouden "5" en "vijf" dus valide moeten zijn. Het is hiermee dus handig om het onder de tien ofzo te houden.

Daarnaast zou je ook een "Laat dit veld leeg: [input]" kunnen toevoegen, om spammers te weren die junk in een veld invullen waarvan ze niet weten wat ze ermee moeten. Je zou dit veld dan nog kunnen hiden met visibility:hidden (niet display:none omdat ie dan niet meer gepost wordt) of door em uit beeld te positioneren (bijv position:absolute;left:-9999px).

Tot slot de names van de input-tags van je captcha randomizen per sessie, zodat een spammer die veldnamen onthoudt, elke keer een nieuw soort veld denkt te krijgen.

[Zakkenwasser]

Bij de vorige website van mij liet ik het nog toe dat mensen zonder account op min blogs konden reageren.

En toen begon op een avond de spam ellende.
Een bot stuurde een BBcode test naar al mijn blog entries, waarop de volgende dag het echte spammen begon.

Nu moeten mensen zich eerst registreren.
En ik check ook op bestaande email adressen bij registratie, dus ik verwacht dat dit een extra drempel moet wezen voor de spammers.

Maarjah, het komt alleen omdat de wereld op geld loopt.
Anders had het geen plezier geweest om spammer te zijn.

[ Voor 11% gewijzigd door Zakkenwasser op 05-09-2009 07:51 ]

[mithras]

Tweaker36 schreef op vrijdag 04 september 2009 @ 23:26:
@mithras:
Nee, dat is waar. Door grotere / moeilijkere beveiliging jaag je alleen je echte klanten weg, natuurlijk..


Wat zijn dan nog goede oplossingen?
* Vragen in je eigen taal, als die niet een veelgesproken taal is, weliswaar. (zoals nu op mijn site)
* Beter nog: verschillende vragen, random 1 uit weergeven
-> nog ideeën? Het gelinkte topic dus.

Avoid spam messages without additional user input

Tweaker36 schreef op zaterdag 05 september 2009 @ 00:01:
Een goede tip, aangehaald in het hiervoor gelinkte topic, is om een veld aan je formulier toe te voegen, dat verplicht leeg moet blijven. Je verbergt dit veld met externe css. Je zet er eventueel nog een *Required bij, eveneens verborgen. Mensen zien het niet en vullen het dus niet is, spambots vullen het in, uit schrik een verplicht veld te missen.

Dat is inderdaad de truuk. Het werkt volgens mij beter dan captcha's en andere invoer velden.

Gomez12 schreef op zaterdag 05 september 2009 @ 00:24:
[...]

Als je site groot genoeg is om boven de simpelste spambots uit te stijgen dan is deze ook al gehackt.

Niet al te simpele spambots doen tegenwoordig periodiek een verkenningsrun met een fullblown browser en kijken daarmee welke velden de gebruiker wel/niet kan/moet invullen, hiermee maken ze ongeveer 99% van de JS / CSS trucjes ongedaan.

De standaard display: hidden in het element zetten is natuurlijk wel heel erg makkelijk. Maar in mijn blogpost staat een wat geavanceerdere methode waarbij je zonder render engine er eigenlijk niet meer achter kan komen.

Zeker met css verschuivingen (grote of negatieve margins) in plaats van het veld op hidden zetten, moet je helemaal een css2.1 compatible bot hebben. En dat is afaik iets wat minder voorkomt dan de bots die de onmogelijke captcha's kunnen lezen

[Wilf]

Misschien denk ik iets te naiëf maar als je een naamveld "email" en een e-mailveld "name" geeft als naam, ID of class, zal de bot dan niet denken dat er een e-mailadres in het naamveld moet, wat je vervolgens met PHP eruit filtert?

Voorbeeld:

code:

Voer in de onderste velden uw e-mail adres (onderste veld) en uw naam (bovenste veld):

<input type="text" name="email" />

<input type="text" name="name" />

Het lijkt mij dat de geautomatiseerde bots namelijk ook zoeken naar de naam, ID of class van een invoerveld om te kijken welke input gewenst is, en dus nu in het eerste veld een @ en een . plaatsen waar dat niet mag en andersom in het name-veld géén valide e-mailadres.

Aan de andere kant: met brute force op elk veld een oneindige combinatie van verschillende input bombarderen houdt zo'n trucje ook niet tegen, maar dat geldt ook voor het blinde invoerveld (oneindige combinatie van input met af en toe een lege regel).

[sub0kelvin]

Om commentspam te voorkomen kun je er ook voor kiezen om niet alleen te kijken of de gebruiker een spambot is, ook kun je de inhoud van het bericht controleren op spam. Zoals bij spamfilters op je e-mail. En als je die contentscan voor de gebruikersscan doet, kun je heel veel normale gebruikers ontzien doordat ze in de eerste instantie nog geen captcha of andere vervelende dingen hoeven in te vullen.

Ikzelf gebruik daarvoor Mollom (www.mollom.com). Doordat ze een centrale functie hebben en veel data krijgen om te verwerken kunnen ze ook heel veel leren van die data, zeker als de gebruikers feedback geven als Mollom een fout maakt. Gecombineerd met de sterke reCaptcha is het voor spammers heel moeilijk om hun boodschap over te brengen. Ook voor de intelligente spambot die de CSS-truukjes, sommetjes en dergelijke probleemloos omzeilen aangezien hun content nog steeds spamachtig is.

Bij mijn websites heb ik hiermee zelfs een 100% score (geen enkele false hits of misses), terwijl ik eerst overspoeld werd met commentspam. En ik heb tot dusver nog geen klachten gehad van mensen die volledig tegengehouden werden; alle twijfelgevallen kregen braaf een reCaptcha.

[Tweaker36]

Wow, al een aantal leuke ideeën, zo te zien.

Sliders etc, vind ik niet echt praktisch, maar zouden de Chineesjes dat ook niet kunnen?

Tekstvakje verbergen, lijkt me nog steeds simpel en vrij effectief.
Verder alles random... Dat lijkt mij dus zo inefficiënt voor je echte bezoekers. De standaard, vertrouwde volgorde, lijkt me een betere uitstraling te hebben dan elke keer een andere volgorde...

MrJey schreef op zaterdag 05 september 2009 @ 07:50:
Maarjah, het komt alleen omdat de wereld op geld loopt.
Anders had het geen plezier geweest om spammer te zijn.

Dat is waar. Ik blijf me erin verbazen hoeveel geld er wel niet in deze duistere wereld moet omgaan, dat dit allemaal rendabel blijft. Welke idioten kopen er via spam?!

Wilf schreef op zaterdag 05 september 2009 @ 10:07:
Het lijkt mij dat de geautomatiseerde bots namelijk ook zoeken naar de naam, ID of class van een invoerveld om te kijken welke input gewenst is, en dus nu in het eerste veld een @ en een . plaatsen waar dat niet mag en andersom in het name-veld géén valide e-mailadres.

Ja, allicht wel... Maar hou je code voor jezelf maar overzichtelijk, als je allemaal andere (random?) benamingen gaat moeten gebruiken...

sub0kelvin schreef op zaterdag 05 september 2009 @ 10:40:
Om commentspam te voorkomen kun je er ook voor kiezen om niet alleen te kijken of de gebruiker een spambot is, ook kun je de inhoud van het bericht controleren op spam. Zoals bij spamfilters op je e-mail. En als je die contentscan voor de gebruikersscan doet, kun je heel veel normale gebruikers ontzien doordat ze in de eerste instantie nog geen captcha of andere vervelende dingen hoeven in te vullen.

Ikzelf gebruik daarvoor Mollom (www.mollom.com).

Bedankt voor de tip. Het idee klink idd goed. Ga ik een bekijken.

[HyperioN]

sub0kelvin schreef op zaterdag 05 september 2009 @ 10:40:
Om commentspam te voorkomen kun je er ook voor kiezen om niet alleen te kijken of de gebruiker een spambot is, ook kun je de inhoud van het bericht controleren op spam. Zoals bij spamfilters op je e-mail. En als je die contentscan voor de gebruikersscan doet, kun je heel veel normale gebruikers ontzien doordat ze in de eerste instantie nog geen captcha of andere vervelende dingen hoeven in te vullen.

Ikzelf gebruik daarvoor Mollom (www.mollom.com). Doordat ze een centrale functie hebben en veel data krijgen om te verwerken kunnen ze ook heel veel leren van die data, zeker als de gebruikers feedback geven als Mollom een fout maakt. Gecombineerd met de sterke reCaptcha is het voor spammers heel moeilijk om hun boodschap over te brengen. Ook voor de intelligente spambot die de CSS-truukjes, sommetjes en dergelijke probleemloos omzeilen aangezien hun content nog steeds spamachtig is.

Bij mijn websites heb ik hiermee zelfs een 100% score (geen enkele false hits of misses), terwijl ik eerst overspoeld werd met commentspam. En ik heb tot dusver nog geen klachten gehad van mensen die volledig tegengehouden werden; alle twijfelgevallen kregen braaf een reCaptcha.

Thnx voor de tip!
Ik snap reCaptcha echter niet echt..
Ze kunnen de tekst niet digitaal "lezen", hoe voeren ze dan de check uit en weten ze of de user de juiste input geeft??

/edit: http://recaptcha.net/learnmore.html
Het blijkt dat hij ook "foute" input accepteert als je er enigszins langszit; een "a" die lijkt op een "o" wordt ook geaccepteerd, etc.. Maar verwacht niet dat een bot er zo dichtbij zal zitten maar het kan op den duur weer voor gaan komen lijkt me.

[ Voor 9% gewijzigd door HyperioN op 05-09-2009 12:13 ]

[sub0kelvin]

Volgens mij is 1 woord wel bekend en 1 woord niet. De spamcheck zit dus op dat woord dat ze al kennen, nieuwe woorden leren doen ze met het andere woord.
----
@edit hierboven: aha, duidelijk, een beetje van beide dus.

[ Voor 17% gewijzigd door sub0kelvin op 05-09-2009 12:16 ]

[Onbekend]

Tweaker36 schreef op zaterdag 05 september 2009 @ 11:13:
Dat is waar. Ik blijf me erin verbazen hoeveel geld er wel niet in deze duistere wereld moet omgaan, dat dit allemaal rendabel blijft. Welke idioten kopen er via spam?!

Gewoon normale mensen die niet echt verder denken dan hun beeldscherm. Als je mensen maar lang genoeg overspoeld met de zelfde reclame, gaan ze er uiteindelijk over nadenken.

Stel dat er naar 1 miljoen e-mailadressen een spam-bericht wordt verzonden.
Van de 1 miljoen ontvangers hebben 0,05% interesse in de reclame (viagra, medicijnen, sieraden e.d.).
Van de geïnteresseerden gaan 5% over tot aankoop van het product.

Dus 0,05% van 1 miljoen = 500 mensen -> 5% van 500 = 25 mensen die daadwerkelijk het product aanschaffen.
Aardig effectief dus, terwijl het versturen van een spam-bericht bijna niets kost.

(Overigens heb ik geen exacte cijfers, maar ik volgens mij liggen ze wel iets in deze buurt.)

[HyperioN]

Onbekend schreef op zaterdag 05 september 2009 @ 12:25:
[...]

Gewoon normale mensen die niet echt verder denken dan hun beeldscherm. Als je mensen maar lang genoeg overspoeld met de zelfde reclame, gaan ze er uiteindelijk over nadenken.

Stel dat er naar 1 miljoen e-mailadressen een spam-bericht wordt verzonden.
Van de 1 miljoen ontvangers hebben 0,05% interesse in de reclame (viagra, medicijnen, sieraden e.d.).
Van de geïnteresseerden gaan 5% over tot aankoop van het product.

Dus 0,05% van 1 miljoen = 500 mensen -> 5% van 500 = 25 mensen die daadwerkelijk het product aanschaffen.
Aardig effectief dus, terwijl het versturen van een spam-bericht bijna niets kost.

(Overigens heb ik geen exacte cijfers, maar ik volgens mij liggen ze wel iets in deze buurt.)

Precies.. van de 10 miljoen spammailtjes die je verstuurd hoeft maar één persoon tot aankoop over te gaan en je hebt het er al uit..

[Gomez12]

Onbekend schreef op zaterdag 05 september 2009 @ 12:25:
[...]
Dus 0,05% van 1 miljoen = 500 mensen -> 5% van 500 = 25 mensen die daadwerkelijk het product aanschaffen.
Aardig effectief dus, terwijl het versturen van een spam-bericht bijna niets kost.

Tja, dit is ook gelijk de denkwijze om een spamfilter te ontwikkelen, ze kunnen chinezen inzetten om captcha's te achterhalen, maar dat doet de kosten onnoemelijk hard stijgen.

Kijk bij een gmail / hotmail captcha is de winst zo groot als je dbase "compleet" is dat ze daar wel voor willen betalen, maar 1000 captcha's handmatig kraken op een website met 1000 bezoekers zal imho niet zo snel gebeuren.
Als je dan weer een standaard captcha script pakt wat op nog 100.000 andere sites draait dan kan het wel weer interessant zijn om de captcha's handmatig te kraken...

Het enige nadeel is dat het laten kraken van captcha's supersimpel is en goedkoop kan ( sla een boel captcha's van 1 site op, zet een gratis porn site op en toon daarbij deze captcha's, je bezoekers kraken gratis en voor niets jouw captcha's )

[T-MOB]

Volgens mij is het hoofddoel van commentspam het creeren van links naar een website om hoog in de zoekmachines te eindigen. Wat ik zelf trouwens toepas is een simpele contentscan op de aanwezigheid van html en/of ubb-links. Daarnaast gebruik ik een time-window. Een formulier wordt alleen verwerkt als minimaal 10 seconden en maximaal 2 uur na het renderen van het formulier wordt verstuurd.

[Janoz]

Gebruik gewoon reCaptcha. Naast dat het handig is om dergelijke onderdelen te laten implementeren door mensen die er hun core business van maken, worden de resultaten ook nog eens nuttig gebruikt en helpen je gebruikers dus mee met het digitaliseren van boeken.

[Spinal]

@T-MOB: werkt dat bij jou? Ik heb na tips hier op GoT ingevoerd op een stel weblogs, maar het werkte voor geen meter. Er kwam nog net zo veel spam als daarvoor.

[Gomez12]

T-MOB schreef op zaterdag 05 september 2009 @ 13:15:
Volgens mij is het hoofddoel van commentspam het creeren van links naar een website om hoog in de zoekmachines te eindigen. Wat ik zelf trouwens toepas is een simpele contentscan op de aanwezigheid van html en/of ubb-links. Daarnaast gebruik ik een time-window. Een formulier wordt alleen verwerkt als minimaal 10 seconden en maximaal 2 uur na het renderen van het formulier wordt verstuurd.

Ach, simpele reclame / naamsbekendheid wordt ook vaak toegepast hoor...
Sinds google de nolinks respecteert hanteren steeds meer sites / blogs / fora dit voor de comments waardoor het linkspamming al grotendeels nutteloos is geworden.

Time-windows zijn leuk, maar verhinderen weer een andere soort gebruiker ( ik heb wel eens op een board voor dyslectici gezeten waar iedereen de reply's in word maakte vanwege spellingscontrole / grammaticacontrole etc en dan een reply in 1 sec plaatste )
Dat is ook gelijk het probleem met anti-spam maatregelen, afhankelijk van je doelgroep kan je er gebruikers tussen hebben zitten die minder snappen dan bots...

@ZanderZ : Vziw werkt het redelijk mits goed uitgevoerd. Enkel een simpele timestamp controleren bij posten is al lang ingebouwd in elke bot. Server side een timestamp opslaan en bij binnenkomst post de binnengekomen ( fatsoenlijk gecodeerde timestamp ) vergelijken met de dbase timestamp en dan server-side het verschil in tijd meten schijnt redelijk te werken...

[ Voor 20% gewijzigd door Gomez12 op 05-09-2009 14:53 ]

[r0b]

Janoz schreef op zaterdag 05 september 2009 @ 13:22:
Gebruik gewoon reCaptcha. Naast dat het handig is om dergelijke onderdelen te laten implementeren door mensen die er hun core business van maken, worden de resultaten ook nog eens nuttig gebruikt en helpen je gebruikers dus mee met het digitaliseren van boeken.

Ja, als je de usability van je website te grabbel wilt gooien.
Ik krijg zelf al steeds meer problemen met het juist intikken van (re)Captcha's, laat staan mijn bezoekers.

Sliders zouden in dat geval - voor normaal gebruik - misschien nog een idee zijn (of een list met het juiste antwoord; "wat is twee keer vijf" - list "twee, tien, zeven, twaalf")

offtopic:
Ik wist niet dat de resultaten van reCaptcha ook daadwerkelijk gebruikt werden; dat is dan wel weer leuk

[ Voor 8% gewijzigd door r0b op 05-09-2009 14:53 ]

[T-MOB]

Gomez12 schreef op zaterdag 05 september 2009 @ 14:43:
Time-windows zijn leuk, maar verhinderen weer een andere soort gebruiker ( ik heb wel eens op een board voor dyslectici gezeten waar iedereen de reply's in word maakte vanwege spellingscontrole / grammaticacontrole etc en dan een reply in 1 sec plaatste )

Als je het spamfilter triggert dan krijg je een pagina voor je neus waarop uitgelegd wordt wat er aan de hand is. Je wordt dus niet aan je lot over gelaten (evt kun je daar zelfs nog een captcha-achtig ding doen om te verifieren dat je met een mens te maken hebt. Verder vind ik het grote voordeel dat je bij normaal gebruik nergens last van hebt. Dat is precies wat ik tegen captcha's heb: dat het normale gebruikers frustreert.

Timestamps checken werkt verder vrij goed, en het is zeer eenvoudig te implementeren. Elk formulier moet de timestamp en een checksum meesturen. Die checksum bestaat uit een hash van de timestamp plus een salt die alleen serverside bekend is.

[XWB]

Janoz schreef op zaterdag 05 september 2009 @ 13:22:
Gebruik gewoon reCaptcha. Naast dat het handig is om dergelijke onderdelen te laten implementeren door mensen die er hun core business van maken, worden de resultaten ook nog eens nuttig gebruikt en helpen je gebruikers dus mee met het digitaliseren van boeken.

Ook dat werkt niet honderd procent. Sinds de implementatie van reCaptcha is het aantal spambots hier met 70% afgenomen, maar niet volledig opgelost. En dat aantal zal in de toekomst wel opnieuw stijgen.

Verder weet ik niet tot hoever spambots met javascript kunnen omgaan. Indien niet, kan je het formulier via javascript (ajax) naar de server knallen.

[ Voor 10% gewijzigd door XWB op 05-09-2009 23:57 ]

[Gomez12]

Hacku schreef op zaterdag 05 september 2009 @ 23:53:
[...]
Verder weet ik niet tot hoever spambots met javascript kunnen omgaan. Indien niet, kan je het formulier via javascript (ajax) naar de server knallen.

Ga er maar rustig vanuit dat zo ongeveer alle spambots een beetje javascript kunnen...

Sowieso zit je met het probleem dat als iemand JS uit heeft staan (vb. noscript) dat je hem buitensluit...

[We Are Borg]

T-MOB schreef op zaterdag 05 september 2009 @ 15:55:
[...]

Als je het spamfilter triggert dan krijg je een pagina voor je neus waarop uitgelegd wordt wat er aan de hand is. Je wordt dus niet aan je lot over gelaten (evt kun je daar zelfs nog een captcha-achtig ding doen om te verifieren dat je met een mens te maken hebt. Verder vind ik het grote voordeel dat je bij normaal gebruik nergens last van hebt. Dat is precies wat ik tegen captcha's heb: dat het normale gebruikers frustreert.

Timestamps checken werkt verder vrij goed, en het is zeer eenvoudig te implementeren. Elk formulier moet de timestamp en een checksum meesturen. Die checksum bestaat uit een hash van de timestamp plus een salt die alleen serverside bekend is.

Helemaal eens met het bovenstaande. Voor mij werkt dit vooralsnog prima om de spam tegen te houden. En ik geef de uitleg erbij voor als de time error getoond wordt zodat iemand weet wat hij/zij er aan moet doen om toch het bericht te versturen.

[XWB]

Gomez12 schreef op zondag 06 september 2009 @ 02:45:
[...]

Ga er maar rustig vanuit dat zo ongeveer alle spambots een beetje javascript kunnen...

Sowieso zit je met het probleem dat als iemand JS uit heeft staan (vb. noscript) dat je hem buitensluit...

Hoeveel mensen hebben javascript dan uitstaan? Moet je hier rekening met houden? Volgens mij zijn er meer IE6 gebruikers dan mensen zonder javascript. En support voor deze oude browser wordt tegenwoordig ook al gestaakt, waarom zou je dan rekening houden met mensen zonder javascript? Ik heb hier geen cijfers van, dus misschien heb ik het verkeerd op, maar volgens mij zijn die op één hand te tellen?

[Gomez12]

Hacku schreef op zondag 06 september 2009 @ 14:42:
[...]


Hoeveel mensen hebben javascript dan uitstaan? Moet je hier rekening met houden? Volgens mij zijn er meer IE6 gebruikers dan mensen zonder javascript. En support voor deze oude browser wordt tegenwoordig ook al gestaakt, waarom zou je dan rekening houden met mensen zonder javascript? Ik heb hier geen cijfers van, dus misschien heb ik het verkeerd op, maar volgens mij zijn die op één hand te tellen?

Zijn imho geen cijfers van te geven omdat het puur afhangt van je doelgroep.

Heb je het over de libelle site dan gok ik dat het 0% is.
Het je het over een tech-site waar mensen vanaf telefoons / tijdens server-installaties (lynx rules) etc info vandaan willen halen dan zou ik er wel rekening mee houden...

Sowieso is graceful degradation nooit een slecht idee...

@Voutloos : Dus een spambot met JS support komt er direct doorheen, een spambot zonder JS support krijgt een captcha voor zijn neus ( die zijn nog nooit gekraakt ). Nee, dat zal echt perfect werken als anti-spam...
Gooi dan minimaal een recaptcha op die tussenpagina, alhoewel ik vermoed dat de meeste spambots nooit op die tussenpagina gaan komen...

Verlies aub het doel ( anti-spam ) niet uit het oog als je allerlei technische oplossingen verzint. Als je enkel via JS wilt kunnen submitten kan je nog redelijk wat cloaking doen, als je een fallback wilt aanbieden zijn je cloaking mogelijkheden sterk beperkt omdat je uiteindelijk enkel een form-submit overwrite...

[ Voor 27% gewijzigd door Gomez12 op 06-09-2009 16:10 ]

[Voutloos]

Dan kom je zonder js op een tussenpagina met je favoriete gebruiksonvriendelijke captcha. Zo. Ook weer opgelost.