Door Tijs Hofmans

Nieuwscoördinator

Beveiligingssleutels onder de loep

Wat kun je met deze fysieke securitykeys?

27-06-2020 • 06:00

228

Multipage-opmaak

Introductie

In simpelere tijden kon je je account beveiligen met een wachtwoord, en als het écht ging om gevoelige info, zoals je bankrekening, kon je daar ook nog een sms'je bij krijgen of een extra kastje bij gebruiken. Anno 2020 liggen er bijna dagelijks nieuwe wachtwoorden op straat, sta je als gemiddelde internetgebruiker in honderden of zelfs duizenden databases met je accounts en moet je je beveiliging iets serieuzer nemen. Dat doe je met een fysieke beveiligingssleutel, mits je je door het woud van protocollen heen kunt worstelen. We namen een handvol bekende en minder bekende beveiligingssleutels onder de loep en bekeken de verschillen.

Een fysieke beveiligingssleutel is een vorm van tweetrapsauthenticatie. Nog even een korte beschrijving van hoe dat ook alweer werkt: tweetrapsauthenticatie betekent inloggen met een tweede stap naast een gebruikersnaam-wachtwoordcombinatie. Die tweede stap kan een sms zijn of een code die je genereert op een apart apparaat, zoals een app op je telefoon of een van die kastjes die je bij sommige banken nog krijgt. Of, en dat is uiteindelijk de veiligste optie, je gebruikt een fysieke beveiligingssleutel.

Iets wat je hebt

Vorig jaar schreven we al een uitgebreid achtergrondartikel over de toekomst van wachtwoorden. Mark Risher van Google beschreef daarin het probleem met authenticatie. Ruwweg heb je drie manieren om te bewijzen dat jij de persoon bent die je zegt te zijn: met iets wat je weet, met iets wat je hebt en met iets wat je bent. Het 'weten' is in dit geval een wachtwoord, of een totp- of hotp-authenticatie, en wat je 'bent' wordt bijvoorbeeld gecontroleerd met biometrische identificatie.

Als je iets 'hebt', elimineert dat een heel groot gevaar: onderschepping op afstand. Een sms of andere code kan door iemand aan de andere kant van de wereld worden gestolen of gespooft, een sleutel niet. Zo'n beveiligingssleutel is iets wat je 'hebt'. Als je ergens inlogt met je gebruikersnaam en wachtwoord, moet je vervolgens ook nog fysieke toegang hebben tot een stukje hardware. Dat maakt het onderscheppen van die extra verificatie een stuk moeilijker.

YubiKey

Gemakkelijk in gebruik

De sleutels lijken in eerste oogopslag gemakkelijk in het gebruik. Bij een dienst die het ondersteunt, zoek je in de instellingen naar tweetrapsauthenticatie, de sleutel gaat in een usb-poort en ter verificatie klik je waar nodig nog op de fysieke knop op het apparaat.

Voor diensten die geen fysieke sleutels ondersteunen, en dat zijn er helaas nogal wat, kun je de sleutel soms koppelen aan een totp-app. De meeste sleutels hebben daarnaast nog een klein programmaatje waarmee je hier en daar nog wat aan je sleutel kunt configureren. Dat heb je niet altijd nodig, zeker niet als je de sleutel vooral gebruikt om in te loggen.

Zoveel sleutels, zoveel optiesEr zijn veel sleutels met veel verschillende functies

Als het gaat om securitysleutels komt YubiKey altijd als eerste naar voren. Hoewel hardwaretokens voor 2fa al jaren bestaan, heeft YubiKey het concept populair gemaakt bij een groter publiek. Toch bestaat er nog een handvol andere sleutels, allemaal met min of meer dezelfde functie, maar met andere formfactors. Zo zijn er de goedkopere SoloKeys, die na een succesvolle Kickstarter-campagne populair werden vanwege hun lage prijs, er zijn sleutels met ingebouwde vingerafdrukscanners, die eigenlijk een soort drietrapsauthenticatie zijn, en er zijn sleutels die je met pincodes moet unlocken.

Onder het motorkapje van de sleutels schuilt een wereld van inlogprotocollen die lang niet overal worden ondersteund, en van software die niet altijd op alle platforms werkt. In dit artikel kijken we vooral naar de verschillende sleutels met hun verschillende opties, voor welk doel ze handig zijn en hoe ze werken, maar ook welke protocollen beschikbaar zijn en hoe tweetrapsauthenticatie werkt. Dit artikel is geen review van verschillende sleutels; daarvoor is de selectie niet volledig genoeg en zijn er te weinig specifieke punten waarop de sleutels te beoordelen zijn. In plaats daarvan beschrijft dit artikel een aantal sleutels die je op dit moment kunt kopen, wat ze kunnen en wat ruwweg de verschillen daartussen zijn.

Overeenkomsten en verschillen

Voor dit artikel hebben we gekeken naar een aantal populaire sleutels die je op dit moment kunt kopen, met dank aan de input van verschillende tweakers op GoT. De sleutels in dit artikel zijn allemaal daadwerkelijk te koop via Amazon, bol.com of andere retailers, behalve Googles Titan Security Key. Die hebben we wel hier en daar genoemd in het artikel, omdat de sleutel van Google een van de bekendere is. Hij is echter alleen te bestellen via een omweg: de Duitse Google Store.

Sleutel Prijs Functies en ondersteuningen Overige sleutels
YubiKey 5 NFC €45,72 Usb-a, nfc, fido2 u2f, smart card piv, open-pgp, ssh, oath-totp/-hotp, YubiKey otp, challenge-response Usb-c, Lightning, vingerafdrukscanner, nano
SoloKey €20,- Usb-a, fido2 u2f Usb-c
Cryptokey OnlyKey €41,- Usb-a, nfc, fido2 u2F, pincode, ruimte voor 24 authenticaties, YubiKey OTP, challenge response, open-pgp, ssh, zelfvernietigingsfunctie Geen
Feitian K9 €32,- Usb-a, nfc, fido2 u2f, oath-hotp Usb-c, nano
Feitian BioPass K27 €72,50 Usb-a, fido2 u2f, vingerafdrukscanner, Usb-c, bluetooth
Kensington Verimark €44,77 Usb-a, fido2 u2f, vingerafdrukscanner, Geen
Google Titan Security Key €55,- Usb-a, fido2 u2f, nfc, bluetooth Usb-c

De sleutels die we voor dit artikel hebben gekocht, hebben in ieder geval één ding gemeen; ze ondersteunen allemaal fido2. Dat is een webstandaard voor tweestapsverificatie waarop we later in dit stuk dieper ingaan. Dit was de belangrijkste eis voor het testen van de sleutels, want fido2-sleutels zijn het meest toekomstvast. De fido-standaard begon in 2014 met fido 1.0, maar die versie bevatte al snel verschillende implementaties.

Aan de ene kant was er het universal authentication framework of uaf, bedoeld als wachtwoordvervanger om met alleen een uaf-apparaat zoals een sleutel te authenticeren. Een andere implementatie was u2f, ook universal 2nd factor genoemd. Daarbij wordt een sleutel of biometrisch gegeven gebruikt als tweede tweestapsverificatie. Gebruikers merkten weinig van de twee verschillende implementaties. Toch gaat het om twee wezenlijk verschillende dingen, waardoor de angst bestond dat het twee aparte protocollen zouden worden. Daarom besloot de FIDO Alliance om de twee, samen met nog enkele andere protocollen en standaarden, samen te vatten in fido2. Dat is dus een meer toekomstvaste standaard. Die kan tweetrapsauthenticatie verzorgen én wachtwoordloos inloggen, mits de dienst dat ondersteunt.

Prijzen

Voor tweetrapsauthenticatie via een app betaal je niets, hooguit een paar euro per jaar als je een totp-app gebruikt bij je wachtwoordmanager. Ook de sms'jes die je van sommige diensten krijgt, zijn gratis. Voor een beveiligingssleutel moet je wel de portemonnee trekken; meestal kosten ze enkele tientjes. De prijzen lopen flink uiteen; de goedkoopste SoloKey kost 20 euro, de duurste Feitian kost 72 euro.

Het kan slim zijn in een keer twee sleutels te kopen,
waarvan een als back-up
Het is per situatie anders, maar afhankelijk van je threat model is het slim om niet één maar twee sleutels tegelijk te kopen. Een berg je dan goed op, bijvoorbeeld in een kluis, voor het geval je de tweede, die je aan je sleutelbos hangt en met je meedraagt, onverhoopt kwijtraakt of als die stukgaat. Of je zo'n tweede sleutel nodig hebt, hangt vooral af van wat je ermee doet.

Als je hem puur en alleen gebruikt voor tweetrapsauthenticatie, is één sleutel misschien genoeg. Zorg dan wel dat je de back-upcodes van de dienst waarvoor je de sleutel gebruikt, goed bewaart. Die back-upcodes krijg je direct na het aanmelden van de sleutel en dienen als eenmalige inlogcodes voor als je je sleutel niet bij de hand hebt. Sommige securitysleutels, zoals die van YubiKey, zijn als bundel te koop voor een betere prijs, maar niet allemaal. Dat is dus iets om op te letten.

In eerste oogopslag lijken de sleutels soms veel op elkaar; het zijn simpele usb-sticks met soms een knop erop en meer niet. We keken naar sleutels met verschillende functies; met vingerafdrukscanners, nfc, en met pincodes. Ook intern kunnen de sleutels verschillende dingen, naast werken als 2fa-sleutel. Zo kunnen ze pgp-sleutels opslaan of wachtwoordloos inloggen.

De sleutels

YubiKey 5 NFC

YubiKey is een van de bekendere namen in de sleutelwereld. Hoewel fysieke beveiligingssleutels al jaren bestaan, maakte YubiKey ze populair bij een groot publiek. Eerdere sleutels waren vooral voor grote bedrijven interessant en hadden daarom propriëtaire protocollen en werkingen. Daar bracht het bedrijf Yubico verandering in. Niet alleen maakte het een sleutel voor commercieel gebruik, het was ook een van de ontwikkelaars van een nieuwe standaard voor tweetrapsauthenticatie.

Yubico verkoopt verschillende sleutels. De goedkoopste daarvan is een simpele u2f-sleutel: de Security Key, die ook met nfc wordt geleverd. De YubiKey 5-serie is interessanter. In de 5-serie zitten verschillende modellen met onder andere een usb-c- en een Lightning-aansluiting, maar belangrijker is dat ze naast u2f en fido2 ook andere protocollen ondersteunen, zoals voor smartcards en passwordless login, en dat je er open-pgp-sleutels op kunt opslaan. Daarom zit hier een YubiKey 5 bij, in dit geval met usb-a-aansluiting en nfc.

YubiKey heeft daarnaast een usb-c-sleutel en een sleutel met zowel usb-c als Lightning. Ook zijn er twee nanosleutels aanwezig met zowel usb-a als usb-c. YubiKey heeft een tool voor alle platforms om de sleutel te configureren en een totp-authenticatieapp voor zowel de desktop als mobiele platforms.

Yubikey en Feitian
De YubiKey 5 NFC en de Feitian K9

Feitian K9 en BiosPass K27

Beveiligingsbedrijf Feitian gaat al een tijdje mee en heeft een hele rits beveiligingsleutels. Het bedrijf biedt ze in alle soorten en maten aan, met usb-a, usb-c, nfc en bluetooth. De meeste van de sleutels ondersteunen fido2.

We hebben een Feitian K9 bekeken, een simpele fido2-sleutel die veel wegheeft van Googles Titan-sleutel en de YubiKey 5. Wat vorm betreft zijn ze bijna niet te onderscheiden. Feitian heeft ook de K35 met usb-c als alternatief. De sleutel heeft een fysieke knop voor validatie, maar is verder niet echt te programmeren met bijvoorbeeld pgp-sleutels.

Daarnaast hebben we de Feitian BioPass K27 bekeken. Die onderscheidt zich met een vingerafdrukscanner op de stick zelf. De K27 is erg stevig en de enige sleutel waarvan we durven zeggen dat hij het lang volhoudt aan een sleutelbos zonder veel beschadigingen. Veel andere sleutels, zoals de YubiKey, de K9 en de Titan-sleutel van Google, hangen met hun usb-aansluiting blootgesteld aan de sleutelbos en het is niet ondenkbaar dat dat een keer misgaat.

Het probleem van de Feitian K27 is dat die niet werkt met Google-diensten. Gmail herkent de vingerafdruk ervan niet en is daardoor niet te koppelen.

CryptoKey OnlyKey

De OnlyKey ziet er het interessantst uit. Hij heeft namelijk zes fysieke knoppen, die werken als een pincode. Als je de OnlyKey in een nieuwe computer gebruikt, moet je eerst een pincode invoeren om hem te gebruiken. Die pincode is ook nodig om de sleutel te configureren én om hem te wipen.

