Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 92 reacties

Twee Amerikaanse wetenschappers hebben een nieuwe methode ontwikkeld om spoofing-bots van mensen te onderscheiden. De methode is gebaseerd op de snelheid van de toetsaanslagen en is bedoeld voor authenticatieservers.

Om aanvallen van spoofing-bots op individuele computers tegen te gaan, hebben Danfeng Yao en Deian Stefan TUBA ontwikkeld. Deze nieuwe authenticatiemethode houdt rekening met de snelheid waarmee url's, mailadressen en wachtwoorden wordt ingetikt.

keylogging

Danfeng Yao is assistant professor bij Viriginia Tech en Deian Stefan is doctoraalstudent aan de computer science-afdeling van de Stanford University. Als hun nieuwe methode op een authenticatieserver wordt geïmplementeerd, bepaalt TUBA de snelheid van de gebruiker. Als TUBA genoeg gegevens heeft verzameld, verwerkt het de informatie in een profiel van de gebruiker.

Nadat de trainingsfase is afgerond kan een verdachte handeling bij de authenticatie van een gebruiker worden gedetecteerd. De gebruiker moet dan van TUBA een aantal namen, url's en e-mailadressen invoeren. De server genereert de gegevens die de gebruiker moet tikken aan de hand van informatie uit de trainingsfase. Als deze gegevens zijn ingevoerd, kan TUBA beoordelen of het door een menselijke gebruiker of door een bot is gedaan.

"De snelheid van een toetsaanslag is een goedkope manier om individuele gebruikers te authenticeren", zegt Yao. Volgens het onderzoek gaf TUBA in 4,2% van de gevallen een false positive of een false negative. In zo'n geval werd de persoon geblokkeerd of de bot doorgelaten.

Yao, houdster van een patent op het gebied van computerbeveiliging, waaronder deze anti-spoofingtechniek, gaat hiervoor een bedrijf oprichten. Hierover vindt overleg plaats met Virginia Tech en haar voormalige werkgever Rutgers University. Er is dus kans dat de authenticatietechnologie op de markt komt.

Reacties (92)

Reactiefilter:-192092+154+22+30
Moderatie-faq Wijzig weergave
Tof als je iets snel aan het typen bent omdat je met een noodgeval zit... Dan volg je ook niet meer je normaal patroon en zal je ook geblokeerd worden... Maar in de toekomst indien deze technology meer gebruikt word zullen bots ook gewoon eerst zien hoe het patroon van de gebruiker is alvorens ze zelf iets gaan doen...
Mja, dat en keepass bijv. Ik ken >90% van mijn wachtwoorden niet. Keepass typt ze gewoon in voor me... Meeste zijn 20+ random karakters (je wil niet weten hoeveel websites over de zeik gaan van meer dan 20 :)).

Ik type ook blind. Op goede dagen haal ik ergens tussen de 400-460. Op slechte dagen iets van rond de 320, aanzielijke marge.
Daar dacht ik ook al aan, krijg je een kuurtje van de dokter mee waardoor je een beetje suf bent kan je niets meer doen.
Of een hand in het gips ofzo...

Maar ik denk dat dit algoritme het waarschijnlijk ook zoekt in relatieve snelheid tussen verschillende letters. Bijv. hoeveel trager je typt als je een hoofdletter wilt typen en shift induwt, en je gemiddelde relatieve traagheid tussen verschillende letters (bijv. hoe snel typ je normaal de a en de e achter elkaar, en deze snelheid relatief vergelijken met die bij andere lettercombinaties).

En ik kan me nog wel voorstellen dat je dan toch leuke en nauwkeurige profielen kunt opbouwen van iemands typkunsten. Je kunt zelfs dingen als vaakgemaakte typo's e.d. aan het profiel toevoegen en iemand bijvoorbeeld pas uitloggen/kicken als het een hele tijd afwijkt... of dan bijv. opnieuw om een password vragen (kan hijacked terminal tegengaan!)

