Cloudflare wil captcha's vervangen door fysieke beveiligingssleutels

Cloudflare begint een test om captcha's te vervangen door authenticatiesleutels. Gebruikers kunnen dan onder andere Yubikeys gebruiken om zich te authenticeren. Dat gebeurt op basis van de WebAuthn-standaard; later kunnen ook telefoons worden gebruikt.

Het bedrijf zegt dat het werkt aan een alternatief voor de bestaande captcha's. Volgens Cloudflare verspillen die veel tijd voor gebruikers en zijn ze ook nog eens lastig om in te vullen. Het bedrijf wil daarom dat gebruikers U2F-beveiligingssleutels kunnen inzetten om te bewijzen dat ze geen robots zijn. Tweakers schreef vorig jaar een achtergrondartikel over fysieke beveiligingssleutels.

Cloudflare noemt het nieuwe authenticatiesysteem Cryptographic Attestation of Personhood. Dat maakt gebruik van WebAuthn, een api waarmee browsers U2F-sleutels kunnen authenticeren. In de eerste test kunnen gebruikers dat met drie sleutels doen. Dat zijn alle soorten Yubikeys, de bekendste fysieke beveiligingssleutels, maar ook HyperFIDO- en Thetis-sleutels. Gebruikers kunnen dat testen op een aparte website. In plaats van foto's van bussen en fietsen aan te klikken kunnen gebruikers klikken op 'I am human' en hun sleutel inpluggen in hun pc, of die via nfc authenticeren op een smartphone.

Volgens Cloudflare zijn fysieke sleutels ook een privacyvriendelijkere manier van authenticatie, al geeft het bedrijf toe dat de oplossing niet perfect is. Zo weet Cloudflare nog steeds welke beveiligingssleutel en hardware een gebruiker heeft.

Op de langere termijn wil Cloudflare het mogelijk maken andere apparaten in te zetten voor authenticatie. Dat kunnen smartphones zijn. Android- en iOS-toestellen zijn nu al te gebruiken als Fido-beveiligingssleutel. Op welke termijn Cloudflare dat wil gaan doen is nog niet bekend. Het bedrijf zegt dat het de huidige implementatie eerst verder wil testen.

Door Tijs Hofmans

Nieuwscoördinator

17-05-2021 • 09:53

104 Linkedin

Submitter: crypt0rr

Reacties (104)

104
104
83
6
0
19
Wijzig sortering
De laatste alinea is wat mij betreft een hele belangrijke.
Je kan immers (het overgrote deel van de) internetgebruikers niet buitensluiten door te eisen dat ze hardware van pakweg 40-50 euro aanschaffen.
Pas wanneer een oplossing voor iedereen toegankelijk is, zal deze in mijn ogen écht slagen.

Zou dit overigens iets te maken hebben met: "Cloudflare stopt met reCaptcha omdat Google die tot een betaalde dienst maakt"?
De hardware is niet meer zo duur. Hyperfido Pro Mini U2F/FIDO2/HOTP is maar € 10,--https://www.amazon.de/Hyperfido-Mini-FIDO2-HOTP-Sicherheitsschlüssel/dp/B0813YWZB2

Ik vind het een goede investering om veiliger in te loggen op diverse sites.
Je moet er wel minimaal 2 hebben zodat je beide kan registeren.
Een voor dagelijks gebruik en andere als backup.

Deze sleutel net getest op de Clourflare site en werkt.

Nadeel is natuurlijk dat Clourflare altijd ziet dat JIJ het bent.
Hier nog meer uitleg: https://herrjemand.medium...lly-bad-idea-d5487f6c7566

[Reactie gewijzigd door vDorst op 17 mei 2021 10:20]

Moet je maar net een apparaat met usb-a (nog) hebben. Hoe werkt dit dan als je een keertje met een iphone/tablet of iets anders wilt inloggen?

Voor inloggen kan ik het overigens nog begrijpen, maar voor puur captcha vervangen lijkt het behoorlijk overkill en meer moeite dan een captcha.
Telefoons die ik in huis heb, hebben Android 6 of hoger.
Alle deze telefoons heb ik Google kunnen activeren via een OTG usb kabel en deze USB FIDO2 sleutel.
OTG kabel is mogelijk niet ideaal maar het is een oplossing. Daarnaast kan je voor een duurdere optie gaan, sleutel met USB-C en/of Apple lighting aansluiting. Denk aan de SoloKeys of
Yubikeys.

Voor applicaties en websites op je telefoon, kan je je telefoon ook gebruiken maken van de Android/iOS ingebouwde WebAuthN API/Authenticator.
Niet elke mobile browser ondersteund dit. Bijvoorbeeld Firefox Focus ondersteund dat niet.
Dat ga ik niet doen
Tijd voor iets anders dan :)
Ik gebruik (o.a) een Yubikey NEO, deze heeft NFC dus zodra de prompt komt hoef ik alleen maar de sleutel tegen de achterkant van mijn telefoon te tappen en klaar.
Dat je er minimaal twee moet hebben hoorde ik ook overal, dus ik heb er twee liggen. Blijkt alleen onzin te zijn: 99% van de sites staat je niet toe een tweede aan je account te koppelen, dus had er niks aan.
Als alternatief kan je dan (in mij geval bij de Yubikey) normale OTP instellen, en die opslaan op beide keys. Het is inderdaad vervelend om een handmatige stap te moeten doen voor het opvragen van de code, maar je hebt dan wel alles op beide keys staan.
Weet wel dat YubiKey OTP 1FA is omdat het geen PIN vereist zoals FIDO, dus als iemand een van je YubiKeys weet te jatten ben je de klos.

[Reactie gewijzigd door MaroonBeret op 17 mei 2021 11:22]

