CBS: aantal bedrijven dat tweestapsverificatie gebruikt is verdubbeld sinds 2017

Het gebruik van tweestapsverificatie onder Nederlandse bedrijven is in acht jaar tijd meer dan verdubbeld. In 2017 maakte 26 procent van de bedrijven volgens het CBS gebruik van 2fa, maar inmiddels zou het gaan om 61 procent.

Vooral onder kleinere bedrijven, met 10 tot 50 werknemers, is het gebruik van 2fa gegroeid: van 29 procent in 2017 naar 76 procent in 2024. Bij grote bedrijven, met meer dan 250 werknemers, is het 2fa-percentage gestegen van 71 naar 97 procent. Dat blijkt uit de Cybersecuritymonitor 2024 van het Centraal Bureau voor de Statistiek.

Ook verplichten steeds meer bedrijven hun werknemers om een sterk wachtwoord te kiezen dat bijvoorbeeld een minimumaantal tekens of cijfers moet bevatten. Acht jaar geleden hanteerde 57 procent van de Nederlandse bedrijven zo'n wachtwoordbeleid en dat is inmiddels gegroeid naar 72 procent. Bij grote bedrijven vereist 98 procent een sterk wachtwoord.

Ook van veel andere cybersecuritymaatregelen blijkt dat deze vaker worden genomen door grotere bedrijven. Het versleutelen van data gebeurt bijvoorbeeld door 48 procent van de kleinere bedrijven en 90 procent van de grotere ondernemingen. Van de bedrijven met 10 tot 50 werknemers slaat 58 procent logbestanden op voor incidentanalyse, terwijl dat bij de grote bedrijven 34 procentpunt hoger ligt.

Verder meldt het CBS in de Cybersecuritymonitor dat ook het aantal bedrijven waarvan de websites voldoen aan bepaalde internetstandaarden, zoals de aanwezigheid van IPv6, Dnssec of Https, licht stijgt: van 60,4 procent in 2020 naar 68,0 procent in januari 2025. Meer kleinere bedrijven hebben IPv6-ondersteuning geïmplementeerd dan grotere, maar grote bedrijven maken wél vaker gebruik van het Https-protocol.

Het aantal cyberincidenten is onder alle bedrijfsgroottes gedaald, meldt het onderzoeksbureau tot slot. Dat geldt zowel voor het aantal incidenten met een interne oorzaak als voor aanvallen van buitenaf. Een uitval van een ict-systeem door een interne storing kwam het vaakst voor.

Reacties (37)

[OttoRocketman]

maar grote bedrijven maken wél vaker gebruik van het Https-protocol.

Volgens mij gaat dat over dit:

Aan de andere kant toont figuur 2.2.5 dat grotere bedrijven juist weer beter scoren op het ondersteunen van HSTS, oftewel HTTPS Strict Transport Security. Websites met HSTS vereisen dat de webbrowser de website alleen via het beveiligde HTTPS kunnen benaderen en niet via het onveilige HTTP-protocol.

Ik denk dus niet per se dat je kunt zeggen dat grote bedrijven vaker gebruikte maken van HTTPS, aangezien je zonder HSTS-headers prima alléén een HTTPS-site beschikbaar kunt stellen met andere technieken.

[Patriot]

Als aanvulling: Het is eigenlijk wel belangrijk om HSTS te gebruiken (en het liefst ook nog aanmelden voor de HSTS preload list), want het voorkomt ook dat je gebruikers in de toekomst misleid kunnen worden door een website die op het juiste domein lijkt te zijn gehost door bijv. DNS-spoofing. Een browser die de header is tegengekomen (of in zijn preload list heeft staan) zal een reguliere http-verbinding weigeren, dus is de kans dat het fout gaat minder groot.

[Reactie gewijzigd door Patriot op 20 juni 2025 15:33]

[Room42]

Als aanvulling: [...] (en het liefst ook nog aanmelden voor de HSTS preload list) [...]

Nou... op diezelfde pagina:

Many browsers (Chrome, Safari [red: en ook Firefox]) will automatically upgrade all HTTP navigations to HTTPS, regardless of the domain's HSTS policy. HSTS preloading only provides value when these upgrades fail in the presence of an active attacker. The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS. While HSTS is recommended, HSTS preloading is not recommended.