Voor die hand in het gips moet wel een oplossing komen, maargoed, dat zou je zelfs nog vooraf kunnen doen door daar een paar referentiezinnen/-woorden in in te typen met beide handen los (even heel ver doorgedacht :+).

Voor het gevalletje 'niet meer kunnen typen met 20 bier op' is dit ook wel handig, zodat je bijvoorbeeld niet namens je baas 7 miljoen vaten olie inkoopt via internet.
Maar ik denk dat dit algoritme het waarschijnlijk ook zoekt in relatieve snelheid tussen verschillende letters. Bijv. hoeveel trager je typt als je een hoofdletter wilt typen en shift induwt, en je gemiddelde relatieve traagheid tussen verschillende letters (bijv. hoe snel typ je normaal de a en de e achter elkaar, en deze snelheid relatief vergelijken met die bij andere lettercombinaties).
Maar dan nog, een beetje spyware heeft zo jouw algoritme achterhaalt.
Maar als er al spyware met een keylogger op je systeem zit, hebben zo goed als geen enkele beveiligingsmethoden nog zin...
Of lekker met je smartphone/tablet bezig bent. En alle vreemde tekens die je nodig hebt, 3 tabbladen verderop zitten op het virtuele toetsenbord...
ja inderdaad, wat denk je van iemand die net zijn typ cursus heeft afgerond... zit je dan met je 50 meer aanslagen per minuut....
Gewoon opnieuw leren? Net zo makkelijk als je wachtwoord resetten neem ik aan :)
En doe jij dat graag?
Dit lijkt me inderdaad een systeem met nogal wat haken en ogen. Het scheelt nogal of ik mijn wachtwoord intik met een collega die naast me staat of dat ik het 's ochtends als ik alleen ben met een kopje koffie in mijn andere hand om een voorbeeldje te noemen...

Of het feit dat ik af en toe nog wel een tikfoutje maak met een lang wachtwoord dat ik niet zo vaak gebruik, je kent het wel: je weet dat je een foute toets hebt ingedrukt en drukt backspace en gaat weer verder...

Wat is er mis met gewoon de aloude methodes? (5 seconden pauze tussen wachtwoorden invoeren, en 5 minuten na 3 x fout)...

[Reactie gewijzigd door rvl1980 op 3 november 2010 08:17]

Wat als je dan vaak cntrl c en cntrl v gebruikt voor urls, inlognamen en wachtwoorden? wordt dat ook meegenomen?
Ik denk dat een digitale invoer praktisch gezien in een keer word ingevoerd en menselijke invoer altijd afzonderlijke invoer van tekens zal zijn indien geen copy paste idee.
Het probleem van iemand locken na 3x fout is dat je er altijd 'grappen makers' bij hebt die een account van een ander frustreren.

Wanneer je je klanten persoonlijk kent is het voor een beheerder nog wel te doen om een lock te resetten, maar op het internet met 1000-den onbekende klanten...
Daar ben ik het mee eens. Bovendien zou een bot dingen in kunnen typen met een normale vertraging tussen de letters, + of - een random interval. Als je een klein beetje je erin verdiept kan je zelfs rekening houden met korte 'denk' pauze's tussendoor, typefouten, afstand tussen letters op het toetsenbord en dat soort dingen. Misschien is het niet perfect, maar er is al snel iets moois te programmeren. En als er aan de authenticatiekant maar genoeg false positives worden gegenereerd is deze methode al waardeloos.

En je zal idd maar in nood zitten, en geweerd worden omdat je te snel typt en dan net buiten het gemiddelde valt.
Het bot kent niet de eigenaardigheden van de echte eigenaar van de login die in zijn profiel worden opgeslagen. Als een bot random vertragingen gebruikt zal dat nooit overeenkomen met dat profiel.
Maar een virus kan wel uitermate simpel met een keylogger met tijdsaanduiding een eigen profiel opbouwen om als invoer voor de bot te dienen.

