Cybersecurityonderzoekers ontdekken dataset met 26 miljard uitgelekte records

Cybersecurityonderzoeker Bob Dyachenko en Cybernews hebben een dataset ontdekt met daarin 26 miljard uitgelekte records. De database is opgebouwd uit gegevens van meerdere cyberinbreuken en bestaat niet alleen uit onlangs gestolen gegevens.

Cybernews meldt dat het gros van de gestolen data afkomstig is van de Chinese techgigant Tencent. Het gaat hierbij om 1,5 miljard records. Bij het Chinese sociale medium Weibo gaat het om ruim 500 miljoen records en bij het sociale medium MySpace om 360 miljoen. Deze bedrijven worden gevolgd door het sociale medium X, met 281 miljoen records. Het bedrijf stond voorheen bekend als Twitter.

Andere bekende bedrijven in de lijst zijn NetEase, Deezer, LinkedIn, Zynga, Adobe, MyFitnessPal, Canva, JD.com en Badoo. Daarnaast bevat de uitgelekte database ook gegevens van overheidsorganisaties uit onder meer de Verenigde Staten, Duitsland en Turkije. De volledige lijst met websites uit de ontdekte dataset is in te zien op de site van Cybernews.

In totaal gaat het om ruim 12TB aan data, waaronder wachtwoorden en gebruikersnamen. Volgens Cybernews heeft de uitgelekte dataset een omvang van 'niet eerder geziene proporties'. Ter vergelijking: de site rapporteerde in 2021 over een comb, oftewel een combination of many breaches, met daarin 3,2 miljard records. Cybernews sprak toen over 'de grootste inbreuk aller tijden'.

Reacties (40)

[Votlook]

Hoe is het inmiddels gesteld met Passkeys? Voorkomt dat zulke breaches/datalekken? Ik denk dat maar weinig mensen hun wachtwoorden (regelmatig) vervangen tegenwoordig, ondanks dat steeds meer mensen zich bewust zijn van de gevaren.

[Anoniem: 1576590]

Votlook schreef:

Hoe is het inmiddels gesteld met Passkeys?

Het gaat langzaam, om meerdere redenen (deze kan ik nu zo snel bedenken):

1) Websites die nog geen WebAuthn voor FIDO2 hardware keys ondersteunen, hebben een hele kluif aan het implementeren en testen.

2) De kinderziektes zijn er nog niet uit. Het is niet moeilijk om op een Android smartphone in 1x alle in "Google Password Manager" opgeslagen passkeys te deleten - zonder dat er vervolgens een backup van bestaat. Ik kan reproduceren dat je het synchroniseren naar een ander (meestal nieuw) toestel kunt saboteren (hoe dit kan heb ik uitgeplozen nadat het mij, tijdens tests, bij toeval was overkomen).

3) Pas als alle belangrijke wachtwoordmanagers passkeys ondersteunen, zit je hopelijk niet vast aan zwaar irritante vendor lock-in. Hopelijk kun je dan ook zelf een backup maken van de private keys van jouw passkeys, maar eigenlijk gaat dat tegen de filosofie in dat je daar zelf niet bij moet kunnen.

4) Wat ik onder 2 en 3 schreef betekent dat account lockout niet denkbeeldig is. Precies daarom zal er een alternatieve inlogmethode moeten blijven bestaan, die zelden phishing-resistant is (zoals een recovery code).

5).Er bestaat nog geen echt stabiele webauth standaard, en bovendien zijn er interpretatieverschillen mogelijk en die bestaan ook in de praktijk, zoals over de (m.i. stomme) optie "Preferred" voor enkele parameters.

Apple ontkent dat het hierbij om een bug gaat, maar als ik in de iPhone/iPad instellingen in "Touch ID en toegangscode" de instelling "Autom. invullen wachtw." uitzet (deze staat altijd uit als je geen Touch ID en vermoedelijk ook als je geen Face ID gebruikt), kan ik op sommige websites inloggen met passkey zonder biometrie en zonder passcode, door het invoerveld voor het user-ID te activeren (dit is de zogenaamde WebAuthn Conditional UI" modus).

Dat geldt voor meerdere demo-websites, in elk geval https://webauthn.io en https://passkeys-demo.appspot.com (op beiden moet je eerste een dummy account aanmaken).

De reden daarvoor, volgens Apple, is dat die sites als default de instelling "Preferred" voor user verification gebruiken (bij webauthn.io kan ik dit op "Required" zetten en dan werkt het toch, ik weet niet waarom).

Op github lukt mij dat overigens niet, maar ik weet niet of github dit op de een of andere manier ondervangt.

5) Veel te veel focus op het gebruik van asymmetrische cryptografie; het belangrijkste aan Passkeys is dat software de domeinnaam van de website checkt waardoor phishing erg lastig is (goede wachtwoordmanagers doen dat ook).