Het heeft dus niet heel veel meerwaarde in moderne browsers, omdat die altijd al pro-actief HTTPS kiezen boven HTTP. Sterker, in ieder geval Firefox, waarschuwt als een website niet via HTTPS bereikbaar is, en vraagt of je door wilt gaan.

[Reactie gewijzigd door Room42 op 20 juni 2025 16:55]

[Patriot]

Interessant, blijkbaar hebben ze daarover hun standpunt veranderd. Op zich logisch, het scenario wat ik omschreef kan zich dan niet voordoen. Wel raar dat ze dan de lijst nog onderhouden, die is dan naar eigen zeggen niets meer waard. Een beetje dubbel.

EDIT: Ik snap overigens niet waarom ze dan HSTS nog wél aanraden. Het voelt een beetje arbitrair.

[Reactie gewijzigd door Patriot op 20 juni 2025 17:40]

[Wilglide]

HSTS preloading only provides value when these upgrades fail in the presence of an active attacker. The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS.

Do not include the preload directive by default. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list without realizing that some subdomains cannot support HTTPS. Removal tends to be slow and painful for those sites.

Maar HSTS biedt al (wat) bescherming tegen een -actieve aanval-. Interne domeinen kunnen wel HSTS activeren, maar sowieso geen preload doen. Zonder 'preload' directive is het ook laagdrempelig te implementeren voor interne domeinen. Dus waarom dan niet aanraden als bekend is dat alle subdomeinen https ondersteunen? Zwitserse gatenkaas voor security..

[Patriot]

Ik ben niet tegen het gebruik van HSTS hoor, ik vind alleen de argumentatie 'tegen' de preload een beetje suf. Er is eigenlijk geen nieuwe ontwikkeling geweest sinds de invoer hiervan, maar er wordt nu gedaan alsof het allemaal de moeite niet meer waard is t.o.v. de extra veiligheid. De extra veiligheid van de HSTS preload was altijd al minimaal.

De reden dat het misschien leek alsof ik tegen HSTS was, was denk ik omdat ik juist door de vergelijking te trekken met HSTS zelf probeerde aan te geven dat het een beetje een slap argument was

[moimeme]

Moet je dan wel eerste in de firefox setting HTTPS-Only Mode aanzetten.

[geenwaarde]

Ook verplichten steeds meer bedrijven hun werknemers om een sterk wachtwoord te kiezen dat bijvoorbeeld een minimumaantal tekens of cijfers moet bevatten.

Ah ja, dat zegt natuurlijk ook niet zoveel. Met bijvoorbeeld Twe@k3rs.n3t voldoe je vaak ook aan de vereisten, maar of dat nu zo'n sterk wachtwoord is?

Overal waar ik heb gewerkt, willen ze bovendien ook elke twee of drie maanden een ander wachtwoord. En een aantal keren niet gebruikt is als wachtwoord. Veel collega's werkten daarom met volgnummers. Is waarschijnlijk ook niet helemaal wat ze beogen.

[delphium]

Overal waar ik heb gewerkt, willen ze bovendien ook elke twee of drie maanden een ander wachtwoord. En een aantal keren niet gebruikt is als wachtwoord.