Ik doe er (volgens mij) niet echt langer over om na de 'e' op 'enter' te drukken als ik een bekende vraag zie of een onbekende vraag.
Dat kost gewoon een x tijd die gewoon te meten valt met een keylogger, paar samples en een klein beetje random vertraging en het lijkt net echt.
En juist daarom is dit systeem voor de gebruiker ook enorm irritant als hij per ongeluk nieuwe 'eigenaardigheden' vertoont en dan als bot bestempeld wordt. Ik zie het nut er in ieder geval niet van in.
Maar daardoor valt de efficiŽntie van die dingen natuurlijk wel helemaal weg. Nu is het zo handig dat alles enorm snel kan ;)
Wat dacht je van gewoon een bot die iets delay doet in wat hij typed? Das niet zo heel moeilijk....
@Limaad

Ja daar ben ik dus ook beniewd naar, wat als hij een random tijd pakt tussen bepaalde aanslagen. Zogenaamde "auto-typers" veel gebruikt in games hebben dat er al in zitten om systemen van online games te omzeilen.

Zo ben ik ook beniewd hoe dit systeem reageert op het kopiŽren / plakken van wachtwoorden.

Voor de rest vind ik deze ontwikkelen de goede kant opgaan, zo krijg je een systeem waar de gebruiker niet direct geconfronteerd word (bijvoorbeeld zo'n plaatje met tekst die je dan in een leeg vak moet invullen, ben de naam kwijt) maar een manier die het de gebruiker juist makkelijk kan maken.

edit: typo

[Reactie gewijzigd door boyjim op 3 november 2010 09:25]

@Boyjim Zo'n plaatje heet een captcha

Het idee erachter is inderdaad interessant en ik vind dat je een aardig argument geeft. Het gebruiken van 'metadata' zoals de snelheid van het typen van de gebruiker, zou (mits het super werkt, wat hier nog te betwijfelen is) een aardig alternatief zijn voor het gebruik van andere testen die bots afvangen.

Zo hebben bijvoorbeeld ook captcha's het probleem dat ze ondertussen al weer steeds moeilijker moeten worden om de bots nog buiten te houden.

[Reactie gewijzigd door kibje op 3 november 2010 09:44]

Dat nog nooit iemand eerder hier op is gekomen. Maar hoe lang zal het duren voordat bots langzamer de tekst intikken?
Denk dat het zo binnen een paar minuten in te bouwen is. Misschien en af een toe een random er in zodat het nog echter lijkt.
Ik kan mij anders herinneren dat persoonsherkenning op basis van toetsenbordaanslagritme (galgje?) al heel oud is.
Zeker geen nieuwtje.
Herinner me een topic op GoT van minstens een jaar geleden, maar volgens mij hoop meer, waar iemand al vroeg of mensen wat dingen in wilde tikken in een site die ook dit soort dingen deed.

Maar het lijkt mij nogal een probleem als je je wachtwoord wil intikken in niet standaard situaties, dus als je haast hebt, kwaad bent, arm in het gips hebt, 1 vinger niet kan gebruiken vanwege papier snee, etc.
Op een gegeven moment worden die bots nog nuttig ook !

http://xkcd.org/810/
Ik ben benieuwd hoe ze ctrl+v situaties gaan oplossen ;)
Stom, verkeerd gelezen. Pas bij detectie van verdacht gedrag wordt er dus een test voorgelegd; ik dacht dat deze test al vooraf werd voorgelegd.

Overigens vind ik een 4,2% false positive best wel hoog, leuk als je zoals hierboven al vermeld in een noodsituatie zit.

[Reactie gewijzigd door eXtReMeBiE op 2 november 2010 17:55]