6) Zelden relevant, maar het komt voor dat fake sites de bekende domeinnaam gebruiken en daar (onterecht) een certificaat voor verkregen hebben. In dat geval bieden Passkeys en FIDO2 hardware keys GEEN bescherming.

Votlook schreef:

Voorkomt dat zulke breaches/datalekken?

Voorkómen zeker niet, en jouw login-secret zou niet het eerste moeten zijn waar je je zorgen over maakt na een lek.

Als de public key van een passkey op straat belandt is dat, in theorie, minder erg dan een sterke afgeleide van een sterk en uniek wachtwoord.

In de praktijk kan een aanvaller jouw passkey-public-key door de hare/zijne hebben vervangen, of een extra hebben toegevoegd, dus de praktijk is weerbarstiger.

Votlook schreef:

Ik denk dat maar weinig mensen hun wachtwoorden (regelmatig) vervangen tegenwoordig, ondanks dat steeds meer mensen zich bewust zijn van de gevaren.

Dat is ook helemaal niet nodig als je sterke en unieke wachtwoorden gebruikt (wat nagenoeg onmogelijk is zonder wachtwoordmanager).

Aanvulling 23:44: de Apple bug die ik noemde is ook in iOS 17.3 nog niet gerepareerd.

[Reactie gewijzigd door Anoniem: 1576590 op 25 juli 2024 17:20]

[bluegoaindian]

Votlook schreef:

[...]

Het gaat langzaam, om meerdere redenen (deze kan ik nu zo snel bedenken):

1) Websites die nog geen WebAuthn voor FIDO2 hardware keys ondersteunen, hebben een hele kluif aan het implementeren en testen.

2) De kinderziektes zijn er nog niet uit. Het is niet moeilijk om op een Android smartphone in 1x alle in "Google Password Manager" opgeslagen passkeys te deleten - zonder dat er vervolgens een backup van bestaat. Ik kan reproduceren dat je het synchroniseren naar een ander (meestal nieuw) toestel kunt saboteren (hoe dit kan heb ik uitgeplozen nadat het mij, tijdens tests, bij toeval was overkomen).

3) Pas als alle belangrijke wachtwoordmanagers passkeys ondersteunen, zit je hopelijk niet vast aan zwaar irritante vendor lock-in. Hopelijk kun je dan ook zelf een backup maken van de private keys van jouw passkeys, maar eigenlijk gaat dat tegen de filosofie in dat je daar zelf niet bij moet kunnen.

4) Wat ik onder 2 en 3 schreef betekent dat account lockout niet denkbeeldig is. Precies daarom zal er een alternatieve inlogmethode moeten blijven bestaan, die zelden phishing-resistant is (zoals een recovery code).

5).Er bestaat nog geen echt stabiele webauth standaard, en bovendien zijn er interpretatieverschillen mogelijk en die bestaan ook in de praktijk, zoals over de (m.i. stomme) optie "Preferred" voor enkele parameters.

Apple ontkent dat het hierbij om een bug gaat, maar als ik in de iPhone/iPad instellingen in "Touch ID en toegangscode" de instelling "Autom. invullen wachtw." uitzet (deze staat altijd uit als je geen Touch ID en vermoedelijk ook als je geen Face ID gebruikt), kan ik op sommige websites inloggen met passkey zonder biometrie en zonder passcode, door het invoerveld voor het user-ID te activeren (dit is de zogenaamde WebAuthn Conditional UI" modus).

Dat geldt voor meerdere demo-websites, in elk geval https://webauthn.io en https://passkeys-demo.appspot.com (op beiden moet je eerste een dummy account aanmaken).

De reden daarvoor, volgens Apple, is dat die sites als default de instelling "Preferred" voor user verification gebruiken (bij webauthn.io kan ik dit op "Required" zetten en dan werkt het toch, ik weet niet waarom).

Op github lukt mij dat overigens niet, maar ik weet niet of github dit op de een of andere manier ondervangt.

5) Veel te veel focus op het gebruik van asymmetrische cryptografie; het belangrijkste aan Passkeys is dat software de domeinnaam van de website checkt waardoor phishing erg lastig is (goede wachtwoordmanagers doen dat ook).