Ook is interessant dat je de toetsen op de OnlyKey kunt programmeren om er een specifiek wachtwoord aan te koppelen. Dat kan ook met andere sleutels, zoals de YubiKey en de Feitian, maar die hebben maar één knop en kunnen dus maar één inlog onthouden.

De OnlyKey kan daarnaast OpenPGP- en ssh-sleutels opslaan, en met de bijbehorende tool kun je er bestanden en berichten mee versleutelen. De OnlyKey heeft een handige tutorialtool waarmee je de sleutel kunt instellen. De tekst verschijnt daarbij in een tekstverwerker als je een knop indrukt.

De software van de OnlyKey is op Windows, macOS en Linux te gebruiken.

OnlyKey Cryptokey

SoloKey

SoloKey begon in 2018 als een populair Kickstarter-project. Uniek aan de sleutel was, naast de relatief lage kosten van 20 euro, dat de firmware volledig open source was. Ook de firmware van OnlyKey is inmiddels open source. Solo baseerde de firmware op de STM32L442KC-chip, maar die kan gemakkelijk naar andere chips worden geport. De SoloKey is alleen bedoeld voor fido2-logins. Je kunt er geen extra logins of pgp-sleutels op opslaan. Daarom is er ook geen app nodig voor je desktop om de sleutel te configureren.

SoloKey heeft verschillende sleutels beschikbaar, met een usb-a- en een usb-c-aansluiting. Beide zijn ook verkrijgbaar met nfc voor gebruik op een telefoon, maar er is geen bijbehorende authenticatieapp beschikbaar voor Android om bijvoorbeeld totp-codes te gebruiken met de sleutel.

De SoloKey is goedkoop en dat merk je ook aan de bouwkwaliteit. Die voelt veruit het minst stabiel aan van alle sleutels. Je krijgt wel twee rubberen hoesjes bij de sleutel om hem te beschermen, maar ook daarmee voelen de sleutels aan als breekbare usb-sticks die je liefst niet de hele dag aan je sleutelbos hebt hangen.

Solokey
Een SoloKey zonder het beschermende rubber

Kensington Verimark

De Kensington Verimark is vooral wat vorm betreft een wat vreemde eend in de bijt. Hij past namelijk niet aan je sleutelbos. De Verimark is een klein usb-stickje met usb-a-aansluiting. Die ondersteunt fido2-inlogs, maar heeft ook een vingerafdrukscanner. De Verimark heeft geen extra opties, maar werkt wel samen met inloggen via Windows Hello.

Kensinton Verimark

Google Titan Security Key

Google zet al jaren stevig in op de beveiliging van zijn diensten. De Titan-beveiligingssleutel is daar onderdeel van. Het is Googles eigen securitysleutel, in opvallende witte Google-kleur. De Titan-sleutel is officieel niet in Nederland te koop, maar met een omweg kun je er makkelijk eentje bestellen. Je krijgt dan twee Titans thuisgestuurd. Een is een standaard usb-sleutel zoals de YubiKey, met een fysieke knop om op te drukken. De ander is een draadloze sleutel, die vooral handig is voor mobiel gebruik. Die sleutel heeft een druppelvorm en een grote fysieke drukknop.

Deze sleutel werkt met bluetooth. Dat maakt de sleutel wat handiger in gebruik voor mobiele apparaten, al heeft de usb-a-sleutel ook nfc. De bluetooth-sleutel heeft ook een usb-aansluiting zodat je hem op de pc kunt aansluiten - micro-usb, dat dan weer wel. Daarnaast worden de sleutels geleverd met een usb-c-naar-usb-a-convertor.

Googles sleutels zijn alleen te gebruiken met fido2, je kunt ze dus verder niet programmeren of customizen.

Aansluitingen en formfactors

Securitysleutels hebben een moeilijk te doorgronden, maar rijke wereld aan ondersteunde protocollen en standaarden, met exotische namen als fido, u2f, otp en open-pgp. Uiteindelijk valt of staat de aankoop van een sleutel met de aansluiting. De meeste hebben een usb-a-aansluiting, handig voor computers, maar minder handig voor dat andere apparaat dat je vaak gebruikt: je smartphone. Aangezien veel gebruikers een wachtwoordmanager op hun telefoon gebruiken of een authenticatieapp met fido2-vergrendeling, is het wel zo handig als de sleutels daarmee werken.

Sleutelfabrikanten hebben nog geen goede oplossing voor dat probleem. Sommige, zoals SoloKey, bieden sleutels aan met usb-c, maar dan moet ook je pc usb-c hebben en nog niet iedere laptop of desktop heeft dat. Ook iPhones, met Apples propriëtaire Lightning-formaat, vormen nog een probleem. Een paar sleutelmakers, zoals Yubico, proberen daar iets aan te doen door een sleutel met Lightning-aansluiting te maken. Het bedrijf heeft zelfs een sleutel met Lightning- én usb-c-aansluiting.

Nfc

Voor veel Android-telefoons kom je met nfc ook een heel eind. Er zijn steeds meer sleutels, zoals de YubiKey, Feitian en SoloKey, die een kleine nfc-chip hebben ingebouwd zodat je ze gemakkelijk kunt gebruiken met een mobiele telefoon. Althans, een Android-telefoon.

Bij iPhones ligt het weer iets anders. Lange tijd hadden iPhones naast een gesloten ecosysteem een nfc-chip die niet bereikbaar was voor externe diensten, dus ook niet voor securitysleutels. Daarin is in recente versies van iOS verandering gekomen. Er zijn, zoals we hierboven al schreven, een paar sleutels met een Lightning-aansluiting. Die werken met iOS 13.3 of hoger, mits je de Safari- of Brave-browser gebruikt. Ook moet je een iPhone hebben boven de 7.

Fido2

We noemden hierboven al een paar keer Fido2 en het belang ervan voor securitysleutels. Fido staat voor fast identity online. Het is een webstandaard die door de FIDO Alliance in 2012 in het leven is geroepen. Grote internetbedrijven als Google, Amazon en Facebook, maar ook bedrijven als Samsung, VMware, creditcardbedrijven en banken, en securitybedrijven als Thales, Feitian en Yubico zijn erbij aangesloten.

Securitysleutels werken met asymmetrische encryptieFido werkt op basis van asymmetrische of public-key-encryptie. Dat betekent dat er een privésleutel en een publieke sleutel worden gebruikt. Als een gebruiker zich bij een dienst aanmeldt, maakt hij een nieuw sleutelpaar aan met een privésleutel en een publieke sleutel die aan de fido2-hardwarekey is gekoppeld. De publieke sleutel is geregistreerd bij de dienst waarbij de gebruiker zich aanmeldt.

Een sleutel moet vervolgens gevalideerd worden om te voorkomen dat iemand alsnog op afstand de privésleutel kan invoeren. Validatie verloopt in sommige gevallen door op de knop van de sleutel te drukken en in andere gevallen door er een pincode bij op te geven of een vingerafdruk te scannen. Dat wordt vervolgens lokaal geverifieerd en doorgestuurd naar de server.

Fido is niet één standaard, maar beslaat een hele reeks protocollen voor authenticatie. Dat zijn bijvoorbeeld vingerafdrukken, maar ook one-time passwords, trusted platform modules zoals die bij Bitlocker worden gebruikt, en nfc en bluetooth voor mobiele apparaten. Fido wordt ook gebruikt voor authenticatie via Windows Hello, en sinds deze week ook via Touch ID en Face ID in Safari.

Feitian
Sommige sleutels, zoals de Feitian, hebben een ingebouwde vingerafdrukscanner voor extra verificatie

Webauthn en ctap

Ook de fido2-standaard, die wachtwoordloos inloggen mogelijk maakt en over het algemeen gezien toekomstvaster is, bestaat uit verschillende protocollen. Daarin zijn er twee belangrijk: de W3C-standaard webauthn en het client-to-authenticator-protocol. Webauthn is een standaard voor in de browser waarmee diensten fido-authenticatie kunnen implementeren via een web-api. Webauthn zit inmiddels in alle grote browsers.

Fido2-sleutels ondersteunen twee belangrijke protocollen: webauthn en ctapHet client-to-authenticator-protocol is minstens zo belangrijk. Dat protocol zorgt ervoor dat een webauthn-dienst ook daadwerkelijk kan communiceren met een specifieke 'authenticator', zoals een beveiligingssleutel. Fido2-sleutels ondersteunen het ctap automatisch.

Wachtwoordloos

Fido2 maakt het mogelijk om sterkere authenticatie te maken. Belangrijker nog is het einddoel ervan: inloggen compleet wachtwoordvrij maken. Passwordless is al jaren een streven van de beveiligingsindustrie nu duidelijk is dat wachtwoorden ontoereikend zijn voor het inloggen bij diensten.

Praktisch gebruik en andere functionaliteit

Het gebruik van de meeste sleutels is relatief simpel. Vanuit bijvoorbeeld Googles beveiligingsinstellingen kun je een sleutel toevoegen. Die inpluggen en eventueel op de fysieke knop drukken of de vingerafdrukscan doen is dan al genoeg om een sleutel aan een account te koppelen.

Google Security Key

In de praktijk valt het praktisch nut tegen; nog maar weinig diensten ondersteunen de sleutels. Dat ligt niet aan de sleutels, maar aan de diensten, die in maar weinig gevallen fido2 volledig ondersteunen. Je kunt de sleutels vooral gebruiken bij grote diensten waarvoor veiligheid belangrijk is: Google, Dropbox, wachtwoordmanagers… Ook grote diensten als Twitter en Facebook kunnen met de sleutels overweg.

Op websites zoals twofactorauth.org heb je per dienst een goed overzicht van welke vormen van tweetrapsauthenticatie die ondersteunt. In veel gevallen wordt 2fa helemaal niet ondersteund, laat staan via een fysieke sleutel.

Zwakke schakels

Ook voor diensten waarbij de sleutels wel werken, geldt het probleem van de ketting en de zwakste schakel. Zo kun je bij Twitter wel een sleutel instellen voor 2fa, maar niet alléén een sleutel. Je moet altijd een back-upoptie opgeven, zoals een totp-app of sms-verificatie. Als je als potentiële inbreker de keus hebt om gewoon te wisselen naar een sms-inlog, dan heeft die sleutel weinig zin.

Je kunt met een sleutel ook een authenticatieapp beveiligen Voor diensten waarbij een fysieke sleutel niet werkt, maar je wel tweetrapsauthenticatie kunt instellen, voegt de sleutel alsnog iets toe. Je kunt bijvoorbeeld de Yubico Authenticator downloaden. Dat is een standaard totp-app zoals er tientallen zijn, maar wel een die met een sleutel te ontgrendelen is. Zo kan een eventuele aanvaller alleen bij je totp-codes komen als hij je sleutel heeft. Eerder dit jaar ging er malware rond die 2fa-codes uit authenticator-apps probeerde te stelen. Er zijn ook authenticator-apps voor de desktop die met een sleutel te beveiligen zijn.

One-time password

Bij webdiensten kun je vaak via de browser gebruikmaken van de webauthn-implementatie om in te loggen zoals hierboven. Je kunt echter ook een fysieke sleutel gebruiken voor bijvoorbeeld een offline wachtwoordmanager als KeePass.

Er zijn twee manieren om dat te doen. De gemakkelijkste is om een wachtwoord op de sleutel op te slaan. Dat kan bijvoorbeeld met de YubiKey, Feitian K9 en OnlyKey. Via de app programmeer je een wachtwoord in dat je vervolgens met een lange druk op de fysieke knop automatisch kunt laten aanvullen in een invulveld. De OnlyKey is daarin speciaal, omdat die zes fysieke knoppen heeft en daarmee zes van zulke wachtwoorden kan opslaan.

Yubikey Personalization
Met de Yubico-app kun je veel verschillende opties veranderen aan de Yubikey.

Daarnaast is het met de YubiKey mogelijk om een one-time password te genereren. Dat maakt gebruik van het oath-hotp-protocol via een bijbehorende plug-in voor apps als KeePass. Dat gebeurt via een externe provider, zoals OtpKeyProv, waarmee je je hotp-codes moet synchroniseren.

Pgp-sleutels opslaan

Op de YubiKey en wat andere sleutels kun je ook open-pgp- en ssh-sleutels opslaanSommige sleutels, waaronder de OnlyKey, YubiKey en Feitians, kunnen meer dan alleen inloggen via fido2. Die sleutels hebben bijbehorende apps voor de desktop waarmee het mogelijk is om andere vormen van authenticatie en encryptie toe te passen.

Zo kun je de YubiKey en de Feitian K9 programmeren om er privésleutels voor open-pgp of ssh in op te slaan. Die kun je in sommige gevallen direct in een programma of terminal plakken, maar ook via een Kladblok-bestand oproepen. Bij sommige sleutels, zoals de OnlyKey, kun je ook in de app zelf bestanden met diezelfde sleutel versleutelen.