Dat wordt als het goed is geregistreerd als slechts twee toetsaanslagen.
Ja dat is nu net jammer. Je kan bots IMO niet buiten houden door te kijken naar het aantal toetsaanslagen/m. Je kan wel constateren dat een formulier dat met 100 tekens per seconde wordt ingevuld niet kan kloppen en zodoende kun je bots enorm vertragen. Het duurt immers langer voordat het proces klaar is als het constant random pauzes moet inlassen en 1 letter per een aantal honderden milliseconden mag invoeren.

Als je het nu toelaat dat een bot Ctrl+V kan gebruiken duurt het bij elkaar dus nog maar 2x het aantal milliseconden pauze.

Waarom combineren ze dit niet met het aantal verzoeken per minuut vanaf een bepaakd IP-adres. Het aantal mag niet te laag zijn omdat mensen in een groot bedrijf anders gezien worden als bot maar 1 miljoen verzoeken per uur lijkt mij bijvoorbeeld niet in orde, zeker als het 1000 seconden (1 miljoen milliseconden) heeft geduurd..

EDIT: 4+% false positives lijkt mij persoonlijk erg irritant om mee te werken.. Dit mogen ze ook nog even uit laten kristalliseren,

[Reactie gewijzigd door Incr.Badeend op 2 november 2010 18:05]

Ja dat is nu net jammer. Je kan bots IMO niet buiten houden door te kijken naar het aantal toetsaanslagen/m. Je kan wel constateren dat een formulier dat met 100 tekens per seconde wordt ingevuld niet kan kloppen en zodoende kun je bots enorm vertragen.
Maar dan zou de AutoFill functie (die van Google ofzo, niet van Windows) ook niet meer werken?
4.2% is inderdaad veel te veel, maar het is al beter dan captcha's die bij mij zelden de eerste keer goed gaan en zo vreselijk nutteloos zijn omdat de methodes om ze te 'kraken' overal te vinden zijn (zelfs op wikipedia).
Hoewel... die is 4.2% na een training. Dat is helemaal triest.
Voor situaties waar een traning toepasbaar is, zijn ook handiger methoden te bedenken.

Bijzonder ook dat ze false positives (bot die doorgelaten wordt) en false negatives (mens die geblokkeerd wordt) samen pakken en false positives noemen. En is dat met bestaande bots gedaan? dan gaat dat percentage nog wel omhoog.
4.2% is veeeel te veel... Hoe vaak gebeurd het niet, vooral bij sites die je niet vaak gebruikt dat als je zeker weet dat je het goede wachtwoord hebt ingetikt zonder tikfouten, je een van de andere wachtwoorden probeert die je in gebruik hebt (want was het nou dat ene wachtwoord of was het nou dat andere wachtwoord dat ik hier heb geregistreerd???).... Nu was het dus het goede wachtwoord, goed ingetikt, maar vervolgens zit je wel eerst 4 andere te proberen....
Er kan nu ook een bot gemaakt worden dat makkelijk zijn toetsaanslagen aanpast aan de nieuwe methode.

Er kan zelfs een random algoritme worden geschreven dat bijvoorbeeld bij spaties, 1sec rust neemt.

Dit is tijdelijke oplossing, maar geen definitieve oplossing tegen spoofing-bots.
Spaties in een url, cool. Maar het punt is duidelijk, dit is makkelijk na te maken.
%20? Komt vaak genoeg voor.
"%20" is niet " ". 3 toetsaanslagen vs 1
Wat hier op Tweakers.net staat over False positives klopt niet. In het oorspronkelijke paper, staat een False Positive rate van 4.x% als mensen met elkaar vergeleken worden (op basis van dezelfde invoer). Er is slechts een False Positive rate van 1.5% als menselijke invoer met de invoer van bots vergeleken wordt. False Positive betekent overigens niet dat iemand werd tegengehouden, maar juist dat iemand werd doorgelaten terwijl dat niet mocht.

