Door Tijs Hofmans

Redacteur

Beveiligingssleutels onder de loep

Wat kun je met deze fysieke securitykeys?

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)

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 26 november 2020 23:25]

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 27 juni 2020 17:49]

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 28 juni 2020 01:58]

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 27 juni 2020 12:28]

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 27 juni 2020 22:49]

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.
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).
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 27 juni 2020 23:19]

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 28 juni 2020 16:57]

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 29 juni 2020 16: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 29 juni 2020 20:51]

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 30 juni 2020 21:39]

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 1 juli 2020 08:07]

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)
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 27 juni 2020 08:12]

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 27 juni 2020 07:07]

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 27 juni 2020 10:08]

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 27 juni 2020 11:33]

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 27 juni 2020 10:25]

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 30 juni 2020 08:20]

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.
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.
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 27 juni 2020 15:32]

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.
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.
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
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 27 juni 2020 15:37]

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?
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.
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...
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 28 juni 2020 02:30]

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 27 juni 2020 15:43]

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 27 juni 2020 15:49]

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).
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.

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.




Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

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

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

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

Functioneel en analytisch

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

janee

    Relevantere advertenties

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

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

    Ingesloten content van derden

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

    janee