Conclusie

Als je erover twijfelde om een securitysleutel te kopen, is er niet één antwoord op de vraag wat de beste is. Daarvoor hangt het te veel af van je gebruiksscenario en je threat model. Over alle sleutels die we hebben geprobeerd, zijn positieve en negatieve dingen te zeggen, op het clichématige af. De SoloKeys zijn goedkoop, maar beperkt in functionaliteit en voelen ook aan alsof ze een lage prijs hebben. De duurdere sleutels, zoals de YubiKeys, hebben meer functionaliteit en de Feitian K9 is steviger en heeft een vingerafdrukscanner, maar daarvoor betaal je uiteraard ook meer. Dan zijn er nog tientallen andere sleutels die je kunt kopen, allemaal met eigen functies.

Als je een sleutel overweegt, doe je er goed aan om eerst te kijken wat je er precies mee wil doen. Wil je hem alleen gebruiken om je accounts beter te beveiligen? Onderzoek dan vooral eerst of genoeg accounts die je gebruikt, een sleutel ondersteunen. Om je wachtwoordmanager te beveiligen is een sleutel een no-brainer, maar als je alleen je Facebook-account kunt beveiligen, is 50 euro veel geld.

Kijk ook naar je dagelijkse gebruik. Wil je een sleutel aan je bos die je dagelijks moet meezeulen of heb je liever een minisleuteltje dat niet opvalt in een usb-poort? Ook is het van belang welke smartphone je gebruikt en of die nfc heeft of overweg kan met fido2-keys. Anders kun je een bluetoothsleutel overwegen.

Als je een sleutel ook wil gebruiken om pgp-berichten te ondertekenen, dan kun je bij de YubiKey-, OnlyKey- en Feitian-sleutels terecht. Onthou in ieder geval goed: welke sleutel je ook kiest, het is beter er één te gebruiken dan helemaal geen.

Lees meer

Reacties (228)

228
225
127
7
1
90
Wijzig sortering
Goed om te zien dat Tweakers aandacht besteed aan Fido.

Een overzicht van key test kits die je kunt aanvragen van verschillende leveranciers.

https://authentrend.com/microsoft_pilot_program/
https://pages.yubico.com/MSFT-SI-Program.html

Trouwens voor B2B een hele belangrijke reden om over te stappen naar Fido tokens ipv OTP token afgezien van de technische kant is dat FIDO tokens geen batterij hebben.
OTP batterijen gaan ongeveer 3-5 jaar mee en daarna moeten ze vervangen worden dit probleem bestaat niet bij FIDO keys.

Sidenote : het gedeelte van Feitian heb ik eruit laten halen ivm feitelijke onjuistheden die het bedrijf verteld heeft toen ik aangenomen werd.

Hierdoor kan ik niet langer achter de producten staan en adviseer om een kijkje te nemen bij leveranciers gevestigd in Taiwan / Europa / Amerika zoals een Yubico en Authentrend.

Voor een volledige lijst kun je het vinden via onderstaande link:
https://fidoalliance.org/.../fido-certified-products/

[Reactie gewijzigd door Dirk op 22 juli 2024 15:29]

Ik was eerst heel blij met mijn Yubikey maar als je ze een tijdje in de kast laat liggen na gebruik werken ze niet meer. Dat is me al met meerdere keys gebeurd.

En dat is juist heel onhandig. Is je eerste 2FA stuk of kwijt, pak je de reserve fallback blijkt die stuk.

Dus tot dat het duidelijk is hoe zo'n key hersteld kan worden. Zijn ze voor mij waardeloos geworden omdat ik niet op het functioneren kan vertrouwen.
Dat is wel een serieuze klacht. Ik neem aan dat je dit bij Yubico support hebt aangekaart en ik hoor graag wat hun reactie was.
Reactie was dat gratis nieuwe kon krijgen..
Daar heb je dus op dat moment geen hol aan!

Over hoe lang 'in de kast liggen' hebben we het dan over? Wellicht is een x aantal maanden controle van oa. je backup keys wel belangrijk...
Ik ben het met je beide punten eens, maar het duidt ook wel op een enorm probleem met de QA van Yubico. De vraag is nu of dit een eenmalig incident was of dat dit vaker voor komt. Ik zit er al een tijdje over te denken om zelf een Yubikey aan te schaffen en na dit artikel van Tweakers was ik helemaal overtuigd, maar deze comment heeft me weer aan het twijfelen gebracht. Dat gaat weer een middagje Googlen worden ben ik bang...
Laat mij weten wat je tegenkomt, alsjeblieft. Ik ben ook bijna over!
Hier heb ik enige tijd geleden twee Yubikeys aangeschaft en in gebruik genomen. Tot nu toe tevreden mee en geen problemen mee gehad. Het kan natuurlijk wel handig zijn om bijvoorbeeld een halfjaarlijkse check te doen van je backup-sleutel, net als het handig is om je backups eens in de zoveel tijd te checken.

Voor m'n wachtwoordmanager heb ik ook een vrij lange backupcode op papier die ik kan gebruiken mochten beide sleutels het begeven. Dan heeft alleen m'n Google-account geen extra backup voor de beide beveiligingssleutels, maar daarvoor heb ik een paar vertrouwde apparaten. Voorlopig is dat goed genoeg zeg maar.
Ik heb een Yubikey jarenlang aan een sleutelbos gehad. Hij hing dus ook aan m'n fiets (ik heb alle sleutels aan 1 bos :o). Uiteindelijk leek het ringetje te verslijten (mogelijk mede het gevolg van een valpartij) en heb ik 'm maar naar een etui verplaatst. Maar voor een stuk techniek klaag ik echt niet over de kwaliteit van die yubikey.
Ik heb er 2, een yubikey 5c aan mijn sleutelhanger en een nano welke standaard in mijn MacBook Pro zit. Herken mij hier helemaal niet in. Ik gebruik de sleutelhanger variant zelden. Maar nooit problemen mee gehad.

Hiervoor had ik 2 USB-A varianten. Ook nooit problemen mee gehad. Ik kan ze sterk aanbevelen.

Overigens wil ik hier niet mee zeggen dat het probleem niet bestaat, enkel een ander perspectief geven voor @Petertjuh360 en @ari :-)

[Reactie gewijzigd door Jay-v op 22 juli 2024 15:29]

Ik herken dit probleem ook niet. Ik heb een yubikey die misschien wel 7-8 jaar aan mijn sleutelbos hangt en nog steeds probleemloos werkt. Ik gebruikte hem soms een jaar niet maar toch geen enkel probleem.

Heb vorige week toevallig een nieuwe besteld met NFC om het ook op mijn iPhone te kunnen gebruiken.

[Reactie gewijzigd door Yggdrasil op 22 juli 2024 15:29]

Hier tot nu toe ook geen problemen gehad, maar ik houd van backupmogelijkheden. M'n wachtwoordmanager bood zelf aan om een herstelcode aan te maken mocht het ooit wel met allebei de sleutels misgaan. Van dat stuk papier weet ik dat het over tien jaar nog netjes zonder problemen te lezen is, waardoor ik dus ook geen zorgen hoef te hebben wanneer de Yubikey aan m'n sleutelbos ooit op een dag de geest geeft.

Als ik geen vertrouwen had gehad in Yubikey dan had ik ze daar nooit gekocht, maar een stuk papier is nog steeds onverslaanbaar als het gaat om betrouwbaarheid. Maar de Yubikeys winnen het op gebruiksgemak.
Ik heb die klacht nog nooit voorbij zien komen de laatste 2 jaar bij Feitian.

Raad inderdaad aan om Yubico support te contacten.
Eigenlijk ook raar want volgens mij zit in een yubikey ook geen batterij dus die zouden ook geen probleem moeten hebben.
Dat zou dus betekenen dat het probleem de EPROM of whatever ze als opslag gebruiken het probleem is of gevoeligheid voor corrosie.
Alle usb en ssd opslag kunnen niet te lang zonder stroom (meestal 10-12 maanden?) om dataverlies te voorkomen. Ik neem aan dat dat met hardwaresleutels (er staat gewoon data op naar ik aanneem) niet heel anders ligt?
Ik heb meerdere keys in gebruik en heb dit nog nooit gehad. Je hebt vast hun troubleshooting-artikel doorlopen, ik ben benieuwd wat er dan precies niet werkt. Er zit immers geen accu in.
Stop hem in je device, hij wordt gezien, en dan gaat ie uit en reageert nergens meer op. LED gaat niet aan.

[Reactie gewijzigd door djwice op 22 juli 2024 15:29]

AuteurTijsZonderH Nieuwscoördinator @djwice27 juni 2020 14:01
Over welke periode heb je het dan, dat ie in de kast ligt? Een paar maanden, een jaar?
Enkele maanden net geen half jaar, helaas.
Ik was eerst heel blij met mijn Yubikey maar als je ze een tijdje in de kast laat liggen na gebruik werken ze niet meer. Dat is me al met meerdere keys gebeurd.
Ik heb 2 yubikeys (en een Feitian en een nameless) en ik herken dit niet. Een daarvan gebruik ik als standaard, de andere ligt op mijn werk als backup. Die laatste check ik af en toe (minder dan 1 keer per jaar) maar beide hebben nooit issues.
Ik heb al jaren een yubikey, eentje van de eerste generatie, maar wel een versie 2, iirc.
Een tweede yubikey in de familie is de backup key. En vice versa.
Zit sterk aan een NFC versie te denken.

Nooit problemen mee gehad. Sterker nog, NextCloud stelt iedere keer weer dat de yubikey login disabled wordt, want niet compatibel... En elke keer blijkt het gewoon te werken😇👍🏻
Ik hoop dat jou ervaring die van de meeste zal blijven en niemand het zelfde zal hebben als ik, waarbij de key gewoon niets meer doet als je hem in een USB poort stopt.
De yubikey login is disabled omdat die app outdated is, en niet veilig. Vooral omdat er een beter alternatief is die device agnostisch is, je hoeft dus niet perse de yubikey te hebben, het werkt met alle U2F hardware keys. Ik zou dan ook aanraden die app te gebruiken in plaats van de yubikey app. https://github.com/nextcloud/twofactor_u2f#readme
Dat is dus ook mijn angst.
Ik heb een hele goedkope Fido u2f stick en die werkt met alle diensten (die sleutels ondersteunen natuurlijk) perfect.
Ja, geen Fido2 dus maar dat maakt voor mij nog niet uit nu, meeste diensten zijn nog u2f op het moment. Ik heb dan inderdaad mij telefoon met sms altijd als backup ingesteld. Is de key kwijt, dan kan ik ng gewoon inloggen en een nieuwe key koppelen. De key invoeren en op de knop drukken is voor mij makkelijker dan een code uit een sms overtypen, dus ik heb de key in dat opzicht voor het gemak. En met key/sms is altijd nog veel veiliger dan zonder, dus het is een compromis inderdaad.
Ik zou willen dat een Yubikey of andere sleutel een soort van master password zou hebben waarmee de chip erin te backuppen is, zodat je dat regelmatig kan doen en ‘m dan kan herstellen naar een nieuwe. Ik begrijp ook wel waarom dat niet bestaat, maar vanuit mijn kant gezien is dat wel heel erg wenselijk. Twee keys koppelen is gewoon te duur eigenlijk en ook een risico zoals hier wordt aangegeven. Was het een echte Fido2-login dan kun je er zonder key nooit meer bij.
En ja, van mijn belangrijkste bestanden heb ik ook meer dan 1 backup en op verschillende plaatsen. En ook dat is een probleem met 2 keys, ze zijn ‘s nachts gewoon beide in huis.
Wat is het voordeel van een fysiek stickje t.o.v google authenicator?
Voor consumenten? Weinig

Simpelweg omdat de meeste consumenten hun mobiel toch altijd bij hun hebben.

Voor bedrijven is het een heel ander verhaal. We zien veel gevallen waar medewerkers zeggen : Geef me maar een bedrijfstelefoon ik ga me persoonlijke producten niet gebruiken voor het bedrijf

Bedrijfstelefoon zelfs een goedkope zit je al op de honderd euro echter kun je met een key al voor 10 USD klaar zijn.

-Geen BYOD
-Er zijn bedrijven waar een mobiel sowieoso niet naar binnen mag

Voor een CISO is het natuurlijk ook heel simpel : Ik geef ze een key en ik kan laten zien aan de board dat phishing helemaal afgedekt is in het bedrijf.
Het enige nadeel is dat als iemand anders zo een key heeft, hij deze kan gebruiken. In mijn ervaring is een missend mobieltje eerder ontdekt dan een (hardware) key. Ze zijn in iedergeval een heel stuk kleiner dan die RSA keys waar ik vroeger mee moest rondlopen...
1: Niet biometrisch heeft een pincode dus hij moet dan ook je pincode weten
2: Biometrisch dan moet die je vingerafdruk bemachtigen