Dat is één van mijn grootste ergernissen. Dienst ICT Uitvoering (DICTU) die bij de overheid gaat over o.a. de werkplekinrichting, dwingt dit ook af. Mensen die voorheen sterke wachtwoorden gebruikten van 16 tekens of meer, gebruiken nu een eenvoudig te raden woord met een volgnummer, en/of volgteken (!@#$%^&*).

Omdat je ook om de haverklap dat wachtwoord op je telefoon moet invoeren, voor allerhande toepassingen, kiezen mensen ook nog eens voor een wachtwoord dat daar makkelijk op in te voeren is.

Dat, gecombineerd met het voorspelbare e-mailadres als gebruikersnaam, maakt ambtenaren wel heel erg kwetsbaar voor social engineering en/of wachtwoord raden/afkijken.

Ik heb dit al meermaals aangekaart, maar het wordt niet veranderd. Nota bene, Microsoft zelf raad het af om wachtwoorden verplicht te laten wijzigen (DICTU is een MS-club).

[Reactie gewijzigd door delphium op 20 juni 2025 15:00]

[karelvandongen]

Ook bij scholen met heutink/cool. Heb je dat je elk kwartaal het moet wijzigen... Dus dat leid ook tot erg onveilige wachtwoorden. Ook na wijzen op dat in iso dit juist afgeraden word, wil men het maar niet veranderen... . terwijl we over al al 2fa aan hebben gezet..

[Brent]

NIST raad het al bijna 20 jaar af. Ik kom er ook niet doorheen bij de 'hoge' pieten hier.

[Martijntjeh]

Helemaal mee eens! Bij mij op de werkvloer is dit precies hetzelfde.

Off topic : Is het mogelijk om helemaal van de wachtwoorden af te stappen op de werkvloer? Bijvoorbeeld het pasje in combinatie met een pincode voor lokaal gebruik en Yubikey voor als je thuis wil inloggen of zo. Of desnoods een Passkey op je mobiel.

[3raser]

Overal waar ik heb gewerkt, willen ze bovendien ook elke twee of drie maanden een ander wachtwoord. En een aantal keren niet gebruikt is als wachtwoord. Veel collega's werkten daarom met volgnummers. Is waarschijnlijk ook niet helemaal wat ze beogen.

Ik vind die verlooptermijn op wachtwoorden ook zo'n onzin. Dat nodigt alleen maar uit tot het gebruik van makkelijkere wachtwoorden. Want zodra je aan je random 16 karakters gewend bent geraakt kun je alweer een nieuw wachtwoord kiezen. En waarom is dat nodig? Als je wachtwoord uitlekt ben je binnen die 3 maanden ook wel de sjaak dus daar ga je niets winnen.

[naftebakje]

Als je wachtwoord uitlekt gaat het om uren, dan is het verschil tussen 5-jaarlijks en 3-maandelijks wijzigen van wachtwoorden inderdaad onzin. Een goed wachtwoord lange tijd gebruiken is veiliger.

Ik heb altijd één vraag aan IT'ers die wachtwoordpolicy's opleggen zonder 2fa: mijn bankkaart is veilig met 4 cijfers die nooit verplicht veranderen (bij twijfel of iemand meekeek uiteraard wel). Waarom zou 4 cijfers geen veilig wachtwoord zijn

Veilig is:
- 2FA
- Wachtwoord verloopt niet, maar bij twijfel (gebruikt op een "onbekende" PC) moet je het aanpassen.
- Geen wachtwoordregels (maar sterke aandrang naar bepaalde lengte en complexiteit, en check tegenover gekende gelekte wachtwoorden).
- Duidelijk gekende procedure bij verlies of diefstal wachtwoord of 2FA token (gevalletje crimineel met een grote moersleutel is sterker dan het meest complexe wachtwoord).

[JBVisual]

Er bovenop kan je eventueel het nog eens extra beveiligen, al onze klanten zijn inmiddels gewend aan het feit:
-dat alleen geregistreerde apparaten toegang hebben tot bedrijfsresources
-registreren van nieuwe apparaten alleen kan op de IP-adressen van hun kantoor
-registeren alleen kan als je tijdelijk bent toegevoegd aan de securitygroep die dit mogelijk maakt

-op adressen vanuit waar gewerkt kan worden alleen de landen betreft binnen de werkregio. (Met een tijdelijke uitzondering die geheel automatisch start en stopt nadat die ingesteld is)

Sindsdien hebben we in de afgelopen 4 jaar geen enkele melding meer gehad van mogelijk misbruik. (Uiteraard zijn nagenoeg alle applicaties SSO gekoppeld met het Microsoft account)
Datalekken met SAAS diensten buiten ons beheer staan hier uiteraard buiten.

[Orangelights23]

De best practices schrijven voor dat ww’s niet meer gewijzigd hoeven te worden, maar moeten bestaan uit een wachtwoordzin.

[lenwar]

Wortel123!! Is ook al heel sterk hoor volgens menig systeem.

Dit is een lastige in de praktijk. Door te zeggen minimaal 12 karakters waarvan 2 cijfers en 'speciaal teken' valt er met brute-force aanvallen al heel erg veel af, die je niet hoeft te proberen. Ook voor het gebruik van rainbowtables waar mijn en jouw voorbeeld zeker weten in zitten, maak je het ook al makkelijker.

Ik denk zelf dat het voornamelijk handig is voor 'meekijkers' (fysiek over de schouder) en 'gokkers'.

Onder aan de streep zouden de inlog-gebruikersnaam en het wachtwoord idealiter twee willekeurige strings moeten zijn. (Er is tenslotte geen reden dat je e-mail adres of je screenname je inloggebruikersnaam moeten zijn. Lezen jullie mee Tweakers? 🤓)

Ook voor een wachtwoordherstel vul je dan je e-mail adres in, ipv je gebruikersnaam. (Desnoods een combinatie).

Iedereen die deze website bezoekt weet nu al de helft (of een derde) van je credentials. En dat is nergens voor nodig.

[Reactie gewijzigd door lenwar op 20 juni 2025 14:23]

[PaulHelper]

Met je tweede punt ben ik het deels eens, een tweede bekende zoals gebruikersnaam kan nog iets beter zijn maar bij een sterk wachtwoord zou het aanval technisch denk ik niet veel verschil maken als je ze op een zelfde plek hebt (password manager).
Dit gaat ook alleen fijn zijn als er een dedicated username en email stuk komt in password managers. Ik heb er nu een hekel aal als er een losse vereiste gebruikersnaam is voor inloggen omdat ik dan moet kiezen tussen de email of gebruikersnaam in het 'gebruikersnaam' vakje zetten. En dan handmatig email in notities ofzo.

[lenwar]

Je hebt hier te maken met meerdere vormen van beveiliging. Waar wil je je voor en tegen beveiligen, is de vraag wezenlijk.

Een gestolen database met gehashte wachtwoorden kan geautomatiseerd tegen bekende hashes aan gehouden worden. (er zijn databases met SHA-256 hashes van wachtwoorden). Dus daar kan een salt (en of pepper) bij helpen. Dan heb je tenslotte niets meer aan de gehashte wachtwoorden, tenzij je ze één voor éen gaat brute-forcen (en nog wat andere zaken, als mensen die hetzelfde wachtwoord hebben gekozen, maar dan wel een andere salt hebben enzo)).