Dat lijkt me dan dus juist een achteruitgang qua security?
Meestal wordt het gebruikt in een password + OTP vorm. Dan heb je wel 2FA.
?

Bij OTP moet je meestal en je wachtwoord en je [HT]OTP code invoeren
Let wel, Het is 1FA voor captcha's. Als iemand je yubikey weet te jatten kan hij doen alsof hij een mens is en niet meer dan dat. Maar dat was hij toch al.
Om in jouw door Yubikey beveiligde google account te komen, of enige andere, moet men óók je username / password kennen. En daarmee is het een van de veiligste 2fa die je momenteel kan hebben want hoewel digitale credentials relatief makkelijk door iedere aardbewoner van jou te ontfutselen zijn, is er een ontzettend veel kleinere groep die überhaupt de mogelijkheid heeft om te proberen jouw fysieke Yubikey te stelen.
Zoals anderen ook aangeven klopt dat niet. Het is net zo 2FA als het gebruik van een authenticator app, alleen is de sleutel die wordt gebruikt om die codes te genereren niet opgeslagen op de telefoon, maar op je Yubikey.

Het klopt dat als je je Yubikey verliest dat je OTP codes dan op straat liggen, maar zonder gebruikersnaam en wachtwoord heb je er weinig aan.
Klopt, TransIP bijvoorbeeld staat niet toe om meerdere Yubi keys te koppelen. Toch een slechte ontwikkeling.
TransIP ondersteunt ook geen WebAuthN. Alleen maar TOTP.
Vergeet niet dat te melden bij TransIP. Ik merk dat veel bedrijven open staan voor dit soort aanpassingen, maar wachten tot klanten aangeven dit nodig te vinden. Jammer, maar waar.
Ik ben die sites nog niet tegen gekomen maar komt ook vast dat veel sites nog geen WebAuthN ondersteunen.
Bij Google, Github is het wel mogelijk.
Dat je er minimaal twee moet hebben hoorde ik ook overal, dus ik heb er twee liggen. Blijkt alleen onzin te zijn: 99% van de sites staat je niet toe een tweede aan je account te koppelen, dus had er niks aan.
Dat ligt aan die sites, je kan moeilijk zeggen dat het onzin is om een backup te hebben voor een authenticatiemiddel. Het klopt dat de meerderheid het flut heeft geimplementeerd maar zo werkt het eigenlijk altijd in de IT. 99% van de IT in deze wereld is bagger. Het is helaas niet anders. Voor de sites die het wel goed doen blijft het verstandig om een tweede token te hebben.

Het zegt ook wel wat over hoe de wereld om gaat met veiligheid. Bij MFA zie je heel goed dat de meesten er maar een slag naar slaan zonder te weten waar ze nu eigenlijk mee bezig zijn. Iedereen die er even over na denkt zal beseffen dat tokens kwijt raken en dat een tweede token/authenticatiemethode de beste oplossing is.

Vaak hebben sites wel "recovery codes" die je eenmalig kan gebruiken om in te loggen als je token niet bruikbaar is, maar dan moet je wel de discipline hebben om dat soort codes ergens veilig en toegankelijk op te slaan. Dat toegankelijk is belangrijk want mensen behandelen dit soort codes vaak als wachtwoorden (wat het technisch gezien ook zijn) en zetten ze in hun wachtwoordmanager, maar ze hebben hun token nodig om die wachtwoordmanager te openen. (en denk ook even over backups).
Het is ook niet duidelijk, bij het aanmaken van een nieuwe 2fa, kies ik voor handmatig en kopieer ik de key. Daarna voeg ik deze handmatig toe aan beide keys toe via de yubico authenticator en soms ook aan de Microsoft authenticator op mijn telefoon (zoals die van tweakers) omdat ik die altijd bij me heb. Omslachtig maar daarna heb ik iig twee keys met dezelfde code.

En daarna zet ik recovery via sms en mail uit op dat account.
De hardware is in west europa niet zo duur. Maar als de hele wereld opeens over moet dan hebben gebruikers in India of delen van Afrika een probleem.
Je kan immers (het overgrote deel van de) internetgebruikers niet buitensluiten door te eisen dat ze hardware van pakweg 40-50 euro aanschaffen.
Uitsluiten zal niet zo gauw gebeuren. Internetgebruikers die de hardware aanschaffen zullen geen captcha's meer voorgeschoteld krijgen. Andere gebruikers die de hardware niet hebben, zullen wel nog zebrapaden, taxi's, brievenbussen, ... mogen zoeken.