De False Negative rate lag hoger: in 5.7% van de gevallen werd een legitieme gebruiker niet doorgelaten.

M.b.t. tot de naÔeve ideeŽn die mensen hier hebben over "even een randomizertje ertussen zetten": als je het paper leest, zie je dat de onderzoekers al rekening hebben gehouden met "random" delays die bots zouden kunnen introduceren (ze hebben getest met een random noise en een gaussian noise bot). Die vormen dus geen probleem.

Deze TUBA is overigens niet meer dan de moderne tegenhanger van de "fist" uit de tijd van de telegraaf (het seininstrument, niet het dagblad): telegrafisten konden elkaar herkennen aan de hand (no pun intended) van hun "fist": de subtiele verschillen in timing waarmee de seinsleutel werd aangeraakt tijdens het telegraferen.

Als ze dit zouden koppelen aan een zelf-lerend systeem, dat beetje bij beetje het typgedrag van de gebruiker onder verschillende omstandigheden leert, dan heb je een behoorlijk sterk, non-intrusive systeem.

[Reactie gewijzigd door Herko_ter_Horst op 2 november 2010 19:13]

M.b.t. tot de naÔeve ideeŽn die mensen hier hebben over "even een randomizertje ertussen zetten": als je het paper leest, zie je dat de onderzoekers al rekening hebben gehouden met "random" delays die bots zouden kunnen introduceren (ze hebben getest met een random noise en een gaussian noise bot). Die vormen dus geen probleem.
Jammer dat je input van anderen direct als naÔviteit af probeert te doen. Weerleg het dan gewoon met argumenten :?

Een van de punten hierbij is is dat er nog geen bots speciaal voor deze toepassing geschreven zijn. Simpelweg een random tijd wachten zal niet werken maar op basis van bv keylogging en metingen kun je natuurlijk een veel nauwkeuriger beeld schetsen met een bot waarbij je juist de variaties minimaal probeert te houden met als doel de software te laten geloven dat het met een mens te maken heeft EN met de bedoelde gebruiker. Wil je dit soort systemen voor de gek houden dan zul je minimaal moeten afwijken maar een afwijking zal nodig zijn tegen replay beveiligingen indien aanwezig.

[Reactie gewijzigd door Bor op 2 november 2010 20:27]

Ik zeg toch dat even de paper lezen als duidelijk maakt dat een randomizer niet werkt? Lijkt me een valide argument. En zomaar aannemen dat researchers er niet over nagedacht hebben, vind ik naÔef, ja.

En een keylogger installeren op de machine van elke willekeurige gebruiker is toch wel even iets anders dan een scriptje schrijven om automatisch in te loggen op een forum om te spammen. Om betrouwbaar een mens na te doen, moet je er al haast een academische studie van maken.
Het is imho naÔef te bedenken dat een algoritme onvatbaar is voor goed ontworpen geautomatiseerde systemen. Het is slechts een kwestie van een hogere benodigde inzet om een werkende bot te maken die de menselijke activiteit kan analyseren en simuleren. Natuurlijk is daar meer voor nodig dan een simpel programmaatje wat je van afstand kunt draaien echter hoeft een keylogger mogelijk niet eens de enige optie te zijn. Toetsaanslagen zijn namelijk ook te horen en dus zelfs op afstand (zei het beperkt) te analyseren. De kans op de ontwikkeling van counter measures zal naar gelang deze techniek meer gebruikt word toenemen (evenals wanneer deze gebruikt gaat worden voor informatie met hoge waarde).
De mooiste authentificatie methode die ik heb gezien is afbeelding in een cirkelvormige kader rechtop roteren. Het is namelijk tot nu toe voor geautomatiseerde systemen onmogelijk in korte tijd een afbeelding te herkennen en deze rechtop te roteren. De mens is daar nu eenmaal sneller in.
Inderdaad, er zijn nog ontelbare dingen die computers niet zomaar kunnen detecteren, terwijl ze voor de mens eenvoudig zijn. Denk bijvoorbeeld aan:
  • Hoeveel dieren staan er op deze afbeelding
  • Vul de oneven cijfers van "14752" in
  • Hoeveel lachende mensen staan er op deze foto
  • Hoeveel is vier plus acht
  • ...