Ook de gebruikersnaam kan in principe gewoon gehashed in de database bewaard worden, zodat ook die niet goed leesbaar is. Het is een kwestie van secure-by-design. En dat is lastig te veranderen bij een bestaand design.

Als je een wachtwoordmanager gebruikt, dan voegt het nog steeds wat toe, mits je die wachtwoordmanager extreem goed beveiligd. (bijzonder sterk wachtwoord, inclusief een extra private key, of aan de hardware van je telefoon of Yubikeys laten koppelen en zo (wat ook weer andere consequenties heeft)). Als je database gestolen is, en ontsleuteld is, dan ben jij als individu het bokkie, maar veelal is het voor kwaadwillenden veel interessanter om van veel mensen data te hebben. (als je persoonlijk getarget wordt, dan gaan we een hele andere kant op )

Als je wachtwoordmanager niet de optie heeft om een gebruikersnaam en e-mail adres los op te slaan, dan zou ik naar een andere zoeken om eerlijk te zijn, maar goed. Dat ben ik . Ik zie net op screenshots dat KeePass het niet heeft(, en volgens de FAQ gaan ze het ook niet toevoegen.) Ik gebruik zelf Enpass, en daar kan ik het gewoon invullen. (een los veld voor een e-mail adres, en een los veld voor een gebruikersnaam). (voor zover het van belang is om op te slaan welk e-mail adres er bij een account hoort, maar dan kan inderdaad praktisch zijn.)

Fun fact: Bij een gestolen database, heeft TOTP bijvoorbeeld helemaal geen nut meer. (althans. Je moet dan je gedeelde string vernieuwen). TOTP is tenslotte slechts een 'shared secret' (beide kanten hebben dezelfde informatie onversleuteld (of ontsleutelbaar) opgeslagen, anders kunnen ze die cijfers niet genereren.

Dit gezegd hebbende. TOTP is wel een goed idee. Het is in elk geval beter dan helemaal geen 2FA.

[PaulHelper]

Sorry maar je doet nu net alsof los username zo globaal een ding is, ik zit nu bij bitwarden en ik kan handmatig velden toevoegen maar dat is niet hetzelfde. Voor zover ik weet zijn username supported password managers op 1 hand te tellen.

En je laatste punten zijn waarom ik niet in mijn password manager TOTP store maar die los houdt

[Reactie gewijzigd door PaulHelper op 20 juni 2025 17:36]

[lenwar]

Oké? Als jij het zegt. Daar verbaasd me dan heel erg. Ik vind het niet meer als normaal om een gebruikersnaam en een e-mail adres als gescheiden objecten te hebben.

voor birwarden is er in elk geval vraag naar:

https://community.bitwarden.com/t/add-username-and-email-as-separate-entries-for-vault-login-items/5808/20 😊

Maar voor mij zou het een reden zijn om iets anders te zoeken. Voor mij is dat echt iets heel basaals

[Reactie gewijzigd door lenwar op 20 juni 2025 17:38]

[PaulHelper]

Ik ben het opzich met je eens dat het logisch is maar dat veranderd de applicaties die er zijn niet.

[qlum]

Voor wachtwoorden zou gewoon een entropiecheck veel beter zijn, voor de gebruiker gewoon een balkje. Werkt best goed vanuit keepassxc. Wortel123!! zou zwak zijn met 32 bits waar 57760811074 een sterker maar nog steeds zwak wachtwoord is met 36 bits en mqbrnnfxurtiikkf dan sterk is met 75 bits.

[lenwar]

Dat is ook een methode. Uiteindelijk ligt het er aan waar je je tegen wil beschermen. Mijn voorbeeld is uiteraard gewoon stom, omdat die zeker weten in een rainbow table staat. Jouw voorbeelden zijn al minder waarschijnlijk.
Onder aan de streep (als het gaat om brute-force) is, hoe langer hoe beter. Als het gaat om social engineering moet je iedere vorm van woorden die iets voor je betekenen vermijden. (Namen van partners/kinderen/voetbalclubs/merken/personages/enz)
Als je geen wachtwoordmanager ter beschikking hebt, is bijvoorbeeld passphrase een goede (een relatief sterke zin)

De zwakkere apparaten zijn veelal pc's. Als je op je pc inlogt met een wachtwoord, dan is dat zelden zo'n 'string-wachtwoord van 40 karakters' omdat dat niet te doen is.

Eindconclusie: wachtwoorden zijn ruk, en we moeten er eigenlijk zo snel mogelijk vanaf, ten faveure van paskeys of zo.

[3raser]

...maar grote bedrijven maken wél vaker gebruik van het Https-protocol.

Waarom blijven kleine bedrijven achter qua https? Met de komst van Let's Encrypt is er toch vrijwel geen reden meer om geen gebruik te maken van https?

[lenwar]

Foutje in het artikel. Het gaat om HSTS niet om HTTPS Ik zal hem melden.
https://www.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2025/cybersecuritymonitor-2024/2-cybersecuritymaatregelen-door-bedrijvenwww.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2025/cybersecuritymonitor-2024/2-cybersecuritymaatregelen-door-bedrijven

edit:

Linkje toegevoegd.

[Reactie gewijzigd door lenwar op 20 juni 2025 13:58]

[grimson]

Ondertussen heeft KPN/XS4All heeft nog steeds geen MFA op hun e-mailsystemen. Eigenlijk toch raar als je er over nadenkt.

[The Zep Man]

2FA op webmail is prima in te richten.

2FA op IMAP/SMTP is bijna niet (praktisch) in te richten door beperkingen in veel mail clients die zich voor OAUTH enkel richten op de grote jongens (Google, Microsoft). Daar wordt wel aan gewerkt bij bijvoorbeeld Thunderbird om dat makkelijker te maken, maar dat duurt nog wel even.

[Reactie gewijzigd door The Zep Man op 20 juni 2025 14:27]

[Memori]

Ik erger me wel de tering aan bedrijven die hun eigen 2FA app aanbieden. Laat mij gewoon met Aegis werken. Verder is het jammer dat FIDO2 vaak wordt vergeten. Maar het ergste is nog wel DIGID (OK - niet echt 2FA). Het duurt bijna een minuut om daar doorheen te komen met de 10 handelingen die je moet doen.

[Reactie gewijzigd door Memori op 20 juni 2025 14:57]

[dsdevries]

Ik ben het hier volledig mee eens. Ik ben al tijden bezig de beveiliging van mijn accounts naar een hoger niveau te tillen.
Alle accounts hebben hun eigen e-mail alias d.m.v. Apple HideMyEmail.
Alle accounts hebben een random generated password
Alle accounts die het aanbieden hebben Passkeys (FIDO2)
Alle accounts die het aanbieden hebben TOTP via HOTP
Alle accounts die het aanbieden hebben een andere form van 2FA enabled.
Voor alle accounts die het niet toestaan om een e-mail adres te wijzigen, of geen 2FA aanbieden ben ik GDPR data removal requests aan het versturen. Het valt me echter op dat het percentage bedrijven dat 2FA aanbiedt nog steeds enorm laag is. Sommige accounts zonder 2FA zijn voor mij nog te belangrijk om op te heffen.

Ik heb er ook een hekel aan als bedrijven hun eigen 2FA hebben geïmplementeerd. Ik heb all mijn wachtwoorden, passkeys en TOTP's gewoon in de passwords app van iOS en MacOS staan en gesynchroniseerd via iCloud. Dit werkt perfect. Ik hoef geen aparte authenticator apps en al helemaal geen OTP via e-mail of SMS! Soms moet je minuten wachten op zo'n code. En sommige bedrijven hebben er zelfs voor gekozen om alleen nog maar een OTP te accepteren. Hoe is dit 2FA? Dit is dan toch gewoon weer SFA?!?! Implementeer gewoon Passkeys of HOTP!

[Reactie gewijzigd door dsdevries op 20 juni 2025 16:19]

[i7x]

Ik vond vroeger 2FA altijd erg irritant met die smsjes of zo'n losse app, maar sinds die Passwords app zo lekker werkt heb ik het overal netjes ingested, ook met random wachtwoorden en waar mogelijk passkeys. Chill om nooit zorgen te hoeven hebben over gelekte wachtwoord databases, was vroeger wel anders...

Emailadres verbergen zoals jij doet is eigenlijk ook wel een goeie, maar dan ben ik zo afhankelijk van iCloud+. Ik heb het wel, maar voelt toch niet zo chill. Maar ik heb wel een spam email speciaal voor gebruik met minder belangrijke accounts.

[Reactie gewijzigd door i7x op 20 juni 2025 17:09]

[PaulHelper]

Emailadres verbergen kan met heel veel services, bijvoorbeeld DuckDuckGo, alleen is dit niet geïntegreerd met iCloud/passwords voor zover ik weet. De mooie walled garden van APPLLEEEE

[PaulHelper]

Ja zeker waar, al heb ik dit nu vrij weinig meegemaakt.
Twilio met authy had dit met specifiek services (twitch? Blue... Mail service).
En dat DigiD een stap verder gaat vind ik niet erg als dat verbeterde veiligheid garandeert.

[Reactie gewijzigd door PaulHelper op 20 juni 2025 17:41]

[DeCo]

[zeurmodus]
Ik ga hier vast minnetjes voor krijgen, maar toch wil ik heel graag kwijt dat ik me de pleuris-erger aan 2FA en dergelijke 2-3-x-traps rakketten, als je dagelijks bij een hoeveelheid diensten tig keren in moet loggen..
En nee, dat is niet op te lossen met eenvoudigere passkeys of whatsoever, ik beheer die systemen namelijk niet. Mijn authenticator-app staat bomvol met 2FA accounts. Nog even en ik ga iets ambachtelijks doen. Broodbakken ofzo. Zo vervelend vind ik het.
[/zeurmodus]

[Deem]

Ik blijf het bizar vinden dat een bedrijf zoals Bol.com nog geen optie heeft voor tweestapsverificatie.

[qlum]

Wachtwoordsterkte naar bepaalde soorten tekens blijft ook irritant, leestekens in praktijk worden er maar een paar gebruikt, vooral ! aan het eind en dat doet niet zo veel. Ik zou eerder zeggen eis een bepaalde entropie, maar dat zie je nergens.

Persoonlijk heb ik een sort van 2 factor, alles leeft in mijn wachtwoordmanager, voor totp ook (passkey werkte niet goed toen ik het probeerde). Ik ben het lieftst niet afhankelijk van een bepaald apparaat voor 2 factor.

[mr_evil08]

Wachtwoorden zijn onveilig in algemeen want mensen gebruiken het bij meerdere diensten, mag je wachtwoord wel sterk zijn maar als iemand lekt ligt die toch echt op straat.

[Reactie gewijzigd door mr_evil08 op 21 juni 2025 14:11]