Cloudflare schotelt trouwens zeer zelden een captcha voor. Enkel wanneer de website "under attack" is of je ip adres gekend staat voor DDoS aanvallen of spamdoeleinden, moet je een captcha oplossen vooraleer de website te zien krijgt.
Er zijn een aantal alternatieven voor reCaptcha, ik denk aan hCaptcha,
Volgens mij is Cloudflare al gestopt met reCaptcha omdat Google geld wilde zien en zijn ze toen naar hCaptcha gegaan. hCaptcha is echt vreselijk, met het aanklikken van stoplichten, of bussen. Soms ben ik een minuut bezig met een captcha en denk ik laat maar zitten deze site.
Gebruik zelf ook hCaptcha en tot nu toe werkt het prima. Ik heb hem wel weggehaald van de loginpagina op verzoek van zo'n beetje alle users, maar voor registratie en password reset is het nog gewoon nodig. Lijkt me wel een mooie tussenweg, 2FA (gewoon TOTP momenteel) is voor iedereen verplicht dus captcha is niet zo zinvol meer. Voor de registratie/reset kun je dan adressen gaan raden en je wilt geen door bots aangemaakte accounts, dus daarom daar nog wel een captcha. :Y)
Zo denk ik er ook over! hcaptcha op mijn registratie en resetpagina's. Op de loginpagina's uiteraard niet (ik heb nochtans geen 2FA)
Soms ben ik een minuut bezig met een captcha en denk ik laat maar zitten deze site.
Terecht naar mijn mening. Als ik er niet in 2 poging doorheen kom dan stop ik gewoon. Dan verdien je het als website ook niet en ga ik wel naar een concurrent. Ik heb geen zin in dat soort pesterijen. Zeker niet omdat Google meer data wil (of een concurrent zoals hCaptcha). Lekker iedereen laten dansen naar de pijpen van Google :(

Overigens ga ik geen fysieke sleutels aanschaffen om een willekeurige site te bezoeken. Ook dan geldt: dan maar niet.
Ik ben zelf op een aantal plaatsen ook overgestapt op hCaptcha omdat ik geen zin heb dat data over mijn bezoekers naar Google gaat.

Ik ben nu eigenlijk alleen nog op zoek naar een Europees alternatief (of self-hosted) zodat data helemaal niet meer aan de overkant van de oceaan terecht komt.
Wat ik dan altijd een dingetje vindt: Wat als je die sleutel niet bij de hand hebt, om wat voor reden dan ook? Dus alleen daarom al denk ik dat ze er een combi van maken. Dat je met een Yubikey kan inloggen maar ook alsnog met een captcha.
Dat is het zelfde voor mij als naar je werk gaan en dingen meten zonder een usb stick bij je te hebben.

Onhandig doe je niet, net zoals niet uit huis zonder sleutels. Of niet zonder je 2fa beveiligingskey anders kan je niet op het netwerk.
Dat ding moet dus continu aan je sleutelbos hangen? en die sleutelbos moet je dus altijd mee hebben? Stel je gaat samen met je partner ergens naar toe en je partner neemt de huissleutel al mee. (bij mij is het al een dikke bos, dus als ik de kantoorsleutels niet nodig heb laat ik ze thuis, als ik de autosleutels niet nodig heb, laat ik ze thuis, als mijn partner de huissleutels al mee heeft, waarom moet ik dat dan ook?). Betekent dus een wijziging van routine.

Het kan overigens ook zo zijn dat het de cloudflare is van het bedrijf, en dat de baas zegt: 1 key to rule them all. Dan moet die sleutel dus op kantoor blijven. Dat laatste is dan ook een keuze, maar wel een reële keuze.

Gelukkig wordt in het artikel ook al de mogelijkheid tot gebruik van je mobiele telefoon aangestipt, Die heb je vaker bij je dan je sleutels, maar ook daar: stel dat je je mobiel thuis hebt laten liggen?

[Reactie gewijzigd door pizzafried op 17 mei 2021 11:46]

Voor zakelijk gebruik is er ook een oplossing voor fido2 in je toegangspas/badge, zoals de ATKey.card. Je moet die toch al de hele dag bij je dragen.

Voor privé zie ik meer een oplossing in een virtuele fido op je smartphone als backup.
Nooit een noodsituatie gehad waarbij je moest inloggen op beheeromgevingen, buiten werktijden?
Als je deze ATKey.card zou gebruiken dan heb je die toch bij je? Je pas laat je niet op je bureau liggen anders kom je niet eens buiten of sommige afdelingen niet eens af. Althans zo werkt het bij de bedrijven waar ik kom.
Ja, Maar ik neem dat ding niet per definitie mee naar een verjaardag aan de andere kant van het land....
Ik lees tussen de regels door verbazing, bijna verontwaardiging, maar dit geldt toch voor zoveel zaken? Je kan je huis, auto of bedrijfspand ook niet in als je je sleutels vergeten bent.

Als ik zie hoeveel mensen lopen te tobben met tig wachtwoorden voor tig sites, gefrustreerd raken zelfs, weet ik zeker dat hele volksstammen een fysieke sleutel (in welke vorm dan ook) een prima oplossing zouden vinden.

En laten we nou even realistisch zijn: Hoe vaak vergeten mensen hun mobieltje? Ze vergeten nog eerder hun schoenen.
yes dat is zo, maar digitaal kun je meer dan een pand binnengaan. Als dat Fysiek wordt gehinderd omdat je door een al dan niet domme zet die key bent vergeten. Zelfde probleem met de fingerprint beveiliging op je telefoon. Vrij onrealistisch misschien als je al je vingers hebt ge-authoriseerd, maar geen vingertoppen = geen toegang tot je telefoon als je er niet ook nog een andere inlogmethode naast hield.

Toegang tot zoiets als Cloudflare kan cruciaal zijn als de site van je werkgever er uitligt.
Klopt, maar in de praktijk is er altijd wel een plan B, net zoals je altijd wel je wachtwoord opnieuw kunt instellen als je dat vergeten bent.

Dat is niet per se veiliger maar een mens inzetten garandeert ook niet dat oplichters herkend worden en sites met veel gebruikers willen het opnieuw instellen van wachtwoorden ook automatiseren, vanwege de kosten.
vandaar dus dat ik in mijn eerste post in dit draadje een combinatie van de 2 verwachtte: Het kan straks met de Yubikey (of welke sleutel ze dan ook ondersteunen), maar ook alsnog met de captcha.
Daarom liggen sleutels vaak bij vriend/buren/familie. Je wilt toch je huis weer in als je sleutel binnen ligt en jij buiten staat.

Dergelijke systemen met single-point of failure / geen backup-systeem zijn geen goed idee.
Ik zou willen dat er meer gewerkt gaat worden met bestaande grote frameworks zoals TouchID/FaceID, mijn laptop en mobieltje hebben prima secure elementen met biometrische authenticatie, een externe yubi oid moeten gebruiken voelt overbodig. Ik ben geen Android of Windows gebruiker maar ik gok dat heel apparatuur daar toch ook soortgelijk spul aan boord heeft?
Dat staat letterlijk in het artikel in de laatste alinea ;). Waar het aan schort is dat Cloudflare (nog) niet de benodigde procedures heeft geimplementeerd om attestation formats van ingebouwde authenticators te controleren. Aangezien externe authenticators werken voor een select aantal fabrikanten lijkt het er op dat de `packed` en `u2f` formaten werken, maar dat `android-key` of `android-safetynet`, `tpm` (Windows) en `apple` nog missen.
Volgens mij staat er dat ze het mogelijk willen maken, dus het is er nog niet. Wat Google doet is anders, het is weer afhankelijk van een Google app en bluetooth.