Combineer genoeg verschillende types en variaties, en een bot die dit kan kraken, is klaar voor the matrix. Zo'n algoritme moet beschikken over geavanceerde beeldherkenning en de mogelijkheid hebben om betekenis te kunnen geven aan een zin.
Moest ik over zo'n algoritme beschikken zou ik het wel aan Google verkopen, in plaats van webformulieren in te vullen ;)
Ik weet niet of dat handig is, volgens veel vegetariŽrs zijn vissen en kippen geen dieren (gezien het feit dat ze vaak wel vis en kip eten), moet je de oneven cijfers intypen in de volgorde zoals ze daar staan, of van laag naar hoog, glimlachen is meestal niet echt lachen, dus tellen die mee of niet? Tel je in een decimaal systeem, of is het hexadecimaal?
Leuk geprobeerd, maar zo makkelijk om te omzeilen... gewoon de bot de letters stuk voor stuk met random delay tot op de miliseconde laten invoeren. Kan zelfs random typefouten implementeren... Weg beveiliging.
Volgens mij is dat juist nauwelijks mogelijk. Het systeem heeft van de 'echte' gebruiker een profiel opgebouwd. Een bot zou dus jouw profiel moeten nabootsen om het systeem te passeren. Dit nabootsen gaat - lijkt mij - niet lukken zonder dat de bot over jouw typgedrag beschikt.

Oftewel, stuk voor stuk met random delay is inderdaad the way to go, maar dan nog zal het typgedrag van de bot afwijken van het typgedrag van de gebruiker.

[Reactie gewijzigd door eXtReMeBiE op 2 november 2010 18:00]

Een profiel van wat? Dat jij op keyboard X met monitor Y met 2 handen kan typen op Z? Wat als deze factoren nu veranderen? (je hand in het gips, kleine monitor, mobiel onscreen toetsenbord?)

Buiten het copy&paste van URL's, wachtwoorden en andere wachtwoorden.
Een profiel van je typgedrag.

Wanneer jij een zin/url/whatever moet overtypen kan het systeem jouw typgedrag analyseren; niet alleen hoeveel woorden je typt per minuut, maar ook wanneer je een pauze neemt, hoeveel je typfouten maakt (en op welke positie in de zin deze het vaakst voorkomen), etc.

Als het typgedrag van de bot hier niet mee overeenkomt, zal het gedetecteerd worden. Oftewel, er zijn meer variabelen die gebruikt worden in dit systeem dan bijv. enkel woorden of karakters per minuut.

[edit]
En als je profiel tijdelijk verandert ben je dus de sjaak.

Het lijkt mij overigens wel dat dit systeem enkel wordt getriggerd op het moment dat er al sprake is van verdacht gedrag; zeker omdat het met een foutmarge van meer dan 4% zeker niet foolproof is.

[Reactie gewijzigd door eXtReMeBiE op 2 november 2010 18:08]

leuk, maar als ik verkouden ben tik ik een tikje trager dan wanneer ik gewoon fit ben.
Een leuk idee maar 4.2% is nog al niet wat... wat is de fout marge van een goede CHAPTA oplossing? 4.2% dat houd in dat als ik 100 keer een support call krijg ik dus minimaal 4 mensen niet kan helpen omdat de beveiliging besloten heeft dat ik een BOT ben en niet een mens die alleen maar wil inloggen om een wachtwoord te resten voor een klant.