6) Zelden relevant, maar het komt voor dat fake sites de bekende domeinnaam gebruiken en daar (onterecht) een certificaat voor verkregen hebben. In dat geval bieden Passkeys en FIDO2 hardware keys GEEN bescherming.

Votlook schreef:

[...]

Voorkómen zeker niet, en jouw login-secret zou niet het eerste moeten zijn waar je je zorgen over maakt na een lek.

Als de public key van een passkey op straat belandt is dat, in theorie, minder erg dan een sterke afgeleide van een sterk en uniek wachtwoord.

In de praktijk kan een aanvaller jouw passkey-public-key door de hare/zijne hebben vervangen, of een extra hebben toegevoegd, dus de praktijk is weerbarstiger.

Votlook schreef:

[...]

Dat is ook helemaal niet nodig als je sterke en unieke wachtwoorden gebruikt (wat nagenoeg onmogelijk is zonder wachtwoordmanager).

Aanvulling 23:44: de Apple bug die ik noemde is ook in iOS 17.3 nog niet gerepareerd.

Password managers dus als keepassXC dat op een encrypted partitie.
is dus nog altijd t beste.

[Luchtbakker]

Het grote voordeel van passkey is dat deze uniek is voor elke website. Is er dus een lek geweest op site A dan kan je met deze passkey niet bij site B inloggen.

[Anonymoussaurus]

Dat is eigenlijk alleen een voordeel als je dus géén unieke/moeilijke wachtwoorden gebruikt. Zolang je moeilijke en unieke wachtwoorden gebruikt is het qua veiligheid namelijk soortgelijk.

[Luchtbakker]

Jij en ik weten heel goed dat bijna niemand dat doet.

[Anonymoussaurus]

Klopt, maar aangezien Votlook het vroeg en hij hier op Tweakers zit, ging ik er maar even vanuit dat hij dat wel doet. En dan is het natuurlijk wel belangrijk te weten dat er in die situatie niet zoveel verschil is natuurlijk.

[SenkZ]

Is het feit dat je bij een klassiek wachtwoord deze altijd over het netwerk moet sturen. Terwijl je bij passkey slechts een afgeleide token van je secret stuurt. Geen noemenswaardig voordeel?

[Anoniem: 1576590]

SenkZ schreef:

Is het feit dat je bij een klassiek wachtwoord deze altijd over het netwerk moet sturen. Terwijl je bij passkey slechts een afgeleide token van je secret stuurt. Geen noemenswaardig voordeel?

Nee, helaas niet.

Want zodra je "ingelogd" bent ontvangt jouw browser een 1FA "token", bijv. in de vorm van een session-cookie of JWT, dat over dezelfde lijn gaat.

Als een aanvaller kan meelezen "op die lijn" (of uit de cache van jouw browser), kan zij of hij zo'n token gebruiken om in te loggen als jou. Je zult dus sowieso die lijn moeten kunnen vertrouwen.

Een recente en m.i. aardige uiteenzetting hierover (meerdere posts) van user "dm" las ik hier (infosec.exchange).

Hij verwijst daarbij naar een project DBSC van Google medewerkers op github (DBSC = Device Bound Session Credentials), maar dat realiseren is een stuk lastiger dan je denkt (vooral zonder TPM-achtige hardware).

Je kunt bijv. niet zomaar aan een IP-adres koppelen, want roamende smartphones kunnen een ander adres krijgen.

[Dark Angel 58]

Het grote voordeel van passkey is dat deze uniek is voor elke website. Is er dus een lek geweest op site A dan kan je met deze passkey niet bij site B inloggen.

Echt waar? ook niet met hetzelfde vingerafdruk?

[Anoniem: 1576590]

Door Dark Angel 58:

ook niet met hetzelfde vingerafdruk?

Als ik het allemaal goed begrijp, werkt het als volgt op bijv. een smartphone.

1) In de smartphone zit een speciale chip, ook wel secure enclave genoemd, waarin allerlei secrets kunnen worden bewaard.