Nee ik bedoel gewoon dat ik wil inloggen met mijn iPhone of Macbook zoals ik nu ook met mijn iPhone kan inloggen in apps die "Login with Apple" ondersteunen. Ik heb daar geen third party app voor nodig, alleen maar een iPhone of Macbook die gekoppeld is aan mijn iCloud account en TouchID/FaceID
Ik had de link in de laatste alinea niet gelezen - die is van januari 2020 en had niet de inhoud die ik dacht dat het had 😅. Android 7+ en iOS 14+ hebben WebAuthn-ondersteuning ingebouwd, je kan dus Face/Touch ID gebruiken naast een externe authenticator (zoals een YubiKey).
Cloudflare heft toch een eigen versie, daar gaat het denk ik om? Als we tijd hebben willen we eigen overstappen van reCAPTCHA van Google naar die.
WebauthN zou ook gewoon faceid/vingerafdruk/windows hello (met pin) ondersteunen volgens mij. Waarom ze focussen op usb-sticks vind ik ook vaag, klinkt als meer moeite dan een captcha invullen (plus er hangt een dongle uit je telefoon/laptop).

Als ze gewoon ingebouwde beveiliging accepteren lijkt het me een mooi plan, moeten ze wel duidelijk maken dat je niet inlogt maar slechts laat weten dat je een mens bent (hoe dat te verifiëren valt is ook nog lastig)
Er zit een heel groot verschil tussen kunnen aantonen dat je een mens bent en geen machine, en moeten aantonen WIE je bent want als je fysieke sleutels moet gebruiken authentiseer je ook meteen je identiteit.
Uiteraard, alles draait om geld, maar cloudflare is groot genoeg om zelf een capcha dienst op te zetten ( zelf ooit één geprogrammeerd op basis van letter/ cijfer transformaties en pixelation, een middag werk)
zelf ooit één geprogrammeerd op basis van letter/ cijfer transformaties en pixelation, een middag werk
Maar dat is dan ook wel de variant die helaas door robots tegenwoordig makkelijker is te decoderen dan door echte mensen...
Met een gewone captcha kan een gebruiker niet gevolgd worden over browsers/devices/sessies heen. Met een fysieke sleutel wel.

Ik zie dan ook nog niet helemaal in waarom je een authenticatie middel zou willen gebruiken voor captcha.
Maar dat gebeurd wel. Nooit opgevallen dat je niet altijd de bussen of verkeerslichten hoeft aan te klikken?

Soms is alleen het vinkje zetten voldoende en dat is niet omdat ze je op je blauwe ogen geloven.
Als ik een browser in een private-mode start, waardoor alle cookies enkel voor die sessie zijn, weet een cloudflare niet dat ik het ben. Of als ik op een nieuw apparaat dat doe, zeg een openbare computer in de bieb of bij de vereniging, of in een nieuwe VM, of wat dan ook waardoor je browser fingerprint anders word en cookies geleegd worden. Enkel dat het de zelfde sessie is. Als daar de CAPTCHA vervangen word door de auth key, dan weet een cloudflare wel dat ik al die verschillende sessies ben.

[Reactie gewijzigd door wild_dog op 17 mei 2021 11:24]

Als ik een browser in een private-mode start, waardoor alle cookies enkel voor die sessie zijn, weet een cloudflare niet dat ik het ben.
IP adres is dan nog hetzelfde.

Met de andere voorbeelden heb je gelijk, maar daarvoor geldt, doe je dat daadwerkelijk? En doe je dat dan voor iedere website opnieuw?

Overigens kun je de geregistreerde sleutel gewoon onder een pseudoniem gebruiken zodat het nooit naar jou herleidbaar is.
Meerdere mensen wonen in 1 huis. Gasten nemen smartphone mee en gebruiken wifi. Je kan een gastnetwerk hebben. Je kan misschien aannemen dat voor een specifieke applicatie/spel 1ip adres het zelfde persoon is, maar meer ook niet.

Er zijn steeds meer copyright rechtzaken in Amerika tegenwoordig waar enkel het IP adres weten niet meer genoeg is om een specifiek persoon aan te klagen, ook als je bij de ISP de geregistreerde eigenaar kan achterhalen, om exact deze reden.

Sleutel onder pseudoniem gebruiken is geen verbetering, je hebt namelijk nog steeds de zelfde sleutel voor alle sessies. Er hoeft maar 1 sessie tussen te zitten waar echte gebruikersgegevens gelinkt kunnen worden, zoals een bol.com bestelling, en alle sessies (ook de oude) zijn aan jou te koppelen.

[Reactie gewijzigd door wild_dog op 17 mei 2021 18:42]