OTP Tokens is inderdaad een ander verhaal aangezien je bij die inderdaad alleen de OTP code hoeft over te tikken ( alhoewel wij die ook hebben met pincode beveiliging erop).

Klopt dat mensen eerder merken als een mobieltje weg is, echter is dat relatief aangezien de meeste keys die wij verkopen comfortabel aan sleutelbos hangen en in je zak.

Veel mensen laten hun sleutelbos niet op tafel liggen op kantoor plus als iemand jouw mobiel pakt dan kan die nog met het argument komen : Oh ik dacht dat het mijn mobiel was
als iemand jouw sleutelbos meeneemt dan werkt dat argument niet :+

Uiteindelijk zijn beide oplossingen beter dan niks en voor de zakelijke kant zijn hardware keys goedkoper dan voor iedereen een mobiel aanschaffen.

Echter mochten ze al een werktelefoon hebben dan is software zeker weten een goedkopere oplossing alleen zijn er niet heel veel bedrijven waar iedereen een werktelefoon heeft.

Wat je ook ziet is een combinatie : Software voor mensen met werk telefoon , hardware key voor andere medewerkers
Echter mochten ze al een werktelefoon hebben dan is software zeker weten een goedkopere oplossing alleen zijn er niet heel veel bedrijven waar iedereen een werktelefoon heeft.
Ik vermoed dat een telefoon van de zaak vanaf heden steeds vaker voor gaat komen ivm. bredere adoptie van thuiswerken. Dat is natuurlijk niet geschikt voor elke job
Ja klopt echter zijn er genoeg medewerkers die wel authenticatie nodig hebben voor thuiswerken maar eigenijk geen mobiel van de zaak. Zoom/Teams kan ook via je laptop.

Dan is het voor veel ICTers interessanter om voor te stellen om voor paar tientjes keys aan te schaffen. Want je kunt er ook vergif op in nemen als je met een 100 euro mobiel aankomt je ook gezeur krijgt
Nope, bij volledig passwordless gebruik heb je een pincode en de key wordt na enkele pogingen geblokkeerd. Een van de redenen dat het belangrijk is een tweede te hebben als backup!
Ik bedoelde het inderdaad voor mijzelf. Wat je zegt over bedrijven is helemaal waar. Het is natuurlijk raar om een autenticator van je bedrijfsaccounten op je prive mobiel.
Hier is dat standaard, dat werd helaas als 'de manier' gepresenteerd en gaf bij mij wat weerstand. Ik heb toen twee jaar een codegenerator aan m'n sleutelbos gehad, maar toen die voor de tweede keer leeg was ben ik toch maar over gegaan naar m'n telefoon.
Het gebruik is met zo'n stick wel een stuk handiger dan een OATH-TOTP authenticator app (of dongle, je hebt deze ook in dongle vorm).

Je moet de mobiel pakken, de app openen, juiste code opzoeken en daarna de code overtikken. Bovendien blijft dit een tweede factor, dus je hebt voor deze stap al je gebruikersnaam en paswoord ingetikt.

Met Fido2 heb je de login prompt van de website. Je voert de stick in, voert de pincode in (die steeds hetzelfde is dus je hoeft niks op te zoeken), raakt de stick aan en je bent ingelogd. Niet eens een gebruikersnaam meer nodig!
Ik begrijp je punt wel in verband met het nut voor consumenten tov een Google Authenticator, maar toch denk ik dat het misschien iets genuanceerder is?
Sinds kort gebruik ik Bitwarden als password manager. Deze kan ook OTP codes genereren en heeft zelf ook enkele mogelijkheden om de Bitwarden vault te voorzien van 2FA (zoals OTP, key, email, ...).
Daarbij zie ik toch een scenario waar een key een oplossing is. Tenzij ik iets mis? Dan hoor ik het graag! :-)
- Ofwel laat ik mijn OTP codes genereren door Bitwarden, maar dan kan ik uiteraar moeilijk Bitwarden gebruiken om zijn eigen OTP code te beheren... Daarbij lijkt het best om iets anders te kiezen: een key of een andere authenticator.
- Ofwel laat ik mijn OTP codes genereren door een andere app zoals Duo, Authy, Google Authenticator, ... en daar dus ook mijn Bitwarden OTP door laten beheren.

De authenticators die het toelaten om deze te restoren bij het overzetten naar een andere telefoon (door verlies of gewoonweg door niet meer functioneren), hebben uiteraard ook een wachtwoord nodig, die ik dan in Bitwarden zou zetten. Daarbij is er een soort kip-of-ei probleem bij een volledige restore. Bitwarden nodig om een login te doen om authenticator te herstellen en authenticator nodig om in Bitwarden te geraken (indien OTP gebruikt is als second factor).

Daarbij lijkt het mij makkelijkst om Bitwarden te beveiligen met een key. Dat lijkt mij het veiligst én doorbreekt het kip-of-ei scenario van hierboven. Los daarvan kan ik dan nog altijd kiezen om Bitwarden mijn OTP codes te genereren of een andere authenticator gebruiken waar Bitwarden het wachtwoord van beheert voor een eventueel herstel indien mijn telefoon het begeeft, verloren geraakt, ...

[Reactie gewijzigd door Eejs op 22 juli 2024 15:29]

Er is nog een derde optie: een stuk papier. Neem een OTP-app die synchroniseren toestaat en zet het wachtwoord in Bitwarden en op een stuk papier. Dat stuk papier gooi je in je kluis samen met je diploma's en dat soort spul. Het enige moment dat je het wachtwoord nodig hebt is wanneer je je OTP-app over wilt zetten naar een nieuw device. Als op dat moment je oude device functioneert dan kun je daarmee Bitwarden openen. Als je oude device niet functioneert dan kun je het wachtwoord van je fysieke stuk papier halen om je OTP-app werkend te krijgen.

Qua veiligheid valt de impact wel mee, want je OTP-app is eigenlijk de fysieke factor net zoals een stuk papier dat is. Je draagt het stuk papier niet overal met je mee naartoe, maar het blijft een fysiek object dat een aanvaller in handen zou moeten zien te krijgen.
Sterker. Authenticatie genereert one time passwords van 6 cijfers, de yubikey doet 64(? of 32) willekeurige letters en cijfers.
Dat levert een hogere entropie, wat kragen lastiger maakt.
Anoniem: 368883 @Zyphlan27 juni 2020 15:17
Zijn jullie biometric keys ook compatible met PGP-smartcard (zoals YubiKey) ?
Moest het even navragen Sith ( sorry voor de late reactie).

Nee biometrisch heeft niet PGP echter technisch is het mogelijk dus als we een klant hebben die de aantallen nodig heeft kan het door R&D toegevoegd worden.

Feitian heeft 1000+ man personeel waarvan ongeveer de helft R&D echter moet ik wel kunnen verdedigen waarom PGP toe te voegen ( of laten zien dat er vraag is vanuit de markt , of een klant al klaar hebben die wil bestellen).

De vraag PGP komt aan de b2b kant weinig voor ( heb volgens mij vorig jaar 1 mail binnen gehad die erom vroeg maar ging om 100 stuks ofzo max).

Echter over 1-2 maanden komt de nieuwe K9C uit ( deze heeft alle mogelijkheden die de Yubikey 5 NFC ook heeft).
AuteurTijsZonderH Nieuwscoördinator @Zyphlan27 juni 2020 13:58
Goede toevoeging! Ik heb gewoon de links van de Feitian-website zelf gepakt inderdaad, waar vind ik buiten deze screenshot om een beter overzicht?

De K27 Biopass die ik heb gekocht is wel Fido2 maar ik kreeg em niet geauthenticeerd met Google, wel met andere diensten. Ik weet niet precies waarom dat is maar zag dat probleem op forums vaker voorkomen - iets met Google dat met die vingerafdruk niet herkent. Dat lijkt nu ik er beter naar kijk meer een Google-probleem te zijn dus dat verhelder ik iets meer!
Re: Praktisch gebruik
Via de app programmeer je een wachtwoord in dat je vervolgens met een lange druk op de fysieke knop automatisch kunt laten aanvullen in een invulveld.
Wat je ook kunt doen is een deel van het wachtwoord op bovenstaande manier opslaan en laten invullen, en vervolgens zelf handmatig het laatste deel aanvullen. Bijvoorbeeld: een wachtwoord van 55 tekens. Sla de eerste 49 op en onthoud de laatste 6. In het geval de sleutel zoekraakt, vermindert het risico dat het (gehele) wachtwoord daarmee ook automatisch in verkeerde handen kan vallen. Net als bij de conclusie van het artikel hangt het er maar net van af hoeveel zorgen je je hierover zou denken te moeten willen maken.
je weet dat lengte of complexiteit totaal niet uit maken voor een breach.

Het tijdperk van password less is aangebroken en het wordt tijd dat sites dat gaan accepteren en implementeren.

Tweakers loopt wat dat bedreft sterk achter met nog geen MFA,, en IP bases sessie logins , Zero trust is wat we tegenwoordig doen een IP is geen factor voor authenticatie.
Lengte en complexiteit maakt zeker uit voor de meeste breaches, aangezien de databases met hashes verkocht worden en de meeste hackers geen moeite te nemen de raw passwords te dumpen terwijl ze toegang hebben tot de website. Om brute-forcen tegen te gaan moet je nog steeds een goed wachtwoord hebben, een wachtwoord dat lang en willekeurig is.

Ik zou graag MFA willen zien bij tweakers, het liefst ook verplicht of desnoods aangeduid met een speciale badge bij vraag&aanbod zodat je weet dat gehackte accounts onwaarschijnlijk zijn, maar sessies op IP filteren is op zich een prima maatregel om de meeste sessie-kaapaanvallen te weerstaan. Het is een aanvulling op de veiligheid van de authenticatieprocedure, geen losse beveiliging op zich.
je weet dat lengte of complexiteit totaal niet uit maken voor een breach.
Dat spreekt voor zich, maar daar gaat mijn reactie toch ook helemaal niet over? Het is nogal wiedes dat het niets uitmaakt hoe sterk een wachtwoord is of hoe (veilig) je dat zelf bewaart als het op een andere manier, bijvoorbeeld door een lek bekend wordt.
Uuh jawel, lengte en complexitijd zijn zeker belangrijke factoren. Hoe langer en complexer, hoe moeilijker de hash te kraken is.
Ja alleen kraken we hashes niet wat dat is zo goed als onmogelijk dus daarvoor is het totaal onbelangrijk,

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

Hashes worden aan de lopende band gekraakt.
Je kunt een hash niet kraken !!, er is geen enkele bekende exploit om een hash algorithm te kraken,

Wat een attacker doet is een dictionary attack of gewoon een brute force hash compare, maar voor beide maakt het totaal niet uit wat voor paswoord of hoelang het paswoord is omdat het gewoon trial en error is.

Als jouw paswoord 40 chars lang is zijn er wel meer combinaties mogelijk maar dat maakt het niet meer of minder sterk voor de brute force dan wanneer jouw paswoord maar 2 characters lang is. De attacker weet dit nl niet dus hij zal alles moeten proberen. Daarnaast kun je een DB opslaan met known hashes en daar een comparison op doen (Dis is wat Azure bijvoorbeeld doet met know and stolen pasw.)
Je kunt een hash niet kraken !!, er is geen enkele bekende exploit om een hash algorithm te kraken,

Wat een attacker doet is een dictionary attack of gewoon een brute force hash compare, maar voor beide maakt het totaal niet uit wat voor paswoord of hoelang het paswoord is omdat het gewoon trial en error is.

Als jouw paswoord 40 chars lang is zijn er wel meer combinaties mogelijk maar dat maakt het niet meer of minder sterk voor de brute force dan wanneer jouw paswoord maar 2 characters lang is. De attacker weet dit nl niet dus hij zal alles moeten proberen. Daarnaast kun je een DB opslaan met known hashes en daar een comparison op doen (Dis is wat Azure bijvoorbeeld doet met know and stolen pasw.)
Natuurlijk maakt het wel uit hoe lang dat password is. Je spreekt jezelf echt 100% tegen. Zowel voor dictionary attacks als voor brute force gaat dat een stuk langzamer resultaat opleveren wanneer het password van voldoende lengte is. Alle combinaties uitproberen tot maximaal 6 lengte is bijv. bijna triviaal tegenwoordig.
Bij een brute force of dictionary attack ga je idd alles proberen. Maar je mist echt een essentieel stukje.
Hoe langer je wachtwoord, hoe groter het aantal mogelijkheden je moet proberen / berekenen om te zorgen dat je het juiste wachtwoord probeert. Het aantal mogelijkheden neemt snel toe met elk karakter wat je toevoegd. Een wachtwoord met 10 tekens is al veel moeilijker te gokken / berekenen dan een wachtwoord met 8 tekens.
Je denkt verkeerd,