2) Eén van die secrets is een (symmetrische) sleutel om private keys van passkeys te versleutelen en te ontsleutelen. Elke versleutelde private key zit in een database record met verder onversleutelde gegevens, zoals de domeinnaam van de website, jouw user-ID en diverse metadata. Die database bevat dus records met daarin meerdere velden, waaronder een versleutelde private key.

3) De secure enclave geeft die sleutel pas vrij (aan een vertrouwd proces) nadat de gebruiker met biometrie of toestel-ontgrendelcode heeft bevestigd aan de knoppen te zitten.

4) Als je voor een account een passkey aanmaakt, wordt een random asymmetrisch sleutelpaar gegenereerd. De public key daaruit wordt "als wachtwoordvervanger" opgeslagen op de server, en de private key wordt versleuteld opgeslagen in een nieuw record in bovengenoemde database.

5) Synchronisatie van de database tussen meerdere devices vereist dat elk device dezelfde sleutel in diens "secure enclave" heeft. Hoe die sleutel zelf -veilig- naar een nieuw te koppelen device wordt gestuurd, weet ik niet precies. Wel weet ik dat je, in elk geval op Android, op een nieuw toestel niet meteen passkeys moet gaan aanmaken, want dan genereert of krijgt dat toestel een nieuwe (unieke) sleutel. Als daarna de passkey database vanaf een ander (oud) toestel gesynchroniseerd wordt, werken de passkeys daaruit niet op jouw nieuwe toestel (omdat de oude private keys met een andere sleutel versleuteld zijn).

6) Het maakt niet uit op welke wijze je jouw nieuwe toestel unlockt (vingerafdruk, gezichtsscan, pin of wachtwoord): dat is alleen maar een middel om een sleutel vrij te geven.

7) De bug in iOS/iPadOS die ik eerder noemde is vermoedelijk het gevolg van een samenloop van omstandigheden: de sleutel wordt daarbij onterecht vrijgegeven als aan bepaalde voorwaarden wordt voldaan. Volgens Apple is dat als de website voor "User verification" de waarde "Preferred" opgeeft - wat Apple uitlegt als "niet nodig", terwijl ik dat uit zou leggen als "doen als het kan".

Kortom, passkeys zijn op geen enkele wijze afgeleid van jouw vingerafdruk.

[epoman]

Dat voorkomen ze niet, lijkt me? Als passkeys enkel 'sleutels' tot een account zijn, kun je nog steeds accountdata buitmaken. Alleen kun je met die accountdata wellicht iets minder eenvoudig toegang tot andere accounts van dezelfde gebruiker krijgen.

[Reactie gewijzigd door epoman op 25 juli 2024 17:20]

[kftnl]

WebAuthn ('passkeys') maakt gebruikt van public key cryptografie, je steelt dus niet de 'sleutel', maar alleen de uitkomst van een berekening met die sleutel op een bepaalde challenge. Mits verstandig geïmplementeerd door de app/website is die al heel snel nutteloos. Het zal meestal nog steeds eventjes mogelijk zijn om data te stelen, maar je kunt dan normaal gezien niet opnieuw toegang tot de site krijgen.

[Reactie gewijzigd door kftnl op 25 juli 2024 17:20]

[Anoniem: 1576590]

kftnl schreef:

WebAuthn ('passkeys') maakt gebruikt van public key cryptografie, je steelt dus niet het de 'sleutel', maar alleen de uitkomst van een berekening met die sleutel op een bepaalde challenge.

Klopt allemaal, maar als de aanvaller, die toegang heeft tot de accounts-database, jouw passkey-public-key vervangt door die van haar of hem, of een nieuwe koppelt aan jouw account, dan schiet je weinig op met die asymmetrische cryptografie.

Een passkey-public-key zit (helaas?) niet in een certificaat waarin staat van wie precies die pubkey is (ondertekend door een betrouwbare TTP). In revocation (bijv. na verlies of diefstal van een smartphone) is overigens ook niet voorzien.

kftnl schreef:

Het zal meestal nog steeds eventjes mogelijk zijn om data te stelen, maar je kunt dan normaal gezien niet opnieuw toegang tot de site krijgen.

Je hebt niet voor niets ergens een account. Als de database die door de aanvaller gekopiejat wordt meer vertrouwelijke gegevens van/over jou bevat, of als de aanvaller ook een andere database met dat soort data kan kopiejatten en/of daarin wijzigingen aanbrengen, dan lijkt mij dat het grootste probleem.