Het is even een voorbeeldje van gegevens die nog bruikbaar zijn om even een educated guess te kunnen maken. Er zijn er heel veel meer. Punt is. Anonimiteit is niet zomaar te regelen. Zelfs als jij je shit wel op orde hebt en die gast die op je wifi zit niet dan kunnen ze zijn verkeer filteren uit het verkeer vanaf een specifiek IP adres en dan hebben ze het alsnog. Meerdere apparaten in hetzelfde huishouden idem dito. Je moet dan voor iedere apparaat de boel netjes geregeld hebben en dat werk niet altijd. Browser fingerprinting, device fingerprinting, zelfs met een VM ben je niet veilig, want met passthrough heb je nog steeds de native Device ID’s te pakken.

Kijk ik snap je punt hoor, maar voor 99+% is het gewoon niet relevant en die tijd die het oplevert ws wel. Dus dan weet je wel wat er gebeurt. Spijtig, maar niets aan te doen.
Ik zeg ook niet dat ze mij op mijn blauwe ogen geloven ;) Enkel de captcha zelf is niet voldoende, de cookies, open sessies, etc. daarmee kan het uiteraard wel. Een captcha gebruikt inderdaad meer data, indien aanwezig, om te bepalen om of jij een echte gebruiker bent.

Iedere captcha die ik krijg vertrouwd mij dan ook nooit, Google's reCaptcha zijn de irritantste.

[Reactie gewijzigd door Caayn op 17 mei 2021 10:31]

Heb jij dan ooit in de gaten dat je geckecked wordt door een reCaptcha v3 ?

Ik gebruik overal in formulieren etc. reCaptcha v3 , daar zie je als gebruiker niets van. Echter hoe goed deze beveiliging is weet ik niet. Hij houdt in elk geval bij al mijn klanten de spam buiten. Implementatie is overigens ook heel makkelijk.

[Reactie gewijzigd door BruT@LysT op 17 mei 2021 13:04]

Met een gewone captcha kan een gebruiker niet gevolgd worden over browsers/devices/sessies heen.
Ik heb echt geen idee waarom je niet gevolgd kan worden met een captcha. Volgens mij gebeurt het ook op grote schaal gezien Google de grootste aanbieder is van re-chaptcha. Het zou het mij verbazen als het niet het geval zou zijn. Zie ook:
https://www.digitalinform...recaptcha-tracks-you.html

Met een fysieke sleutel wel.
Je hebt blijkbaar het artikel niet gelezen. Ze leggen heel uitgebreid uit hoe ze dit doen zonder de privacy te schenden. Zoals ik het lees kijken ze gewoon of je een fysieke (FIDO) sleutel hebt. Ze lezen daar enkel de fabrikant van uit. Is de fabrikant akkoord dan ben jij ook bewezen mens (als je de sleutel aanraakt)

The short version is that your device has an embedded secure module containing a unique secret sealed by your manufacturer. The security module is capable of proving it owns such a secret without revealing it. Cloudflare asks you for proof and checks that your manufacturer is legitimate.

https://blog.cloudflare.c...ttestation-of-personhood/
Lijkt mij vrij simpel. Als je handmatig een CAPTCHA invult weten ze niet dat jij het ben. Ga je dan naar je werk en doe je dat daar ook weten ze die 2 niet te linken.

Gebruik je echter een fysieke key zijn die 2 identiek op beide adressen/sites en dus hebben ze een profiel. Voeg wat cookies en meuk toe en tada.

Een key is dus minder privacy. Verder kunnen ze zoveel zeggen maar dat hebben we vaker gehoord.

[Reactie gewijzigd door computerjunky op 17 mei 2021 19:37]

Ze gebruiken niet de unieke sleutel van de key, maar de fabrikantsleutel. Die is per batch verschillend en een batch moet volgens de FIDO standaard minstens 100.000 sleutels bevatten. Ze weten dus niet wie van die 100.000 jij bent. Browsers kunnen afdwingen dat de site alleen de fabrikantsleutel mag benaderen. Het is niet volledig anoniem dus, maar er is toch wel over nagedacht.
Nee, Zie @Yggdrasil.

Het punt 'Je hebt blijkbaar het artikel niet gelezen.' heeft hier blijkbaar nogmaals toegeslagen..
Niets weerhoud de site in kwestie er van om gegevens te koppelen. misschien ben jij zo goedgelovig maar wfacebook had ook spontaan mijn telefoon nummer na overname van whatsapp en ook mijn mail addres stond ineens in een leak omdat een bedrijf was over genomen met gegevens die ze nooit hadden moeten hebben. Trackers en cookies worden zo zwaar misbruikt dat ik niet 123 geloof dat er niets gekoppeld word en er dus geen profiel opgesteld kan worden.

Maarja zolang anderen goedgelovig blijven blijven ze hiermee weg komen. Ik zal het in ieder geval niet gebruiken.

Ik block dermate veel trackers en vingerprinting en cookies dat veel sited verdommen te werken maar so be it. liever dat dan goedgelovigheid met alle gevolgen van dien.
Er is een nieuw privacy-first voorstel gemaakt door Cloudflare, een bedrijf dat bekend staat om zijn push naar meer privacy voor gebruikers, dat de markt kan verstoren die volledig beheerst wordt door Google, een bedrijf wat bekend staat om zijn push naar minder privacy voor gebruikers.