Van beveiliging kun je niet spreken bij zo'n grote fout marge alleen van een gelukkige uitkomst waar het systeem net even beter presteert dan een gemiddelde oplossing. Als je echt veilig wilt zijn dan moet je toch echt over gaan op een goede authenticatie met minimaal een token etc...
Zelfs voor een website voor gewoon huis tuin en keuken gebruik zou ik er niet op vertrouwen het zou inhouden dat ~4% van de gevallen er een probleem optreed een gebruikers account wordt gelocked (~2%) dan wel een aanvaller kan ongehinderd spam plaatsen op de site (~2%) van de gevallen. Dat is toch al snel genoeg voor de meeste gebruikers om niet meer terug te keren op deze site. Er zijn immers genoeg andere sites die iets vergelijkbaars doen en beter beveiligd zijn.

Een bedrijfje starten dat deze technologie probeert aan de man te brengen lijkt me dan ook geen goed idee het is gewoon niet goed genoeg om echt te beschermen tegen aanvallen dan wel om gebruikers ongehinderd gebruik te laten maken van de service omdat als je in 2% van de gevallen een mens de toegang ontzegt omdat hij/zij te snel dan wel niet snel genoeg typt dan is dat toch best nog een groot aantal mensen op een site met zo'n 1000 unieke bezoekers per dag bijvoorbeeld is dat al snel 20 accounts die geblocked worden en dat kan volgens mij nooit je gebruikers gelukkig maken.
Wie zegt dat een False Negative (oftewel het niet herkennen van een legitieme gebruiker) direct leidt tot afsluiting van een account? Het leidt in eerste instantie alleen maar tot een extra verificatiestap.

Hoe vaak maak jij een typfout bij het invoeren van een password? Misschien ook wel in 5% van de gevallen. Leidt dat in 5% van de gevallen tot afsluiting van je account? Dacht het niet: je krijgt sowieso een aantal kansen om je password juist in te tikken. Dat is met dit systeem niet anders.
Tja, mijn oma van 80 tikt toch heel wat trager dan mijn zus die zo veel typed op haar werk dat ze bijna foutloos 200 aanslagen per minuut haalt...
Ook scripts, denk maar aan programmeerbare gaming keyboards, kunnen random langer en korter pause tussen toetsaanslag 1 en 2 etc. aanbrengen die gebaseerd zijn op gemiddelde marges.
Het (on-)veiligheis aspect noemden anderen al, en daar ben ik het mee eens.
En : weeerrrr een code er bij.....
Tja, mijn oma van 80 tikt toch heel wat trager dan mijn zus die zo veel typed op haar werk dat ze bijna foutloos 200 aanslagen per minuut haalt...
Dat is juist een van de principes waar men bij deze methode van uit gaat: een bepaalde mate van uniekheid in de snelheid van intypen. Denk bv aan (micro) pauzes tussen bepaalde letters etc.
Een goed principe, maar het zal waarschijnlijk de een of andere trage java app worden dat jouw blokkeert als je een vinger hebt gebroken enzovoort.

Mijn versie zonder profielen of andere meuk:

Na 5 keer fout test uitvoeren.
Melding weergeven: "Niet copy/pasten je wordt getest"
Als er tussen elke aanslag <150 milliseconden zit of het niet random is elke keer <5 milliseconden verschil wordt het geblokkeerd.

En voilŗ perfect werkende anti bot methode de bot wordt of geblokkeerd of Zwaar vertraagd (500x)

@Bor de Wollef
Nee na de 5 keer zal de test elke keer worden uitgevoerd.

[Reactie gewijzigd door Edek op 3 november 2010 14:33]

En voilŗ perfect werkende anti bot methode
Daar is niets perfect aan gezien een bod ook gewoon de voorgeschotelde tekst kan lezen en zijn gedrag hier op kan aanpassen. Voer je na elke 5 keer de extra verificatie toe dan hoeft een bot zelfs niet eens te analyseren wat er op het scherm staat maar kun je dit gewoon in het algoritme aanpassen. Schijnveiligheid dus en totaal niet perfect.

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True