Een uitzondering hierop zou kunnen zijn dat je een zwak wachtwoord hebt gebruikt dat je ook voor andere sites inzet (en wellicht niet eens meer weet welke sites allemaal). Met als gevolg dat en je een puist werk kunt hebben aan het overal wijzigen van dat wachtwoord. En als je niet snel genoeg bent, riskeert dat er meer accounts van jou gehacked worden.

[Reactie gewijzigd door Anoniem: 1576590 op 25 juli 2024 17:20]

[epoman]

Ah, ja. Doelde ook meer op situaties waarin ze bijvoorbeeld via een andere route toegang hebben tot achterliggende systemen/databases. Accountdata omvat meestal meer dan credentials. Voor het beveiligen van individuele accounts lijkt het me in veel gevallen een prima oplossing idd.

[Anonymoussaurus]

Dit is alweer van een tijdje geleden: review: Sterven wachtwoorden uit? - Passkeys moeten nieuwe inlogstandaard worden, maar er zijn nog genoeg andere bronnen te vinden.

Verder denk ik dat het meer een kwestie is van weten waar je allemaal een account hebt bijvoorbeeld. Mensen die dat niet bijhouden, gaan dan vergeten waar ze een account hadden, waardoor je dus ook je wachtwoord niet meer kan wijzigen.

[magel725]

Op m'n werk heeft het management toegang tot alle windows inloggegevens en dat wordt o.a. ook gebruikt wanneer je ziek bent om bijvoorbeeld je mail te checken.

Nu heb ik een tijd lang gewoon met m'n Google account ingelogd zodat ik ook af en toe even m'n mail kon checken. Daarnaast stond WhatsApp ook open.

Nu blijkt later dat zelfs wanneer je uitlogt een ander gewoon nog zo bij al je wachtwoorden uit je Google account kan. Dat bpijft gewoon bereikbaar zonder enige moeite. Als je maar op de pc kunt inloggen kun je er bij en worden je wachtwoorden ook automatisch ingevuld. Handig wanneer je bij iemand anders of op een openbare pc inlogt.

Op deze manier heeft een password manager geen zin en is zelfs gevaarlijk. Ook is het heel makkelijk praktisch bruikbaar.

Ik kijk zelf niet meer op van mails dat m'n wachtwoorden gelekt zijn en ik vind het ook wat minder risico omdat ik overal random wachtwoorden heb, maar als je maar even niet oplet ben je alsnog kwetsbaar door iets stoms.

[DataGhost]

Je browser is dan ook geen fatsoenlijke password manager. Gebruik een van de gangbare echte password managers die je nog apart moet unlocken met credentials die niet in beheer zijn bij een ander (zoals je werkgever).

[Omnicron1]

Huh ?
Dat is nog al wat
Kijk controle op eigen infra okee, snap ik, maar er is toch echt een grens.
Werk en prive. waarom dan alle inlog gegevens? Werk je soms bij Big brother of zo ?

[magel725]

Het is een werk pc waarop ik zelf de keuze maak om ook iets privé te doen. Heb dit al uitgezocht maar ze mogen dit gewoon doen. Dan moet ik gewoon uit prive stuff uitloggen erna, alleen Google zelf doet dat niet ook al log je uit. Als je in Google wachtwoorden opslaat en je logt ooit bij een ander in met Google dan kunnen ze gewoon overal bij ook al log je weer uit.

[Pietervs]

Op m'n werk heeft het management toegang tot alle windows inloggegevens en dat wordt o.a. ook gebruikt wanneer je ziek bent om bijvoorbeeld je mail te checken.
Ik zou dit niet accepteren. Het management heeft niks te maken met jouw account. Als er nu iemand een leuke Ferrari besteld uit jouw naam heb jij het probleem dat je aan mag tonen dat jij het niet geweest bent.

Als directie bij e-mails wil kunnen die jij ontvangt/verzendt moeten ze daar een algemene mailbox voor inrichten (verkoop@bla of zo).

[Paulus07]