Maar nee, weer niet goed.... We kunnen niemand vertrouwen... Je moet ze niet geloven!
Ik word wel een beetje moe van sommige reacties maar ik raad je aan om die energie niet te stoppen in het klagen over een mooi initiatief maar om zelf met een goede oplossing te komen of dit huidige voorstel te verbeteren. Je kunt hiervoor terecht op de site van cloudflare (waarschijnlijk na het invullen van een chaptcha).
Je hebt blijkbaar het artikel niet gelezen. Ze leggen heel uitgebreid uit hoe ze dit doen zonder de privacy te schenden. Zoals ik het lees kijken ze gewoon of je een fysieke (FIDO) sleutel hebt. Ze lezen daar enkel de fabrikant van uit. Is de fabrikant akkoord dan ben jij ook bewezen mens (als je de sleutel aanraakt)
En hoe moeilijk is het om voor een bot om dit te simuleren?
Lijkt mij triviaal...
En hoe moeilijk is het om voor een bot om dit te simuleren?
Onmogelijk. Ten minste, in software. Als je hardware robots bouwt dan is het uiteraard te automatiseren.
Onmogelijk. Ten minste, in software. Als je hardware robots bouwt dan is het uiteraard te automatiseren.
We hebben het over een stuk software die moet detecteren of jij geen spammer bent op een computer die onder controle staat van de spammer. Waarom denk je dat je de USB connectie kunt vertrouwen?
Wat belet de spammer om een ‘softwarematig hardware sleutel’ te maken?
Ik denk niet dat je helemaal begrijpt wat Yubikeys zijn. Het hele ding met deze apparaten is dat je ze fysiek aanraakt. Pas dan reageert de key met een respons. Miljoenen mensen gebruiken deze dingen als tweede factor authenticatie, en het is letterlijk waar ze hardware- en softwarematig voor ontworpen zijn. Dus als dit 'gekraakt' zou zijn, dan is dit groot wereldnieuws.

Daarbij stuurt het authenticatie verzoek ook de cryptografische producent sleutel mee van het apparaat. Voor bijvoorbeeld deze oplossing van cloudlfare worden enkel nog de normale yubikeys geaccepteerd. Je zal dus niet alleen hardwarematig de touch functionaliteit moeten kraken maar ook de cryptografische sleutels van Yubikey moeten stelen. Want niemand accepteert zomaar onbekende 'sleutels'.

Google heeft 50000 (soortgelijke) keys uitgedeelt en heeft aangegeven sindsdien geen inbraken meer te hebben gehad (via medewerkers)
Zelfs het amerikaanse ministerie van defensie gebruikt deze.

Niets is uiteraard onmogelijk maar we praten hier over de wereldwijd veilig beschouwde oplossing (vrijwel defacto standaard) die bestaat uit hardware, software en zware cryptografie. De software is open-source dus ik zou daar beginnen als ik jou was. Maar ik denk (no offense) dat je nog steeds totaal geen kans maakt.
Ik denk niet dat je helemaal begrijpt wat Yubikeys zijn. Het hele ding met deze apparaten is dat je ze fysiek aanraakt. Pas dan reageert de key met een respons. Miljoenen mensen gebruiken deze dingen als tweede factor authenticatie, en het is letterlijk waar ze hardware- en softwarematig voor ontworpen zijn. Dus als dit 'gekraakt' zou zijn, dan is dit groot wereldnieuws
Ik begrijp echt wel wat een Yubikey is. Ik denk echter dat jij niet begrijpt dat ik bedoel dat een PC die gekraakt is door een spammer niet eens een Yubikey hoeft te hebben of dat ze deze lokaal zouden moeten hacken.
Het enige wat ze hoeven te doen is een key faken. Mocht je dat niet softwarematig kunnen (en ik denk dat dat kan), dan is een leuke manier een Yubikey via internet te verbinden: Gewoon een computer ergens (China?) met een verzameling Yubikeys en een laagbetaalde persoon die af en toe op een knopje drukt (als je dat al niet kan omzeilen door het knopje van de Yubikey te verbinden met een GPIO).
Timing in deze is, juist omdat de lokale gebruiker toch op een knopje moet drukken, compleet geen probleem en hergebruik van sleutels ook niet, omdat je vanwege privacy niet individuele sleutels wil herkennen.

Iets wat eigenlijk precies zoiets doet is de Host card emulation zoals deze op Android aanwezig is. Daar kan een App een NFC kaart emuleren.
Quote:
Host card emulation (HCE) is the software architecture that provides exact virtual representation of various electronic identity (access, transit and banking) cards using only software.
Dus we hebben hier een door Google in het Android OS ingebouwde manier om kaarten te emuleren, met:
HCE requires that the NFC protocol be routed to the main operating system of the mobile device instead of being routed to a local hardware-based secure element (SE) chip configured to respond only as a card, with no other functionality.
Dat klinkt niet echt veilig...
Kijk, uiteraard kun je een chinees ervoor zetten die op een setje yubikeys drukt maar dat kun je uiteraard ook door hem normale captcha's te laten ontcijferen.

Maar een key faken kan gewoonweg niet zomaar. Dit werkt op basis van certificaten. Als je naast de URL kijkt van Tweakers.net dan zie je dat deze een certificaat gebruikt. Jij kunt deze wel 'zien' en valideren dat deze inderdaad correct is. Maar jij kunt deze niet kopiëren of misbruiken. jij kunt niet zomaar even nadoen alsof jij een producent bent Yubikeys gezien jij niet de signing key hiervoor hebt..

Ik raad je aan om wat in te lezen over (publieke) certificaten. Ze zijn de basis van bijna alle encryptie en validatie methoden die we hedendaags gebruiken. Als dat te 'faken', emuleren of op een andere manier gekraakt zou zijn dan zou dat in 1 klap het gehele internet (en intranet) onveilig maken. Bankieren of inloggen op elke site zou onmogelijk zijn omdat er geen veilige verbindingen meer opgezet kunnen worden, VPN tunnels zouden open en bloot aan het internet staan. Het zou chaos zijn.
Omdat de machines dadelijk goed zijn, dat ze sneller die verkeerslichten en taxi's herkennen dan de mensen. Als machine learning nog een paar jaar zo snel doorontwikkelt als de afgelopen jaren, dan houdt de gemiddelde internetter dat echt niet meer bij, laat staan de minst begaafde persoon die toch echt wel een persoon is. Lijkt me goed dat voor te zijn, anders krijg je straks nog commerciële CAPTCHA ondersteuning voor mensen, op basis van machine learning 8)7
Tenzij die captcha geserveerd wordt van een domein van een zoekmachine/advertentieboer
Belangrijk om te vermelden is dat hier ook wat bedenkingen bij zijn, als het bijvoorbeeld om privacy gaat, maar ook om of het daadwerkelijk effectief is als het gaat om het tegenhouden van bots.
Belangrijk om ook te vermelden waarom ze dit doen. Momenteel gebruikt iedereen rechapta wat al sinds 2009 gratis door Google wordt verzorgt. Cloudflare is hier al eerder vanaf gestapt.