in bijde gevallen hoef je nl maar 1 hash te berekenen.

Verder kun je bijna niks over de kans zeggen dat iemand het goed raad.

Als ik een brute force laat lopen over een max tot 100 characters max length dan heeft elke mogelijke combinatie dus even veel kans gezien ik niks weet van het paswoord.

Wat jij doet is denken dat ik weet hoelang een passwoord is en dan gaan brute forcen op die combi maar dat weet een attacker niet dus hij zal nooit een brute force starten op 6 chars bijvoorbeeld. Maar altijd een brute force op max pasw lenght , en dan ligt het maar net aan het algorithme en de async van het programma,

Example ik start 1 async task per combi tot 6 letters , 5 tasks per combi tot 12 letters, 10 tasks per combi tot 15 letters , 25 tasks per combi tot 20 letters,

Er is dan totaal geen verschil in te zeggen wie het eerder vind een 5 letter pasw of een 15 letter pasw.


Jouw zou het net als bitcoin kunnen zien, de moeilijkheids graad is inmiddels factor duizend alleen toch wordt het nogsteeds binnen elke 10 min de juiste hash gevonden.

Maar de echte reden is toch wel dat een attacker vaak niet eens meer een brute force doet omdat er geen hammering meer wordt toegestaan, X keer lockedout. Nee een hacker gaat direct voor de Database en haalt gewoon jouw hash (of plain text pasw) gewoon uit de database en authenticeert met die hash direct. Kortom het intereseert hem totaal niet wat er eigenlijk in die hash staat of hoe sterk die is.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

Je hebt de klok wel horen luiden maar je weet niet waar de klepel hangt. Leg dit eens voor op een serieus forum als security.stackexchange.com als je er daadwerkelijk voor open staat om te leren.
wat is er volgens jouw fout dan ? je geeft nu iets aan zonder enige vorm van uitleg.


Zoals op Jouw forum:

https://security.stackexc...-website-crack-md5-hashes

je kunt een hash niet kraken , bruteforce != Kraken !!!

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

wat is er volgens jouw fout dan ? je geeft nu iets aan zonder enige vorm van uitleg.


Zoals op Jouw forum:

https://security.stackexc...-website-crack-md5-hashes

je kunt een hash niet kraken , bruteforce != Kraken !!!
Ik wil niet op semantics ingaan want daar gaat het helemaal niet over. Er is best te stellen dat brute forcen JUIST kraken is. Laten we in ieder geval uitgaan van dat dit de intentie was van de mensen die boven je reageerden. Dit is overigens ook wat gezegd wordt in de link naar de vraag waar je nu zelf mee komt.
Ik zeg ook niet dat de hashfunctie te reversen is en dat beweren zij ook niet. Maar het maakt wel degelijk uit hoe lang het password is. Kort gezegd wat zowel ik als Spiceworm hierboven al zeggen maar wat jij ontkent.

Spiceworm zegt bijv: "Bij een brute force of dictionary attack ga je idd alles proberen. Maar je mist echt een essentieel stukje.
Hoe langer je wachtwoord, hoe groter het aantal mogelijkheden je moet proberen / berekenen om te zorgen dat je het juiste wachtwoord probeert. Het aantal mogelijkheden neemt snel toe met elk karakter wat je toevoegd. Een wachtwoord met 10 tekens is al veel moeilijker te gokken / berekenen dan een wachtwoord met 8 tekens."

Dit klopt gewoon. Het maakt niet uit of je jouw taken async start of niet, het berekenen van die hashes op basis van de wachtwoorden kost simpelweg processor cycles. Het is inderdaad zo dat het wachtwoord '123456' net zo lang kost om te hashen als '123948081098jsdgjkhsdkjht3'. Maar dat is het punt niet. In de adresruimte van 6 tekens zitten véél minder combinaties dan in de adresruimte van 26 tekens. Als je alle combinaties van 6 tekens probeert te hashen ben je daar zo. Maar die van 26 tekens gaan je ontzettend veel tijd kosten.
Stel je voor dat een pincode maar uit 1 cijfer zou bestaan. Hoe lang kost het je dan om bij een pinautomaat alle combinaties te proberen, en hoeveel groter is de kans dat je het goede cijfer hebt voordat het pasje wordt ingeslikt na 3 pogingen ten opzichte van 4 cijfers, oftewel 10000 combinaties in plaats van 10?

Daarnaast (maar eigenlijk irrelevant hiervoor) klopt "en authenticeert met die hash direct" ook niet. Je kan niet zomaar de hash opsturen naar een server want dan gaat ie de hash hashen en daar komt weer iets heel anders uit.
bij brute force kraak je niks omdat je niks misbruikt nog inject je vult immers gewoon het juiste pasw in. Dit is de zelfde mistake als vele maken tussen de woorden hacker en cracker. Een hacker maakt niks stuk.

Vertel me nu eens hoe jij weet dat een paswoord 6 chars lang is want in jouw statement weet je dat dus blijkbaar want je probeert alleen die combinaties.

Omdat je de lengte niet weet als attacker ga je de uit van de maximale lengte bij een brute force en bereken je alle mogelijke combinaties voor al die lengtes en maakt het dus niet uit of het password 5 of 30 lang is want je moet toch all 1..30 lengtes proberen.

Hence de statement het maakt helemaal niks uit voor de attacker omdat je de blokken opdeelt in evenlang durende cycli. Elke cycli heeft een bepaalde processing tijd en een van die cycli gaat je de goede oplossing geven.

Alleen als een attacker van te voren weet dat jij 6 char pasw gebrukt is hij weaker omdat een attacker dan alleen de 6 serie hoeft te proberen. In dat zelfde geval als jij een 15 lenghte pasw gebruikt hoeft de attacker 1..14 en 16..30 niet te testen en zou je een statement kunnen maken dat hij meer werk moet verzetten en het veiliger is. Maar zodra een hacker weet hoe lang jouw ww is heeft hij waarschijnlijk je WW al via een keylogger en hoeft hij niet te brute forces.

Oftewel Als jij een 6 char paswoord heb bij een max lenght van 30 dien je 30 tot de macht van 26 (uitgaan van alleen kleine letters) combinaties te testen

Als jij een 30 char paswoordt hebt bij een max length van 30 dien je 30 tot de macht van 26 (uitgaan van alleen kleine letters) combinaties te testen.

volgensmij is dat toch echt de zelfde aantal die je totaal moet testen als je geen geluk hebt en het de laatste is.


Verder is dit natuurlijk in perspectief omdat je bij authenticaties die meer dan +-12 chars (met complex) toestaan je over boundries gaat dat hele luxe hardware nodig is het idd zo dat een nog langer paswoord sterker is. alleen juist daar gaat niemand een brute force attack doen maar zoekt met eerder naar exploides zoals PTH zoals ik al eerder zij waar je gewoon de hash gebruikt om te authenticeren. Of ADFS replay attack, collision attacks etc etc..