Misschien een gekke vraag maar hoe nuttig is het nog om bijvoorbeeld een [mailadres]+[naamwebsite.domein.nl te hanteren om eventueel te achterhalen waar een lek vandaan komt? Worden door hackers niet gewoon die waardes achter een + of punt etc eraf gestript? Of nog steeds raadzaam om dit te blijven hanteren?

[markjanssen]

Dat heeft voordelen en nadelen... voordeel is inderdaad dat je bij een spamrun of lek kan zien waar ze het mailadres vandaan hebben, nadeel is dat je dan al die honderden verschillende adressen moet checken op haveibeenpwned, vs een handje vol.

[JSD00]

Als ik me niet vergis kun je ook een compleet domein in de gaten houden via HaveIBeenPwnd. Moet je net even je domeinnaam met een TXT-record verifiëren.

[SirLenncelot]

Ja klopt. Maar de meeste reguliere gebruikers hebben een Hotmail of Gmail adres. Dus dan gaat die vlieger niet op.

[Paulus07]

Dat is een goeie inderdaad mbt controleren via een haveibeenpwned of een monitor.mozilla.org
Dan ga je jezelf daar weer moeilijk mee maken....
Ook dus nog niet helemaal de 100% handigste oplossing tegen dit soort dingen. Nog keer iets op verzinnen met bijvoorbeeld gebruik van een gmail account.

[JSD00]

Daarom is een catch-all op je eigen domeinnaam zo leuk

[John Doos]

Yes hier ook, 3 domeinen, 3 catchalls.
Worden allemaal opgevangen bij het [e-mail]

En direct geforward en verwijdert naar mijn prive proton. Daar, zo is er een [e-mail] en een wehkamp@mijndom... etc.

Hoef maar maar 1 mailbox in de gaten te houden, en zodra er spam gericht word op een adres dan kan ik dat makkelijk tegenhouden.

Ik kan dat iedereen aanraden, ik ben van 100+ ongewenste mailtjes per week, naar 1 a 2 per dag gegaan. En die spoor ik ook een voor een op

[zhoreb]

Daar gebruik ik simplelogin voor, in combinatie met Proton.
Elke site, webshop, list krijgt zijn eigen unieke e-mailadres. Heb het niet gekoppeld aan een eigen domein. Maar elke alias kun je koppelen aan een van je mail accounts. Replies gaan ook via de alias.

Een voorbeeld adres is dan [e-mail]. Het beheer van de aliassen is zeer eenvoudig. Te veel spam op een alias? Weg er mee.

[Reactie gewijzigd door zhoreb op 25 juli 2024 17:20]

[Defspace]

Je kan ook op gmail en alias toevoegen.
Dus [e-mail] en je weet dat je dat account hebt gebruikt op tweakers

[huiz]

Het nadeel is dat niet iedere website een plus-teken accepteert in een mailadres.

[e.dewaal]

En de spammers kennen dit trucje ook en verwijderen simpelweg met een scriptje de plus en alle karakters daaropvolgend tot het apenstaartje.

[DataGhost]

Dat is alsnog veel. Ik gebruik geen catchall maar een whitelist (en greylisting) en ik ben van een soortgelijk aantal zo'n 15 jaar geleden naar ondertussen 1 a 2 per jaar gegaan.

[Dysnake]

Vraagje, hoe lang duurt het eer zoiets verschijnt op haveibeenpwned?

[Bender]

Het is maar net de vraag wat het precies is.
Een dataset wil niet zeggen dat er een gebruikersnaam/wachtwoord is, het kan bij wijze van ook het publiekelijke gedeelte van je linkedin profiel zijn.

[Christoxz]

In totaal gaat het om ruim 12TB aan data, waaronder wachtwoorden en gebruikersnamen.

Zitten toch echt login gegevens bij.

[Bender]

Zitten er bij inderdaad, omdat het vele datasets zijn, maar zullen dus niet allen dit soort info bevatten.

[Boyd]

Misschien is het wel de dataset van haveibeenpwned

[Morress]

Ach, dat is het al eens eerder gelekt

[ultimasnake]

Ik denk dat we gerust kunnen stellen dat van iedereen op aarde, met minstens af en toe online activiteit, er minstens 1x data is gelekt. Wat en hoe erg dat is valt te bezien maar vermoed dat ik niet ver van de waarheid zit

Het wordt dan ook echt tijd dat je echte identiteit (adresgegevens, telefoonnr, betaalgegevens en vooral identificatiegegevens zoals paspoort/id-kaart) in eigen beheer gaat genomen worden want er zullen zoveel bedrijven zijn die jouw data hebben waar je jezelf niet eens bij hebt ingeschreven dat het aanvoelt als een ‘lore ijsberg’… je bent nooit baas van je eigen data geweest en dat gaan we nu echt wel meer en meer merken ben ik bang