Privacy and Blocking Concerns
Since those early days, some customers have expressed concerns about using a Google service to serve CAPTCHAs. Google's business is targeting users with advertising. Cloudflare's is not. We have strict privacy commitments. We were able to get comfortable with the Privacy Policy around reCAPTCHA, but understood why some of our customers were concerned about feeding more data to Google.

We also had issues in some regions, such as China, where Google's services are intermittently blocked. China alone accounts for 25 percent of all Internet users. Given that some subset of those could not access Cloudflare's customers if they triggered a CAPTCHA was always concerning to us.

Over the years, the privacy and blocking concerns were enough to cause us to think about switching from reCAPTCHA. But, like most technology companies, it was difficult to prioritize removing something that was largely working instead of brand new features and functionality for our customers.
https://blog.cloudflare.c...om-recaptcha-to-hcaptcha/

[Reactie gewijzigd door dycell op 17 mei 2021 10:24]

Volgens Cloudflare zijn fysieke sleutels ook een privacyvriendelijkere manier van authenticatie, al geeft het bedrijf toe dat de oplossing niet perfect is. Zo weet Cloudflare nog steeds welke beveiligingssleutel en hardware een gebruiker heeft.
Dus de eerste zin is een leugen, Cloudflare weet dat en presenteert het als positief nieuws.

Idee leuk, want het gebruik van captcha's is verspilling van levensjaren. Maar dit alternatief is nog erger dan tracking cookies of "Federated Learning of Cohorts" / "Privacy Sandbox" van Google. Immens kun je iemand die zo'n fysieke beveiligingssleutel gebruikt ongeacht de browser noch machine overal tracken.

[Reactie gewijzigd door RoestVrijStaal op 17 mei 2021 10:00]

Nouja, een leugen gaat wel ver. Nergens in die zin staat 'de perfecte oplossing met absolute privacy', alleen 'vriendelijker'. De wereld bestaat nu eenmaal niet uit zwart/wit, ookal zou je dat tegenwoordig wel denken.

Ook 'verspilling van levensjaren' vind ik wel ver gaan. Het is een paar seconde waar je even iets in moet voeren, misschien moeten we als mensheid meer kijken naar die drang naar efficientie als blijkbaar een paar seconde wordt gezien als verspilling en iedereen maar een key moet kopen om dat sneller te laten gaan.
Ook 'verspilling van levensjaren' vind ik wel ver gaan. Het is een paar seconde waar je even iets in moet voeren, misschien moeten we als mensheid meer kijken naar die drang naar efficientie als blijkbaar een paar seconde wordt gezien als verspilling en iedereen maar een key moet kopen om dat sneller te laten gaan.
Bij mij heeft het altijd langer geduurd dan ÉÉN SECONDE.

En ja, als je Google Chrome gebruikt, krijg je bij ReCaptcha inderdaad meteen een groen vinkje dat 2 seconden duurt. Maar dat is ook omdat Google haar browser wil voortrekken (net zoals bij YouTube) en het is niet uit te sluiten dat Google haar browser gebruikt wordt om jou te tracken.

Met behulp van Privacy Pass (enkel voor WebExtension-browsers) was/is het mogelijk om hCaptcha van Cloudflare te omzeilen. In de praktijk wordt er voor iedere website dat Cloudflare gebruikt een extra HTTP header toegevoegd. (Hmmm klinkt ook als user tracking).

[Reactie gewijzigd door RoestVrijStaal op 17 mei 2021 10:44]

Door een volledig gebrek aan onderbouwing van welke claim dan ook voegt een dergelijke post in zijn geheel niets toe aan de discussie.

Wanneer je de extra verstrekte info van Cloudflare er bij pakt kun je zien dat de identificatie beperkt blijft tot batch niveau. Identificatie op sleutel niveau is theoretisch mogelijk maar ze geven aan dat ze dit niet gaan gebruiken en geven jou daarbij de info hoe je dit zelfs kunt voorkomen. Bij voorbaat roepen dat het erger dan Google's Privacy Sandbox is is daarmee dan ook onterecht.
Daarnaast hebben browsers als Firefox de mogelijkheid sleutel communicatie te anonimiseren, maar omdat mijn Solokey nog niet geaccepteerd wordt tijdens de testfase heb ik niet kunnen controleren of Cloudflare dit toestaat.

https://blog.cloudflare.c...personhood/#privacy-first

[Reactie gewijzigd door Forage op 17 mei 2021 10:33]

Waarom zou je geen bots kunnen draaien met fysieke beveiligingssleutels.

Op zich als je een niet al te grote website hebt hoef je helemaal geen zichtbare captcha's te hebben. Gewoon je input velden een verkeerde naam geven. En controleren of gebruikers wel het goede invullen.
Ws omdat die key dan gerevoked/geblocked wordt als er misbruik geconstateerd wordt.
Dat gaat niet want de unieke key wordt niet gecheckt. Er wordt volgens https://blog.cloudflare.c...ttestation-of-personhood/ gekeken of de key is uitgegeven door een vertrouwde producent. De hoogste nauwkeurigheid hierbij is het batchnummer van de productierun, en een batch moet volgens de FIDO spec minimaal 100.000 sleutels bevatten. Blokkeren van die sleutel blokkeert gelijk 100.000 potentiele andere bezoekers.