Nu je weet dat attacker dus liever uitwijken naar keylogger, DC controle, PTH, DB`s zonder hash etc, pasw replay etc maakt het dus totaal niet meer uit wat je paswoord ook is, hence de hele movemnet voor password less authenticatie. Het pasw in zijn huidige vorm is per definitie niet meer secure en gaan we naar een alternatief MFA logon toe icm oplossingen als windows hello.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

Sorry maar je snapt het gewoon niet of wil het niet snappen. Ik kan het niet beter uitleggen dan ik al heb gedaan. Je snapt dat als je eenmaal een match hebt met de hash, je dan kan stoppen met het proberen van alle andere hashes hé?

"Dit is de zelfde mistake als vele maken tussen de woorden hacker en cracker. Een hacker maakt niks stuk."

En jezus, dit soort eeuwenoude quotes gaan wederom alleen maar om semantics. En is ook erg discutabel want het begrip black hat hacker is nu ook een begrip.
jij lijkt niet te snappen dat een brute force niet van a-z loopt of je wilt het niet snappen, en zoals gezegt doet men meestal geen brute force over large pasw omdat dat veel makkelijker kan.
jij lijkt niet te snappen dat een brute force niet van a-z loopt of je wilt het niet snappen, en zoals gezegt doet men meestal geen brute force over large pasw omdat dat veel makkelijker kan.
Volgende editie van https://en.wikipedia.org/wiki/Observe._Hack._Make. leg ik het je wel in real life uit, dit is zinloos. Ik programmeer al 25 jaar, denk dat ik wel weet hoe dit werkt.
dus in 25 jaar tijd heb je nog nooit gehoordt van paralel processing of async workers vreemd .

Ik verzin het niet staat gewoon in de publieke Wiki
https://nl.wikipedia.org/wiki/Brute_force_(methode)

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

Jongen je hebt wel wat woorden opgepikt af en toe maar het is duidelijk dat je ze nog nooit in de praktijk hebt toegepast. Je doet je naam, al geen compliment, er nog niet eens eer aan. Ik schrijf elke dag parallel processing code maar dat is geen magisch medicijn waardoor processoren opeens oneindig snel zijn. Veel succes met als expert posen verder, ik ben er klaar mee.
Dat claim ik toch ook helemaal niet je moet nu niet allemaal dingen gaan verzinnen en nu terug vallen op beledigingen is niet echt netjes.

En als jij ook parallel code schrijft weet jij donders goed dat je paralel taken op hakt in verwerk bare blokken en dat is precies wat ik zeg niet meer niet minder.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 15:29]

idd, en net daarom wordt een hash ook bij regelmaat herberekend zodat ze beperkt zijn in tijd om die te kraken.
Veel succes met brute forcing sha256 of sha512
I.p.v. een securitykey kan je ook een gogole authenticator gebruiken. Daarnaast een blaadje met 10 reserve codes afdrukken en klaar.
En het blaadje in een kluis bewaren bij de bank
In mijn ogen altijd nog beter dan op een vreemde cloud server aan de andere kant van de wereld -beheerd door een natie met andere privacywetten- opslaan.
Mijn Yubikey heeft als tweede 'slot' een statisch wachtwoord, en dat gebruik ik op deze manier. Het eerste deel is een sterk wachtwoord, het tweede deel komt uit mijn key. Ik gebruik deze strategie bijvoorbeeld voor de encryptie van de harddisk van mijn laptop, toegang tot mijn password manager (keepass). Ook voor root wachtwoorden van mijn servers trouwens (waar ik normaal alleen SSH public key auth gebruik natuurlijk, het is meer voor incidentele fysieke toegang)
AuteurTijsZonderH Nieuwscoördinator @zonder.h27 juni 2020 14:02
Dit is inderdaad een goede tip ja, zeker als je de key zelf niet verder hebt beveiligd met een pin of zo.
Ik heb al 10 jaar ervaring in het gebruik van Yubikeys. Wij hebben destijds versie 1 van deze sleutels geïmplementeerd in ons softwareproduct en enkele 100-en van die dingen gekocht. (Echt 10 jaar, even in git gekeken, april 2010 is onze software aangepast)

Destijds waren al deze standaarden er niet, maar Yubico blonk uit in de openheid van hun protocol, mogelijkheden tot configureren en implementatie van eigen code voor validatie. Wij gebruiken nog altijd die eerste versie en dat werkt nog steeds veilig en eenvoudig. Wij re-flashen elke key met een alleen bij ons bekende secret en onze klanten verbinden een sleutel aan een account.

Ik heb nog nooit een defecte sleutel meegemaakt. De Yubikeys leven dus al ruim 10 aan de sleutelbossen van mij, mijn collega's en onze klanten. Ik heb er laatst een vervangen. Niet vanwege slijtage, maar omdat ik ook fido2 wilde gebruiken om te testen en implementeren.

Niet alleen zijn die sleutels dus onverslijtbaar, maar 10 jaar later nog backwards compatible met de eerste versie.

Het integreren van fido2 in je applicatie is overigens eenvoudig.

[Reactie gewijzigd door casberrypi op 22 juli 2024 15:29]

Ik gebruik ook een Yubi-key (ongeveer?) zo oud is.
Hangt aan mijn sleutelbos, en nog nooit een issue mee gehad.
Pas wel op als je de OpenPGP applet gebruikt. Oudere versies van de Yubikey Neo hebben een zeer kwalijke bug waarbij de pincode totaal niet gecheckt wordt. Yubikey heeft de mijne destijds gratis vervangen. De oudste versies van de Neo kan je trouwens nog zelf updaten, maar de latere versies zijn gelockt, en daar zaten ook versies bij met deze bug.

https://developers.yubico...dvisory%202015-04-14.html
De screenshot van die Yubikey manager is volgens mij zeer oud. De Yubikey manager heeft al minstens een jaar een opgefriste user interface.
Zo kun je de YubiKey en de Feitian K9 programmeren om er privésleutels voor open-pgp of ssh in op te slaan. Die kun je in sommige gevallen direct in een programma of terminal plakken, maar ook via een Kladblok-bestand oproepen.
Ik denk dat je wat dingen door elkaar haalt. Ik spreek dan vanuit mijn ervaring met mijn Yubikey:

• Je kan een static password instellen, die of bij een korte tik of lange tik wordt ingevuld alsof de Yubikey een toetsenbord is.
• Daarnaast kan je een openpgp sleutel opslaan in de Yubikey. Die privesleutel kan je er ook niet meer uithalen en de software je SSH client of git client kunnen dan via de Yubikey - want die fungeert als smartcard - de cryptografische operatie doen.
• Zoals genoemd werkt de Yubikey als Smartcard dus in Windows domeinen kan je het ding ook voor inloggen gebruiken.
Bij iPhones ligt het weer iets anders. Lange tijd hadden iPhones naast een gesloten ecosysteem een nfc-chip die niet bereikbaar was voor externe diensten, dus ook niet voor securitysleutels. Daarin is in recente versies van iOS verandering gekomen. Er zijn, zoals we hierboven al schreven, een paar sleutels met een Lightning-aansluiting. Die werken met iOS 13.3 of hoger, mits je de Safari- of Brave-browser gebruikt. Ook moet je een iPhone hebben boven de 7.
Je hebt het nu over lighting en niet over NFC. Inderdaad sinds iOS 13.3 is er ondersteuning voor WebAuthn - maar ook via NFC. Dit heb ik meerdere keren gebruikt en werkt prima. Je kan dit gebruiken via iedere app die Safari embed - en natuurlijk Safari zelf.

Helaas behoort het invoeren van een pincode wanneer NFC wordt gebruikt niet tot de mogelijkheden. En dat is vervelend want als je je FIDO2 key wilt gebruiken om je Microsoft account te beveiligen moet je je key beveiligen met een pincode.

[Reactie gewijzigd door Sebazzz op 22 juli 2024 15:29]

AuteurTijsZonderH Nieuwscoördinator @Sebazzz27 juni 2020 14:08
De screenshot van die Yubikey manager is volgens mij zeer oud. De Yubikey manager heeft al minstens een jaar een opgefriste user interface.
Dit is de Linux-app die ik een paar weken geleden heb gedownload. Ik kan me herinneren dat de Windows-versie er inderdaad wat anders uit zag, maar m'n VM heeft op het moment even kuren dus moet even sleutelen (pun intended) voor ik dat kan dubbelchecken.
• Daarnaast kan je een openpgp sleutel opslaan in de Yubikey. Die privesleutel kan je er ook niet meer uithalen en de software je SSH client of git client kunnen dan via de Yubikey - want die fungeert als smartcard - de cryptografische operatie doen.
Ja je hebt gelijk, haalde inderdaad wat door elkaar, je kunt de ssh/pgp-key niet oproepen via Kladblok. Pas ik aan!
Je hebt het nu over lighting en niet over NFC. Inderdaad sinds iOS 13.3 is er ondersteuning voor WebAuthn - maar ook via NFC. Dit heb ik meerdere keren gebruikt en werkt prima. Je kan dit gebruiken via iedere app die Safari embed - en natuurlijk Safari zelf.
Hier had inderdaad iets over nfc bij moeten staan, nu ik het lees ontbreekt dat ja. Voeg ik toe.
Wat ik bijzonder vind aan de hele constructie: ik kan hiermee bewijzen wie ik ben, maar de andere kant bewijst niets. Dus de bank weet zeker dat ik Milmoor ben, maar ik weet niet zeker of ik niet per ongeluk op een fishing site ben gekomen. Ik ben nog geen oplossingen tegen gekomen die dat stuk oppakken. In principe doet je browser dat natuurlijk, maar ik zou graag bij mijn wachtwoord vastleggen bij wie ik deze wil gebruiken. Dus buiten de PC om. Zeker als ik iemand anders zijn/haar apparaat gebruik is dat wel zo veilig. Dat vereist wel een slimmere sleutel.
Bij FIDO2/U2F wordt de private key zoals opgeslagen in de hardware sleutel gekoppeld aan een domeinnaam. De browser geeft vervolgens ook aan voor welke website (/domein) de authenticatie uitgevoerd moet worden. Als je op een "echte" phishing site terecht komt zal de hardware sleutel dus "niet werken", omdat er geen match is (site die je bezoekt bestaat geen private key voor). Maar voor MitM achtige aanvallen waarbij de phishing website geserveerd wordt onder de domeinnaam van de originele site is dat geen oplossing. Echter werkt webauthn wél alleen in combinatie met TLS beveiligde websites, dus de phishing website zal wel nog steeds een valide certificaat moeten hebben. (Maar als je op een untrusted PC inlogt dan is het natuurlijk ook mogelijk dat het "onveilige" certificaat wel als veilig wordt beschouwd).
Idd zijn veel sites hier niet klaar voor. Maar veel belangrijke sites die je nodig hebt bij DevOps achtige toestanden (github, gitlab, aws, gcp, vast ook azure) wel. Ik heb een solokey voor mijn werk en daarmee zitten juist de belangrijkste dingen achter U2F. Die solokey zit overigens gewoon aan mijn sleutelbos en lijkt daar geheel niet van onder de indruk.

Wat ik zelf wel raar vind, is dat sommige sites je niet toestaan om *alleen* de device te gebruiken, heel vaak moet je alsnog ook totp instellen (github bijvoorbeeld). Dit verzwakt de beveiliging in mijn ogen. Ook al kun je de totp secret weggooien i guess. Bij google is dit het beste geregeld voor zover ik weet.
Wat mij niet helemaal duidelijk is hoe deze keys veiliger zijn dan Totp? Bij Totp worden je smartphones toch de 3e factor 'iets wat je hebt' en eens je Totp generator geconfigureerd is, heb je er toegang tot nodig om een andere toe te voegen, net zoals bij deze keys.
Je heb inderdaad nog wel het passwordless gebeuren, maar er zijn nog veel diensten die dit ondersteunen, en zowel Google en MS hebben dit op orde via je smartphone. Voor je smartphone heb je dan nog eens extra factoren (pin/fingerprint) nodig om erin te geraken. Is dat bij deze keys ook het geval, of eens je zo'n key hebt, kan je die ook gebruiken?
OTP is geen "wat je hebt", maar "wat je weet". OTP codes kunnen worden onderschept, of je kunt ze al dan niet vrijwillig doorgeven aan anderen. Daarmee bewijs je dus niet dat de telefoon bij de PC is, maar dat je aan een code kunt komen.

Zo kan een kwaadwillende je een OTP code ontfutselen via bv de telefoon en inloggen op een website terwijl die aan de andere kant van de wereld is. Bij deze hardware sleutels is dat onmogelijk, omdat de hardware sleutel fysiek in de buurt moet zijn van het apparaat waarop je de inlog doet (zij het via USB aangesloten, of via NFC, of via Bluetooth). Daarnaast gebruikt FIDO2/U2F ook geen (zichtbare) codes, waardoor een aanvaller je überhaupt niet kan verleiden om een code af te staan, want die zie je niet.
Deels akkoord, maar je key kan even goed gestolen, verloren worden waardoor je dan die dan ook meteen kan gebruiken (sommigen hebben een pin of fingerprint, maar de meesten precies niet).
Is het verschil tussen 'wat je weet' en 'wat je hebt' niet afhankelijk van waar dat 'weten' komt?
Als je Totp device verloren is en je hebt geen back-up, dan geraak je er toch ook niet meer in, omdat je 'wat je hebt', er niet meer is?
Bij deze keys is het toch ook 'wat je weet', namelijk het private key, die op die keys staan? Als je die zou hebben (hypothetisch, geen idee of je die kan ontfutselen van zo'n key eens je fysieke toegang er tot hebt), heb je toch ook maar een geavanceerde 'weten'? waarbij je die zelfs niet kan veranderen, terwijl Totp elke 30s veranderen.

Voor mij lijkt het dat beide op zich een extra laag security toevoegen, maar niet elkaar horen uit te sluiten, aangezien ze elk een ander deel van security chain proberen te beschermen (locatie en tijdstip).

[Reactie gewijzigd door laibalion op 22 juli 2024 15:29]

maar je key kan even goed gestolen, verloren worden waardoor je dan die dan ook meteen kan gebruiken
Maar dat kan bij een telefoon ook. Dat nadeel hebben beiden dus. Echter kan bij OTP ook de code "gestolen" worden (babbeltruc aan telefoon, phishing site), en dat kan bij deze hardware sleutels niet.
(sommigen hebben een pin of fingerprint, maar de meesten precies niet).
YubiKey heeft het wel, optioneel in te stellen via hun app. Maar eenmaal ingesteld niet meer te verwijderen (wel aan te passen).
Als je die zou hebben (hypothetisch, geen idee of je die kan ontfutselen van zo'n key eens je fysieke toegang er tot hebt)
Volgens mij is het nog maar de vraag of je de private key kunt uitlezen als je toegang tot de sleutel hebt. Als het goed is kan dat in ieder geval niet (en als het wel kan is de sleutel "lek"). Maar als je toegang tot de sleutel hebt kun je die waarschijnlijk dus ook gewoon gebruiken :+.
waarbij je die zelfs niet kan veranderen, terwijl Totp elke 30s veranderen
Appels en peren :p De code die de hardware sleutel genereert veranderd ook steeds, alleen dan op basis van wat de website voor een challenge stuurt. Dat is dus semi gelijk aan aan TOTP.
Echter bevat TOTP ook een secret (deze staat in de URL in de QR code), en die secret is statisch, net zoals de private key bij FIDO2/U2F. TOTP is simpelweg een hash berekend over de huidige tijd (/30 seconden) in combinatie met de secret. Als je de secret weet kun je dus ook op elk moment een TOTP code genereren, hetzelfde als dat je FIDO2/U2F challenges kunt blijven uitvoeren als je de private key hebt.
aangezien ze elk een ander deel van security chain proberen te beschermen (locatie en tijdstip).
Tijdstip an zich is IMO geen beveiligingsmaatregel binnen TOTP. Het is meer een oplossing om aan twee kanten hetzelfde algoritme te kunnen gebruiken en tot dezelfde code te komen. De voorloper was HOTP en die werkte met een teller, waarbij zowel de website als de telefoon een teller bijhouden en elke keer dat een code wordt gecontroleerd/gevalideerd wordt de teller opgehoogd, op het moment dat je echter twee telefoons instelt, of SMS en app door elkaar gebruikt, gaan die tellers "scheef" lopen en werkt het dus niet meer. Waarbij bij TOTP domweg de teller is vervangen door "<aantal seconden sinds 1 januari 1970 00:00 UTC> / 30". Waardoor dus iedereen dezelfde code genereert op een willekeurig tijdstip.
Een telefoon heeft zijn eigen laag van beveiliging met een PIN en/of fingerprint (hetzelfde als sommige duurdere keys), maar goed :).
Tijdstip an zich is IMO geen beveiligingsmaatregel binnen TOTP. Het is meer een oplossing om aan twee kanten hetzelfde algoritme te kunnen gebruiken en tot dezelfde code te komen
Heb je hier wat achtergrond voor? Mij lijkt dit wel degelijk onderdeel van de beveiligingslogica, aangezien er altijd maximaal een window is van 30s waarin een totp geldig blijft, waardoor het dus niet zinvol is om die totp's te bewaren ofzo. Maar goed, ik ga niet beweren hier een expert in te zijn :P.

Wat betreft die 'secret' die voor Totp wordt gebruikt, ik neem aan dat websites deze (kunnen) resetten indien je 2FA uit- en weerinschakeld, of als er verdachte activiteit op accounts gebeurt.

Leuke discussie :)
Heb je hier wat achtergrond voor? Mij lijkt dit wel degelijk onderdeel van de beveiligingslogica, aangezien er altijd maximaal een window is van 30s waarin een totp geldig blijft, waardoor het dus niet zinvol is om die totp's te bewaren ofzo. Maar goed, ik ga niet beweren hier een expert in te zijn :P.
Daarom IMO :P Ik vind TOTP in die zin niet veel veiliger dan de voorloper HOTP. Beiden werken op basis van een tellertje om misbruik te voorkomen. Alleen is bij de een het tellertje daadwerkelijk een tellertje die bij elke poging wordt opgehoogd (en daardoor out-of-sync kan raken en niet meer werkt), en bij TOTP is de huidige tijd het tellertje.
En die 30 seconden, de code wordt gegenereerd voor een tijdspanne van 30 seconden en veranderd daarna (omdat dus de teller is afgeleid van de huidige tijd gedeeld door 30). Maar omdat niet alle klokken gelijk lopen kun je meestal ook een oude, of toekomstige code gebruiken. De server berekend zelf het tellertje (tijd / 30) en berekend daarbij de code, als de code overeen komt met wat de gebruiker heeft ingevuld, is het in orde. Maar als de code niet overeen komt wordt er normaliter ook nog gekeken naar de code behorende bij teller -1, -2, +1, +2 etc waardoor er al wat meer "speling" ontstaat en een code van 2, 3, 4 minuten oud ook werkt, en hetzelfde voor een code van 2, 3, 4 minuten "uit de toekomst".
Wat betreft die 'secret' die voor Totp wordt gebruikt, ik neem aan dat websites deze (kunnen) resetten indien je 2FA uit- en weerinschakeld, of als er verdachte activiteit op accounts gebeurt.
Klopt, uiteraard kan die veranderd worden. Maar op dat moment moet je natuurlijk ook die nieuwe secret in de app hebben, anders werken de TOTP tokens zoals door de app gegenereerd niet meer.
Standaard is de slack, die on de klokken mag zitten, 5 minuten (300 seconden), maar dat is een instelbare variabele.
Mag in de huidige tijd rustig wat strakker, imho.
Als ik kijk bij de google site over titan keys, https://cloud.google.com/titan-security-key zie ik staan
A hardware chip that includes firmware developed by Google helps to verify that the keys haven’t been tampered with. The hardware chips are designed to resist physical attacks aimed at extracting firmware and secret key material.
typefout verbeterd

[Reactie gewijzigd door jcvw op 22 juli 2024 15:29]

ACM Software Architect @kcjs27 juni 2020 10:24
Wat ik zelf wel raar vind, is dat sommige sites je niet toestaan om *alleen* de device te gebruiken, heel vaak moet je alsnog ook totp instellen (github bijvoorbeeld). Dit verzwakt de beveiliging in mijn ogen. Ook al kun je de totp secret weggooien i guess. Bij google is dit het beste geregeld voor zover ik weet.
Toen ik mijn best deed om het webauthn-protocol te begrijpen, kwam ik al vrij snel tot de conclusie dat er een flinke usability-issue ontstaat bij de device-based authenticators.

En die authenticatie is doorgaans ook echt heel hard aan het apparaat gekoppeld; je vingerafdruk, iris of gezicht geeft op ieder apparaat een andere cryptografische sleutel.

Stel je hebt de beveiligingsfeatures van je telefoon gebruikt via webautn. Daarna mag je natuurlijk alleen nog maar inloggen via MFA... maar wat als je een ander apparaat wilt gebruiken? Dan kom je in een catch22; je mag niet inloggen want je hebt niet de juiste authenticator, maar je kan je apparaat ook niet aanmelden als authenticator want je kan niet inloggen.

Met deze usb-sleutels is dat probleem natuurlijk veel kleiner, want doorgaans kan je die eenvoudig overzetten naar een ander apparaat.

Maar hoe los je het op bij authenticators die je niet zo makkelijk kan overzetten? Webauthn kent hier geen oplossing voor; het meldt wel dat het sterk aanbevolen is om meerdere authenticators te ondersteunen, maar meldt niet hoe je die aanvullende authenticators dan veilig kan toevoegen...
Daarnaast zit je nog met accountrecovery; hoe doe je dat? Zodra je die telefoon kwijt bent, kom je er anders ook nooit meer in.

Behalve dan toch via totp inloggen - en daarna je (nieuwe) apparaat koppelen - weet ik in ieder geval geen oplossing daarvoor die niet nog meer beveiligingsproblemen heeft.

[Reactie gewijzigd door ACM op 22 juli 2024 15:29]

Goede vragen waar ik ook erg mee heb geworsteld.

Ik ben tot de conclusie gekomen dat er praktisch gezien geen werkbare oplossing is die 100% veilig is. Je moet in praktijk backups maken van alles, en daarmee worden al die middelen eigenlijk dezelfde factor.
Als iemand bij de backups kan, dan is daarmee alles te herstellen.
Als je geen backups maakt dan kom je enorm in de problemen als je telefoon of je yubikey stuk gaat of wordt gestolen. Daar is praktisch gezien niet van terug te komen zonder backups. Een paar grote diensten als Google en Microsoft hebben nog wel iets geregeld, maar die processen zijn ook weer zeer twijfelachtig van aard. Dan moet je bijvoorbeeld met je paspoort voor de webcam gaan zitten en dat is tegen alle voorschriften in. Of ze hebben juist een zeer onveilig proces waarmee je met een simpele mail alle beveiliging kan resetten.
Veel sites gaan echter niet zo ver. Als je niet zelf voor een backup van je 2e factor zorgt dan heb je pech als je die kwijt raakt.
Maar hoe los je het op bij authenticators die je niet zo makkelijk kan overzetten? Webauthn kent hier geen oplossing voor; het meldt wel dat het sterk aanbevolen is om meerdere authenticators te ondersteunen, maar meldt niet hoe je die aanvullende authenticators dan veilig kan toevoegen...
Daarnaast zit je nog met accountrecovery; hoe doe je dat? Zodra je die telefoon kwijt bent, kom je er anders ook nooit meer in.
Volgens mij is het de bedoeling, je hebt 2 van de 3 apparaten:
- smartphone met die functie en ondersteuning
- laptop or deskop met functie en ondersteuning
- security key (NFC/USB/whatever)

Je meld je aan op een site en onder 'acccount' van de site voeg je het 2e apparaat toe.

In praktijk denk veel websites dat je gewoon een email reset link kunt laten sturen (net als password reset), want niemand wil helpdesk spelen voor mensen die niet meer kunnen inloggen ;-)

Of toch maar link via email en SMS ? klen beetje veiliger, soort password reset met 2FA.

Of wat je vaak ziet:

lijst van backupcodes

Die kun je dan in keepass zetten, oid.

[Reactie gewijzigd door Lennie op 22 juli 2024 15:29]

ACM Software Architect @Lennie30 juni 2020 08:33
Je meld je aan op een site en onder 'acccount' van de site voeg je het 2e apparaat toe.
Maar hoe doe je dat? Dan moet je waarschijnlijk naast in je nieuwe apparaat ook met een al vertrouwd apparaat inloggen en daar op een of andere manier bevestigen dat dit nieuwe apparaat inderdaad van jou is.

Al met al dus best complex om goed uit te werken.

En een resetlink via email is uiteindelijk weer maar 1FA; sms betekent natuurlijk dat je het telefoonnummer van de gebruiker moet hebben (nog los van de beveiligingsissues ook een privacyding). Uiteindelijk kunnen backupcodes natuurlijk helpen, maar als je MFA aanbiedt hoor je alle routes via MFA te beveiligen. Dus ook het toevoegen van een nieuw apparaat of het herstellen van je account.
Maar hoe doe je dat? Dan moet je waarschijnlijk naast in je nieuwe apparaat ook met een al vertrouwd apparaat inloggen en daar op een of andere manier bevestigen dat dit nieuwe apparaat inderdaad van jou is.

Al met al dus best complex om goed uit te werken.
Hier is een mogelijke, zeer veilige manier:

Stuur een email link om een extra apparaat toe te voegen. Die kun je dan openen op andere apparaat, oid.

En via het account deel van de site, bevestig het toevoegen van het tweede apparaat terwijl je bent ingelogd via het eerste apparaat.
ACM Software Architect @Lennie30 juni 2020 10:04
Klopt. Zoiets inderdaad... Maar dat is nog best complex om uit te werken.

De originele vraag waar ik op reageerde is waarom vaak totp-tokens ook gebruikt worden of zelfs verplicht zijn. Ik kan me in ieder geval voorstellen dat de complexiteit om nieuwe apparaten toe te voegen daar een reden voor is. Dat het dus effectief als een soort universele 2FA werkt en/of als backup-methode voor het geval je originele apparaat niet beschikbaar is.
Mogelijk is de praktijk simpeler: je meld je aan op de laptop, je wil je mobiel aanmelden, er staat een QRcode met link naar de site, meld je mobiel aan en er staat een melding op de laptop: bevestig aub.

Wat je vaak ziet: backupcodes die je dan maar in keepass moet zetten, oid.

Dus is dus allemaal als 2FA naast een wachtwoord en het email adres dat de site heeft dat je voor password reset kunt gebruiken.

Ik ben vooral benieuwd hoe het zit met veel sites die je helemaal niet zo heel veilig moet zijn, gaan we dan echt 1FA doen ? Dus niet gebruikersnaam/wachtwoord invullen, misschien zefls niet eens een gebruikersnaam, maar direct de laptop/smartphone of NFC/USB-stick.
AuteurTijsZonderH Nieuwscoördinator @kcjs27 juni 2020 14:31
Dat laatste vind ik zó ergerlijk. Je moet die totp dan echt knarsetandend aanzetten, wetende dat je je beveiliging compromiteert. Gelukkig is dit vaak niet het geval bij de diensten die er echt toe doen, zoals wachtwoordmanagers.
Dat laatste vind ik zó ergerlijk. Je moet die totp dan echt knarsetandend aanzetten, wetende dat je je beveiliging compromiteert. Gelukkig is dit vaak niet het geval bij de diensten die er echt toe doen, zoals wachtwoordmanagers.
Een vraag die ik regelmatig stel is "Voor wie doen we dit?". Gebruiken we MFA om de gebruiker te beschermen of om de dienstverlener te beschermen?
Gebruikers gaan er uiteraard van uit dat het in hun eigen belang is, terwijl de sites die de authenticatie aanbieden uiteraard met hun eigen belang bezig zijn. Die belangen kunnen heel anders zijn. De meeste siters maakt het niet echt uit als een individuele gebruiker gehacked wordt. Als gebruikers moeite hebben met inloggen is dat een veel groter probleem.

Overigens lijken ontwikkelaars hier vaak ook niet goed over na te denken waardoor er vanuit verschillende strategieen of filosofien wordt gewerkt. Dan krijgt je van die systemen waarin veel factoren mogelijk zijn maar er niet lijkt te zijn nagedacht over de relatie tussen die factoren of het behaalde veiligheidsniveau.
Wat ik een beetje mis in het verhaal is het scenario van verlies of defect raken van de key. Bieden ze een back-up mogelijkheid?
Daarom moet je er eentje extra hebben. De backup die je in een kluis bewaart.
Dit staat op de eerste pagina omschreven. Advies is om er twee te hebben. De tweede ook overal in te stellen waar je de eerste instelt, maar die vervolgens veilig (in een kluis?) op te bergen.

Daarnaast ligt het uiteraard ook aan het gebruik. Gebruik je de keys alleen om in te loggen op websites dan hebben de meeste websites alsnog een herstel optie (via een lange recovery code, mail, ...). Ook zonder "backup van de sleutel / backup sleutel" kun je dan weer toegang tot je account krijgen. Voor andere toepassingen zal dat uiteraard anders zijn. Log je via PGP in op een server en is PGP de enige ingeschakelde SSH authenticatie optie dan kun je natuurlijk een probleem hebben zonder tweede sleutel.
Ook met SSH kan je meerdere sleutels aanmelden hoor, geen enkel probleem!

En met PGP heb je ook nog het voordeel dat je een softwarematige sleutel kan aanmaken en gewoon uitprinten en in de kluis leggen. Dat is wel een punt van mogelijke aanval natuurlijk maar je moet die dus heel veilig opbergen, is een puntje eigen verantwoordelijkheid. Goede, veilige passphrase er op, op zijn minst.

Helaas met Fido2 heb ik zo'n software oplossing nog niet gezien, al moet het natuurlijk wel gewoon kunnen.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:29]

AuteurTijsZonderH Nieuwscoördinator @MijnKijk27 juni 2020 14:14
Tenzij je vooraf nadenkt over de backupmogelijkheid is die er niet. Daarom kun je vaak twee sleutels tegelijk kopen.

Daarnaast geven diensten waar je 2fa instelt je eenmalig een stel backupcodes. Die moet je uitprinten en ergens offline bewaren, dat doe je ook bij bv een authenticator-app. Dat moet je wel consistent doen.
Net zoals software 2fa via Authenticator apps: Backup codes waarmee je zonder de key alsnog verder kan. Yubikeys zijn echt onverslijtbaar.
Bor Coördinator Frontpage Admins / FP Powermod @MijnKijk27 juni 2020 10:21
Nee een backup mogelijkheid is er niet. Het advies is zoals meerdere mensen hier aangeven om er meerdere aan te schaffen. Let wel dat niet elke oplossing het mogelijk maakt om meerdere keys te koppelen waardoor dit niet altijd een optie is. Je bent op deze manier ook dubbel zo duur uit waardoor ik het een slechte oplossing vind.
Een beetje laat, maar dank allen voor de reacties.
Als fervent MFA gebruiker weet ik van de back-up codes en heb ik de oplossing van een tweede key gelezen. Zonder een betere oplossing te weten voelt het echter een beetje als een halfslachtige oplossing, nog los van de vraag of het voor "jouw risicoprofiel" een veilige oplossing is.

Alles heeft natuurlijk z'n voors en tegens en er is niet 1 oplossing voor alles. Ik ga (weer) even in beraad :+
Hoelang gaan de usb aansluitingen mee met zo'n sleutel waarop je moet drukken? Ik kwam in het verleden laptops tegen waarvan de usb aansluiting fysiek niet goed meer werkte door het insteken en eruit halen van flashdrives.
Bor Coördinator Frontpage Admins / FP Powermod @FrostyPeet27 juni 2020 10:26
Mijn ervaring is dat de hardware van bv Yubikeys vrijwel onverwoestbaar is (bij normaal gebruik) en de belasting voor de USB poort minimaal. Het is geen echte drukknop die hard ingedrukt moet worden maar meer een soort touch gevoelig. Wil je dat niet dan zijn er ook keys met bv NFC beschikbaar zoals: https://www.yubico.com/product/yubikey-5-nfc
AuteurTijsZonderH Nieuwscoördinator @FrostyPeet27 juni 2020 14:15
Ik heb zelf een jaar een YubiKey en de rest pas een paar weken getest, maar in principe zouden ze jaren mee moeten kunnen. Kan het alleen uit ervaring niet zeggen...
Dit is wel een beetje zo bij goedkope USB poorten. Ik heb zo'n 5 euro China-hubje op de voet van mijn iMac geplakt op het werk, om zo de Yubikey er makkelijk in te kunnen doen. Want Apple heeft alle USB poorten aan de achterkant zitten 8)7

Maar met die goedkope flut hubs heb ik inderdaad dat de poort na een tijdje uitlubbert en geen goed contact meer maakt: Als ik hem dan aanraak dan verbreekt de verbinding even waardoor de login poging mislukt. Ik heb daarna de poort afgeplakt en gebruikte de andere 3, tot er daarvan ook weer eentje stuk ging. Dusja het is wel een dingetje, en ik moet er ook bij zeggen dat ik een stukje muismat onder de yubikey heb liggen waardoor hij geen kracht op de USB poort zet als ik hem aanraak.

Maar met USB poorten op laptops heb ik dit nog niet gezien. Dus het lijkt alsof het van de kwaliteit van de poort afhangt.

De Yubikeys zelf hebben nauwelijks slijtage, zelfs na 5 jaar aan een sleutelbos met andere sleutels die ze constant krassen. Alleen het plastic gedeelte is wat 'afgeronder' geworden.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:29]

Anoniem: 551631 27 juni 2020 09:41
Kun je een van deze keys ook "koppelen' aan een bestaande password manager? dus in plaats van windows of firefox die aanbied om je passwd op te slaan en bij de volgende keer je wachtwoord in te vullen dat de key dat doet? (icm het desbetreffende programma of browser)

Ik lees dat de ubikey een slot heeft voor een code die deze dan voor je ingeeft wanneer een tik op de stick geeft.
Maar dat is en MAAR 1 pw en dat moet toch ook geautomatiseerd kunnen?
Bor Coördinator Frontpage Admins / FP Powermod @Anoniem: 55163127 juni 2020 10:31
Nee, doorgaans gebruik je een key als dit om de toegang tot een dienst te beveiligen waarbij de password manager zelf ook als zo'n dienst gezien kan worden.
Anoniem: 551631 @Bor27 juni 2020 12:12
Snap ik, maar toegang tot websites is in dit artikel een redelijk groot uitbemeten onderdeel.
Ik mag dan toch zeggen dat de (naar mijn mening) grootste doelgroep zou kunnen zijn mensen zoals ik die miljoenmiljard accounts en dito password moet hebben.
Ik gebruik veelal dezelfde passwords voor websites die er niet toe doen, en waar mijn persoonsgegevens ook niet rondzwerven.

En hoe belangrijker deze worden hoe meer random mijn passwords worden.
Dit zou ik allemaal in een passwordmanager kunnen stoppen, maar dat heeft voor mij 2 nadelen:
1- werkt alleen maar op een device
2- als die passwordmanager gehackt/gekraakt word, ligt in 1 keer al mijn data op straat.

Dan zou ik liever een los iets hebben als een stick waar al die passwords encrypted opstaan die ik in willekeurig elke computer kan steken waar ik kom.
Dit lijkt mij een erg gewilde usecase waar volgens mij veel markt voor zou zijn.

Desnoods moet je een browser schrijven die constant communiceert met de usb stick.
1- werkt alleen maar op een device
Je zou het in sync kunnen houden via een cloud-oplossing. Maar dan moet je die cloudprovider wel vertrouwen. Die databases van passwordmanagers zijn heel erg sterk beveiligd/versleuteld, dus de kans dat dat gekraakt wordt is bijzonder klein.
2- als die passwordmanager gehackt/gekraakt word, ligt in 1 keer al mijn data op straat.
Ditzelfde is als die stick die je beschrijft in verkeerde handen komt.

Je zou natuurlijk een passwordmanager op een USB-stick kunnen zetten met een paar universele binaries of desnoods een paar versies van de tool er op zetten (dus iets van keepassxc. Die heeft portable installaties voor Windows, MacOS en Linux. Dan heb je uiteraard nog niet alle besturingssystemen, maar je komt in elk geval een heel end met de meest gangbare desktopbesturingsystemen.
Anoniem: 551631 @lenwar27 juni 2020 14:07
tuurlijk. een fysieke key kan kwijtraken/gejat worden.

maar de gemiddelde inbreker/zakkenrollet zal echt niet opzoek zijn om data te vergaren.

een hacker die inbreekt op mijn computer wel.
ik weet dat er cloudbased oplossingen zijn. maar ik vind dat nogal wat om uit te besteden en dat staat naar mijn mening helemaal haaks op de definitie van veilig. (waar staat mijn data, van wie zijn die servers, hoe zijn die beveiligd etc.)

ik weet dat er legio oplossingen zijn die ook goed werken. maar ze zijn allemaal relatief omslachtig in een tijd dat juist alles gebeurt zonder teveel handelingen.

heb er zelf de kennis niet voor maar lijkt mij een product waar wel vraag naar is.
mits het echt plug en play werkt zoals een autosleutel.
AuteurTijsZonderH Nieuwscoördinator @Anoniem: 55163127 juni 2020 14:18
Ik denk dat een sleutel die AL je wachtwoorden opslaat fysiek ook een stuk groter zou moeten zijn. Voor zover ik weet is er geen sleutel die dat kan. Wat je beschrijft is eigenlijk een hardware-wachtwoordmanager, toch? Ik ken zoiets niet maar zou wel tof zijn.

Denk dat je best practice dan toch een wachtwoordmanager is...
Anoniem: 551631 @TijsZonderH27 juni 2020 14:51
Zeker, dat heb ik op een andere reactie ook al aangegeven.
Er zijn legio manieren om je passwords veilig op te slaan.

Maar tenzij je het niet "uit" de digitale wereld haalt, blijft het altijd beschikbaar/bereikbaar voor een eventueel kwaadwillende.

Als je alles op een kladpapiertje schrijft, zal er geen hacker zijn die jouw passwords gaat vinden.
Maar dan loop je weer tegen andere problemen aan.

Een hardwarematige variant zou een uitkomst zijn, en vind het eigenlijk apart dat een functie als deze door niemand ooit is uitgewerkt.
Formaat zal ook wel meevallen denk ik, in principe alleen maar een instructieset nodig voor het os en of de ondersteunde programma's en opslag voor je passwords, wat zelfs encrypted niet veel meer als een paar kb zal zijn.

Maar hee, ik hou goede hoop dat er een whizzkid komt die dit leest en zoiets op de markt brengt, wat vervolgens door veel onafhankelijke mensen aan de tand gevoeld is.
Zelf goede ervaringen met deze hardware password manager: https://www.themooltipass.com/
Ik installeer gewoon de BitWarden password manager op elk device/browser, log in met mijn yubikey en heb al mijn wachtwoorden beschikbaar. Is dat niet wat je bedoelt?

Passwordless login via WebAuthn/FIDO2 zou inderdaad nog beter zijn. Dan slaat de sleutel namelijk een apart keypair op per site. Geen installatie van software maar gewoon sleutel inpluggen en je bent geauthenticeerd. Dat vereist wel dat alle diensten dit ondersteunen en dat schiet nog niet erg op. Mijn Yubikey kan beiden aan dus tot het zover is...

[Reactie gewijzigd door Yggdrasil op 22 juli 2024 15:29]

Ja en nee, hij heeft maar 2 slots voor paswoorden (eentje bij kort indrukken, eentje bij lang indrukken).

Ik gebruik zelf het uitstekende zx2c4 pass (password safe), die gebruikt OpenPGP om elk paswoord te encrypten. Daardoor heb je de sleutel echt nodig om elk individueel paswoord te decrypten, en moet je hem ook elke keer aanraken als je de Yubikey "touch to sign" functie aan zet. Wel heel erg belangrijk om te zorgen dat je meerdere sleutels aanmeldt, of op zijn minst een ouderwetse software PGP key als backup.

De software is commandline maar er is ook een GUI versie QtPass. Syncen gaat van/naar een git repo. Er is ook een hele goede Android client voor (de yubikey gebruik je dan via NFC of ook via USB). iOS is er ook maar die vereist een lokale sleutel in software ivm de Apple beperkingen rondom NFC toegang, helaas.

Het is allemaal erg lichtgewicht en superhandig vind ik, maar het is niet echt geschikt voor consumenten, het vereist wel wat technisch inzicht. Maar de vrijheid die je hebt om het in te richten maakt het juist extra handig, vind ik. En je hebt niet het probleem dat als je je masterpassword lekt, de aanvaller toegang heeft tot je complete paswoord database. Ze moeten dan echt de key hebben en hem bovendien voor elk paswoord aan kunnen raken.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:29]

Toen ik de titel las vroeg ik me direct af of hier eigenlijk toekomst in zit? Het lijkt me zo'n verouderd systeem als je al Touch ID hebt op je notebook hebt. Ook redelijk gevaarlijk volgens mij. Als er nu iets is dat je vergeet op een systeem dat niet van jou is dan het meestaal toch wel een usb stick.
Het voordeel vind ik juist dat je het op meerdere systemen kan gebruiken. Zo'n touch ID werkt alleen op je eigen notebook, je hebt er niks aan als je op een andere computer wil inloggen.

Bovendien zit je niet vast aan het ecosysteem van Apple.

En zelfs Apple ondersteunt nu Fido2 in Safari vanaf Big Sur, dus je kan je MacBook aanmelden als aparte "sleutel".

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:29]

Goed dat snap ik wel maar het probleem zit hem voor mij in de vorm van USB key. Ik zie daar echt geen toekomst omdat het risico op verlies te hoog. Touch ID werkt inderdaad enkel op mijn MBP maar als ik een account aanmaak op macOS dan kan ik wel inloggen op die account via FaceID op mijn iPhone. En ja dat is inderdaad het voordeel of nadeel van een ecosysteem. Zoals ik al eerder aangaf lijkt het me veiliger om een universele standaard in een wearable te steken. Misbruik ligt dan gevoelig lager
Verlies is niet zo'n probleem als je bedenkt dat zo'n Fido2 stick maar een euro of 20 kost. Je kan er normaal gezien meerdere aanmelden. En je gebruikt hem met pincode, dus bij verlies heeft niemand er wat aan, net als bij een pinpas.

Maar het idee van Fido2 is dat je zelf kan kiezen wat voor authenticator je gebruikt. Een fysieke stick, of een ingebouwde functie in je OS. Binnenkort hebben alle OSen dit ingebouwd zitten. (Android nu al, iOS en macOS komen, alleen van Windows weet ik het niet zeker, maar volgens mij kan je via Hello ook al een Fido2 authenticator emuleren).
AuteurTijsZonderH Nieuwscoördinator @monojack27 juni 2020 14:39
Ik denk dat het vooral heel nuttig wordt als meer diensten Fido2 ondersteunen. Plus, lang niet iedereen heeft Apple-producten natuurlijk. Een universelere methode zoals deze keys is dan wel handig.
Inderdaad dat is waar ik ook initieel aan dacht. Handig als ik ergens ben waar ik geen toegang heb tot macOS maar dat is nu net de moment dat die ik die key zou vergeten weer mee te nemen omdat je het zo gewoon bent dat alles vanuit een eco-systeem centraal beveiligd is. Ik zie hier echt geen toekomst in. Dan zie ik meer toekomst in wearables. Handig zou zijn dat elke computer mij zou kunnen authenticeren op basis van mijn smartwatch bvb.

Op dit item kan niet meer gereageerd worden.