[Reactie gewijzigd door Yggdrasil op 17 mei 2021 14:28]

Loop je dan niet ook meteen tegen problemen aan met autoaanvullen?
Ik neem aan dat die ook kijkt naar die namen om de juiste data op de juiste plek te zetten.

Kan me voorstellen dat dat voor de gebruikers wel vervelend is
Dat kan inderdaad een probleem zijn. Deze strategie wordt vaak "honeypot" genoemd: extra invoervelden die voor bots interessant moeten lijken om in te vullen, en die voor echte bezoekers niet zichtbaar zijn. Staat er een waarde in zo'n veld, dan wordt de aanvraag niet gevalideerd. Extensies en apps die helpen met het invullen van formulieren, zoals wachtwoordmanagers, kunnen inderdaad ook de honeypot-velden gaan invullen en dan gaat de controle niet lukken terwijl je toch een echt mens bent.

Bovendien leren bots steeds beter herkennen welke velden honingpotten zijn, om dit trucje te omzeilen. Alle manieren waarmee je een veld onzichtbaar maakt, of buiten beeld plaatst, zijn ook wel automatisch te herkennen als er genoeg moeite wordt gedaan. Desnoods kan een bot simpelweg het formulier vele malen invullen en steeds één of meer velden leeg laten, om er zo doorheen te komen.

Deze denkrichting is waarschijnlijk niet de weg voor de toekomst. Of een fysieke sleutel dat wel is, evenals captcha-achtige oplossingen; ik weet het niet. Authenticatie en persoonlijke verificatie op internet blijft een enorm complexe uitdaging.

[Reactie gewijzigd door geert1 op 17 mei 2021 14:16]

Zo kunnen dan alle anonieme accounts gelinkt worden aan je sleutel, dag privacy…
Voordat je die aanname doet moet je toch het artikel even lezen. Cloudflare valideert of je key is gefabriceerd door een vertrouwde uitgever, niet de individuele sleutel van je key. Zo weten ze ten hoogste in welke batch je key geproduceerd is. Batches hebben een minimale grootte van 100.000 keys, volgens de FIDO spec (al houdt niet elke fabrikant zich daaraan).
Wat houdt spammers/hackers dan tegen om een key te kopen en deze te misbruiken om talloze inlogpogingen te doen?
Niks, alleen dat security keys handmatig geactiveerd moeten worden via aanraking. Dus ze moeten óf een robot bouwen óf ze elke keer met de hand activeren. Datzelfde kunnen ze nu ook met Captcha's al doen. Ik kan me voorstellen dat CloudFlare er ook een rate-limit op zet om dat deels tegen te gaan.
Gaat dit niet in tegen de privacy? Ik moet een key hebben en zo weer Cloudflare precies wie welke site bezoekt, dat gaat wat mij betreft een Cloudflare niets aan.
Maar cloudflare weet al lang welke website je bezoekt aangezien de website die je bezoekt via hun wordt geserveerd.
Als over b.v. VPN of tor gaat ben je met een ander IP ineens terug te herleiden naar een device met dat zelfde ID.
Dan nog is het herleidbaar aangezien je browser clientside ook nog wat dingen heeft om te kunnen tracken.

Maar hee als je dergelijke anonimiteit wil dan houd ik je niet tegen, het is alleen sowieso al verdraait lastig om dat voor elkaar te krijgen. Alleen VPN of tor is niet voldoende.
Waarom is dit een goede optie volgens jou? Hoe werkt dit? Naast dat het afhankelijk is van een app (en dus enkele van dezelfde nadelen als een security key) én een browser plugin zie ik in een oogopslag niet direct waarom ik dit zou kiezen als site bouwer of bezoeker.
Privacy gedachte even achterwege, kan iemand mij vertellen waarom bijvoorbeeld een script niet gebruik zou kunnen maken van zo'n USB key?
Bij fysieke sleutels moet iemand de sleutel op het juiste moment aanraken om hem te unlocken. Je zou natuurlijk een robot kunnen maken, maar een scriptje is niet genoeg...
Mooi zo, ik begon me steeds meer te ergeren aan websites die CloudFlare gebruiken.

De moeite die je moet nemen om een website te kunnen bezoeken slaat helemaal nergens op. Ik als goedbedoelde bezoeker is de dupe van misbruik van andere, daar heb ik geen zin in en ga ik wel naar een andere website.

Ik begrijp dat ze Recaptcha hebben laten varen vanwege de kosten, maar wat ze nu gebruiken is een low budget oplossing geworden wat echt merkbaar hinderlijk is.
De recaptcha is ingesteld door de website eigenaar, en niet cloudflare. Je hebt namelijk wat settings als je cloudflare gebruikt. Geen, een low, mid of high vorm van security en een "i'm under attack" setting wat juist die captcha laat zien.

Ik gebruik cloudflare ook, erg positief over, maar op sommige pagina's moet je gewoon een I'm under attack challenge voeren omdat het anders de perken uitloopt met bruteforce's, automatische registraties en toestanden (ook al heb je protectie op je form). Bedoel spammers kijken eenmalig mee met je formulier en passen hun scriptwerk daarop aan.
Volgens mij als je het niet instelt staat het op Mid en daarmee krijg je al snel de captcha.

En mocht je High instellen, wat prima is, zorg dan dat je het ook goed configureert dus bijvoorbeeld op je registratie pagina.. niet op een hele website enkel om wat tekst te lezen.

Je gaat gewoon echt je gebruikers wegjagen als je het niet goed configureerd.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee