Autoriteit Persoonsgegevens wijst op problemen bij afknippen van hashes
Organisaties die zeggen zij anonieme gegevens verwerken doordat de data 'gehasht en afgeknipt' is gaan bij deze vorm van anonimisering vaak de fout in, waardoor de gegevens toch niet anoniem blijken te zijn. Dat stelt de Autoriteit Persoonsgegevens dat op praktische problemen wijst bij het afknippen van hashes.
Een manier om gegevens te anonimiseren is het gebruik van k-anonimity. Hierbij wordt een dataset zo veranderd dat iedere combinatie van attributen altijd minstens k keer voorkomt. "Onder de juiste omstandigheden en als k groot genoeg is, is het herleiden van personen dan onmogelijk. Iedere persoon maakt dan deel uit van een groep gelijken. Immers (k-1) anderen hebben dezelfde attributen", aldus de privacytoezichthouder.
Het afronden van attributen is een manier om groepen te maken. In het geval van leeftijd kun je afronden op tientallen. Zo vallen personen die bijvoorbeeld 29, 27 of 21 jaar zijn allemaal in dezelfde groep, namelijk die met de leeftijd 20. Een andere methode is het afknippen, waarbij je één symbool van rechts gezien afknipt. In het gegeven voorbeeld zouden de drie personen in de groep met de leeftijd 2 terechtkomen.
Dit werkt anders bij een telefoonnummer, ip-adres of persoonlijke identifier. "Aan een afgeknipt ip-adres kun je bijvoorbeeld nog steeds zien bij welke internetprovider iemand zit en soms ook in welke omgeving deze persoon woont", laat de Autoriteit Persoonsgegevens weten. Om dergelijke bevindingen te voorkomen worden dit soort gegevens vaak gehasht.
Bij ongehashte telefoonnummers zorgt het afknippen van twee symbolen voor groepen tot 100 telefoonnummers. In het geval van gehashte telefoonnummer is elke hashwaarde uniek, ook na het afknippen van enkele symbolen. "Maar hoeveel moet je dan afknippen om van gehashte attributen groepen te maken? Het antwoord is afhankelijk van de dataset, maar in veel gevallen: bijna alles", stelt de privacytoezichthouder.
Wanneer er namelijk van gehashte attributen te weinig symbolen worden afgeknipt, bevat de datastet nog steeds persoonsgegevens. "Want te weinig afknippen van hashwaardes laat unieke identificatoren achter. En dan is er dus géén sprake van geanonimiseerde gegevens", concludeert de Autoriteit Persoonsgegevens.
Reacties (50)
30-04-2021, 12:49 door
Erik van Straten
Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Geïnteresseerden kunnen in de PDF https://www.usenix.org/system/files/sec21fall-heinrich.pdf (bron: https://www.security.nl/posting/700126/Onderzoekers+melden+privacylek+in+Apple+AirDrop+en+ontwikkelen+alternatief) verwijzingingen vinden naar publicaties met meer informatie over deze problematiek.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Geïnteresseerden kunnen in de PDF https://www.usenix.org/system/files/sec21fall-heinrich.pdf (bron: https://www.security.nl/posting/700126/Onderzoekers+melden+privacylek+in+Apple+AirDrop+en+ontwikkelen+alternatief) verwijzingingen vinden naar publicaties met meer informatie over deze problematiek.
Een bekend voorbeeld is het maskeren van creditcardnummers. Vaak zie je alleen de laatste vier cijfers terug. Echter de eerste zes cijfers liggen vast, dat is de issuer. En de volgende zes cijfers zijn vaak voor een bepaald product en liggen dan ook vast. 6+6 cijfers die te herleiden zijn + de vier die je krijgt = een ongemaskeerd volledig creditcardnummer... Zelfs de laatste drie is niet veilig, want er zijn maar 10 pogingen nodig om het hele nummer te raden.
Als je een login database hebt, valt k-anonimity niet direct toe te passen, behalve door verschillende velden onbruikbaar te maken voor de database users (login/profiel als 2 aparte users, overige users als k-anonimity).
Het hashen van een e-mail adres is voor login databases niet effectief, dan kan je nooit een password reset laten uitvoeren zodra de database gecompromiteerd is (db global e-mail naar alle users).
Het hashen van een e-mail adres is voor login databases niet effectief, dan kan je nooit een password reset laten uitvoeren zodra de database gecompromiteerd is (db global e-mail naar alle users).
Organisaties die zeggen zij anonieme gegevens verwerken
Dat wordt dus moeilijk met een login database. Verder heeft het AP gelijk dat deze datasets beperkt moeten worden opgeslagen, dat is bijvoorbeeld van toepassing op enquete's en andere 'one time use' datasets.In Jip en Janneke-taal:
Volledig:
1MA4RK67RU65TT67EI6SE09ENLE89UGE98N123A4A2R4
Knip:
1MA4RK67RU65TT67EI6SE09ENL
Bijzonder knap dat ze bij de AP ontdekt hebben dat dit niet anoniem is. Zonder studie rechten was dit uiteraard nooit aan het licht gekomen.
Volledig:
1MA4RK67RU65TT67EI6SE09ENLE89UGE98N123A4A2R4
Knip:
1MA4RK67RU65TT67EI6SE09ENL
Bijzonder knap dat ze bij de AP ontdekt hebben dat dit niet anoniem is. Zonder studie rechten was dit uiteraard nooit aan het licht gekomen.
30-04-2021, 14:29 door
karma4
Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Datis een cirkelredenering die ook bij complotdenkers leeft en moeilijk te doorbreken is.
Jammer genoen ook bij security een verschijnsel: "Als je root hebt is dat zeer ernstig want je kan root rechten krijgen".
.. Een manier om gegevens te anonimiseren is het gebruik van k-anonimity. Hierbij wordt een dataset zo veranderd dat iedere combinatie van attributen altijd minstens k keer voorkomt. "Onder de juiste omstandigheden en als k groot genoeg is, is het herleiden van personen dan onmogelijk. ..
Wonderlijk aangezien de AP tot nu toe beweerde dat elk niveau van k-anonimity niet zou kunnen bestaan.Ze verwezen naar een chinees onderzoek die met een steekproef uit bekende tracks de zelf gegroepeerde track weer terug lon krijgen met de aanwezigheid van die bron gegevens.
Pseudonimiseren is in de GDPR als een maatregel genoemd met daarbij de inperking dat de GDPR niet voor geanonimiseerde (k-anonimity) geld. De AP heeft dat geheel eigengereid als een big brother uitgebreid alsof geanimiseerd niet mogelijk zou zijn. Met het benoemen van gepseudopnimiseerde data als zijnde geanonimiseerd is de AP in overtreding met de wettekst van de GDPR.
30-04-2021, 14:41 door
Erik van Straten
Door Anoniem: Als je een login database hebt, valt k-anonimity niet direct toe te passen, behalve door verschillende velden onbruikbaar te maken voor de database users (login/profiel als 2 aparte users, overige users als k-anonimity).
Ik vermoed dat de AP-publicatie volgt uit de WiFi-tracking boete voor Enschede (https://security.nl/posting/701247), niet zozeer i.v.m. opgeslagen klantgegevens, zie: https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/internet-telefoon-tv-en-post/internet-en-telecom#ik-pas-bij-wifitracking-en-bluetoothtracking-hashing-toe-dan-zijn-het-toch-geen-persoonsgegevens-meer-6964.Door Anoniem: Het hashen van een e-mail adres is voor login databases niet effectief, dan kan je nooit een password reset laten uitvoeren zodra de database gecompromiteerd is (db global e-mail naar alle users).
Klopt, voor zover zo'n database nog te vertrouwen is (en niet is versleuteld).Voor inloggen zou je natuurlijk wel een hash van een e-mailadres kunnen opslaan; een password-reset door de user is dan nog gewoon mogelijk (user voert e-mail adres in, browser of server berekent hash en vergelijkt met de hash in de DB, bij een match stuur je een mail met reset-token). Blijft het probleem dat aanvallers hashes van veel e-mail adressen kunnen "reversen".
30-04-2021, 14:45 door
Erik van Straten
Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Door Erik van Straten:
Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.karma4 heeft wel een punt Erik. Je moet van te voren al weten dat de input een reeks bytes was van 0 tot oneindig tekens. En het is ook handig om te weten welke hash functie er is gebruikt (als je ze niet allemaal wilt proberen). karma4 houdt zijn hash en encryptie algoritmes natuurlijk geheim. Zo heeft de aanvaller minder kans om bij zijn data te komen.
karma4 kan ook end-to-end encryptie kraken, want de sleutels staat centraal op de servers van de end-to-end encryptie.
Het is altijd een genot zijn reacties hier te lezen als het oven encryptie of over privacy gaat!
Door karma4: Wonderlijk aangezien de AP tot nu toe beweerde dat elk niveau van k-anonimity niet zou kunnen bestaan.
Ze verwezen naar een chinees onderzoek die met een steekproef uit bekende tracks de zelf gegroepeerde track weer terug lon krijgen met de aanwezigheid van die bron gegevens.
Los van de vraag of dat onderzoek als het laatste woord over dat specifieke onderwerp gezien moet worden: dat AP bij dat onderwerp naar dat onderzoek verwijst wil niet zeggen dat ze het concept van k-anonimiteit afwijzen. Dat jij er een bepaalde gedachtengang bij invult wil nog helemaal niet zeggen dat dat ook de gedachtengang van AP is geweest.Ze verwezen naar een chinees onderzoek die met een steekproef uit bekende tracks de zelf gegroepeerde track weer terug lon krijgen met de aanwezigheid van die bron gegevens.
Pseudonimiseren is in de GDPR als een maatregel genoemd met daarbij de inperking dat de GDPR niet voor geanonimiseerde (k-anonimity) geld.
Er staat in de AVG dat pseudonimiseren risico's kan verkleinen, dat het andere maatregelen niet uitsluit, en ook dat als gepseudonimiseerde gegevens die met behulp van andere gegevens aan natuurlijke personen kunnen worden gekoppeld als gegevens over een identificeerbare persoon moeten worden beschouwd (overweging 26). De AP heeft dat geheel eigengereid als een big brother uitgebreid alsof geanimiseerd niet mogelijk zou zijn. Met het benoemen van gepseudopnimiseerde data als zijnde geanonimiseerd is de AP in overtreding met de wettekst van de GDPR.
Dat klopt niet. Jij doet het steeds voorkomen alsof een verwerkingsverantwoordelijke goed zit als er maar een pseudoniem wordt ingezet. AP gebruikt als criterium de vraag of de identiteit van de betrokkene te achterhalen is. Overweging 26 gaat daarover. Als het koppelen van een natuurlijke persoon niet kan zijn het geen persoonsgegevens, als het wel kan, eventueel met behulp van aanvullende data, dan zijn het wel persoonsgegevens. Overweging 26 zegt ook dat de beschikbare technologische mogelijkheden op het moment van verwerking en technologische ontwikkelingen in acht moeten worden genomen. Dat betekent dat wat vandaag als voldoende geanonimiseerd kan worden beschouwd dat over een maand of over een jaar misschien niet meer is. Het is geen statisch oordeel.Door Erik van Straten:
Nou hij heeft wel gelijk dat je moet weten wat voor soort gegevens het zijn en hoe ze geformatteerd zijn.Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.En je moet ook het hashing- en knip algorithme weten.
Als het een totale black box is waar je alleen die hashcodes uit krijgt dan kun je daar nog niet veel mee, als je op de
een of andere manier weet hoe ze gemaakt worden is het een ander verhaal.
Door Erik van Straten:
Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Goh. Applausje waard, karma4 op een technische fout betrappen. Gebeurt anders nooit ....
Door Erik van Straten:
Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Een van de eigenschappen van een hash functie is dat je niet van terug kan "rekenen".
Dus het is heel makkelijk om de Hash-waarde van "A", te berekenen, maar je kan niet vanuit hash-waarde terug "A" vinden.
Als dat wel kan, dan is het geen hash functie.
Wat wel kan, is "A" proberen te zoeken als je andere informatie hebt over A.
Als je bijvoorbeeld weet dat "A" een 4-cijferige pincode is, dan kan je makkelijk de hash-waarde van alle 10.000 combinaties berekenen en opzoeken wat de originele pincode was. (Dergelijke data noemt men een rainbow table.)
Afhankelijk van de grootte is dit realistisch doenbaar of niet.
Theoretisch kan je steeds een "input" vinden die bij een bepaalde hash output hoort, maar dan ben je nog niet zeker dat het de originele input was. Alle hash functies hebben namelijk collisions, omdat je een onbeperke input-space op een gelimiteerde output-space mapt
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Door Erik van Straten:
Erik, kan je uitleggen waarom dat fout is?Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Als ik een 32-bit hash (ik weet het, erg kort) heb van een email adres, zeg erik@gmail.com, en ik knip daar 16 bit van af, dan zou ik toch, om een "reverse hash" aanval te kunnen doen:
- of de afgeknipte hash met alle mogelijke cijfercombinaties moeten aanvullen tot 32-bit, en voor al die combinaties een "reverse hash" berekening moeten doen (bij langere hashes erg CPU-intensief). En dan moet ik al weten dat het een email adres betreft om überhaupt te kunnen vaststellen of de reverse hash zinnig is.
- of een hash berekenen van een mogelijke set email adrressen die ik al heb, en die vergelijken met een afgeknipte hash?
Overigens denk ik dat het hier (statement van de AP) niet gaat om vanuit een hash het origineel te bepalen, maar om de situatie waarin verschillende gegevens sets, waarin een gehashed persoonsgegeven (bv. email adres) als gemeenschappelijk item/key gebruikt wordt. Als een hash lang genoeg is (bv. SHA-2 met 256-bit digest) is een halve digest nog steeds zo uniek dat de datasets nog steeds gekoppeld kunnen worden, waardoor je nog steeds unieke combinaties hebt (bv. adres uit de ene set, en inkomen uit de andere set)
Dit in plaats van bv. het laatste cjfer van je leeftijd afhalen: dan krijg je een serie adressen van mensen die tussen 20 en 29 zijn, die gekoppeld kunnen worden aan inkomens van mensen die tussen 20 en 29 zijn, dus geen 1-op-1 koppeling van bestanden mogelijk.
Q
Door Anoniem:
Er staat in de AVG dat pseudonimiseren risico's kan verkleinen, dat het andere maatregelen niet uitsluit, en ook dat als gepseudonimiseerde gegevens die met behulp van andere gegevens aan natuurlijke personen kunnen worden gekoppeld als gegevens over een identificeerbare persoon moeten worden beschouwd (overweging 26).
Pseudonimiseren is in de GDPR gedefinieerd als direct herleidbaard tot een persoon.Er staat in de AVG dat pseudonimiseren risico's kan verkleinen, dat het andere maatregelen niet uitsluit, en ook dat als gepseudonimiseerde gegevens die met behulp van andere gegevens aan natuurlijke personen kunnen worden gekoppeld als gegevens over een identificeerbare persoon moeten worden beschouwd (overweging 26).
Anonimiseren is met de WP29 en GDPR gedefinieerd als niet meer herleidbaar tot een persoon (k anomimity).
Gaat de AP die definities ter discussie stellen met gangbaar Nederlands woordgebruik dan overtreden ze de GDPR. =punt
Dat klopt niet. Jij doet het steeds voorkomen alsof een verwerkingsverantwoordelijke goed zit als er maar een pseudoniem wordt ingezet. AP gebruikt als criterium de vraag of de identiteit van de betrokkene te achterhalen is. Overweging 26 gaat daarover. ..
Zie hierboven in de GDPR is het onderscheid strikt gedefinieerd en aldaar als geheel opgenomen. Dat ze een eigen criterium met eigen uitleg willen doen is te zot voor woorden. Dat het de nederlandse wetgeving wel gebeurd moet een cultuurschok voor NL-juristen zijn.Door Anoniem: Theoretisch kan je steeds een "input" vinden die bij een bepaalde hash output hoort, maar dan ben je nog niet zeker dat het de originele input was. Alle hash functies hebben namelijk collisions, omdat je een onbeperke input-space op een gelimiteerde output-space mapt
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Op het moment dat jij een collision vindt, in bijvoorbeeld SHA-256, die dezelfde hash oplevert als de reversed hashes van karma4, dan hebben alle certificate authorities in de wereld een hele slechte dag. Dan moeten ze namelijk alle certificaten, met SHA-256, gaan vervangen omdat het hash algoritme gebroken is.
Dit is gebeurd met MD5 en met SHA-1.
Door Anoniem:
Op het moment dat jij een collision vindt, in bijvoorbeeld SHA-256, die dezelfde hash oplevert als de reversed hashes van karma4, dan hebben alle certificate authorities in de wereld een hele slechte dag. Dan moeten ze namelijk alle certificaten, met SHA-256, gaan vervangen omdat het hash algoritme gebroken is.
Dit is gebeurd met MD5 en met SHA-1.
Nee, niet waar. Collisions bestaan. Maar een sha-265 collision die je kan genereren, en die ook nog zinnige informatie bevat, dat is (nog?) niet mogelijk.Door Anoniem: Theoretisch kan je steeds een "input" vinden die bij een bepaalde hash output hoort, maar dan ben je nog niet zeker dat het de originele input was. Alle hash functies hebben namelijk collisions, omdat je een onbeperke input-space op een gelimiteerde output-space mapt
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Op het moment dat jij een collision vindt, in bijvoorbeeld SHA-256, die dezelfde hash oplevert als de reversed hashes van karma4, dan hebben alle certificate authorities in de wereld een hele slechte dag. Dan moeten ze namelijk alle certificaten, met SHA-256, gaan vervangen omdat het hash algoritme gebroken is.
Dit is gebeurd met MD5 en met SHA-1.
Met MD5 kon met collisions genereren in bv. PDF documenten, door in metadata van de pdf te manipuleren door er "willekeurige" data in te zetten zodat het gehele bestand weer dezelfde hash op leverde. Dat is wat anders dan metadata in een certificate aan te passen: er zijn niet zo veel velden die je onbeperkt kan aanpassen zonder dat het certificate ongeldig wordt. (nou ja, adres, organisatie, hele vreemde waarden in SAN) wanter zijn restricties opdat de velden nog een betekenis hebben. Je kan bv. niet een willekeurige validity start en einddatum kiezen, want er zitten format eisen aan de datum.
Dus zelfs met MD5 en SHA-1 is het eigenlijk niet mogelijk, maar men heeft het zekere voor het onzekere genomen.
Q
Door Anoniem:
Op het moment dat jij een collision vindt, in bijvoorbeeld SHA-256, die dezelfde hash oplevert als de reversed hashes van karma4, dan hebben alle certificate authorities in de wereld een hele slechte dag. Dan moeten ze namelijk alle certificaten, met SHA-256, gaan vervangen omdat het hash algoritme gebroken is.
Dit is gebeurd met MD5 en met SHA-1.
Door Anoniem: Theoretisch kan je steeds een "input" vinden die bij een bepaalde hash output hoort, maar dan ben je nog niet zeker dat het de originele input was. Alle hash functies hebben namelijk collisions, omdat je een onbeperke input-space op een gelimiteerde output-space mapt
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Collision-resistance is een belangrijke eigenschap als je hash-functies gebruikt voor security doeleinden.
Op het moment dat jij een collision vindt, in bijvoorbeeld SHA-256, die dezelfde hash oplevert als de reversed hashes van karma4, dan hebben alle certificate authorities in de wereld een hele slechte dag. Dan moeten ze namelijk alle certificaten, met SHA-256, gaan vervangen omdat het hash algoritme gebroken is.
Dit is gebeurd met MD5 en met SHA-1.
Technisch niet correct.
Je moet niet alleen een input vinden die een collision oplevert, je moet een input vinden die een collision oplevert en ook gelijktijdig nog eens een geldig certificaat is.
(Alle hashes hebben collisions, zelfs een oneindig aantal. Dat is nu net een eigenschap van een hash-functie.)
Belangrijk is de collision resistance, oftewel hoe moeilijk het is om daadwerkelijk zo'n collision te vinden.
MD5 is niet "gebroken", maar de collision resistance is minder sterk dan gedacht. Daardoor is het niet meer OK om het voor dingen te gebruiken waarbij collision resistance belangrijk is, vb voor cetificaten.
Voor andere dingen, bijvoorbeeld hashes om gewijzigde bestanden te detecteren (Technische controle, geen security controle), is MD5 nog perfect geschikt.
01-05-2021, 10:00 door
karma4
Door Anoniem: ...karma4 kan ook end-to-end encryptie kraken, want de sleutels staat centraal op de servers van de end-to-end encryptie. ..
Ik kan ze niet kraken. Ik lat me niet bedonderen / oplichten door de verkooppraatjes.Als ik de sleutels niet zelf heb maar die zitten bij de dienstverlener dan is geern sprak van end-to-end encryptie.
Je ziet het aan de meerdere gevallen waarbij de politie cryptotelefoon netwerken uit de lucht gehaald hebben.
Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Sure, maar je vergeet wel dat je dan moet weten wat er gehashed is.
"f7367a2ddeabefd06b2c00d59d1f7e83c1f1b9fb81dd14c847d8be247baf32f0"
Vertel mij maar wat het orgineel was van deze SHA256 string. Is zo te doen toch?
Ik zal je in de goede richting helpen: Het is een emailadres,
Of een IP adres, of een ethernet adres, of een IBAN-nummer, of een creditcardnummer, of een User-Agent-string, of een kort wachtwoord....
Maar het kan ook een combinatie van bovenstaande zijn.
Door botbot:
Sure, maar je vergeet wel dat je dan moet weten wat er gehashed is.
"f7367a2ddeabefd06b2c00d59d1f7e83c1f1b9fb81dd14c847d8be247baf32f0"
Vertel mij maar wat het orgineel was van deze SHA256 string. Is zo te doen toch?
Ik zal je in de goede richting helpen: Het is een emailadres,
Of een IP adres, of een ethernet adres, of een IBAN-nummer, of een creditcardnummer, of een User-Agent-string, of een kort wachtwoord....
Maar het kan ook een combinatie van bovenstaande zijn.
Het probleem is dat de veiligheid niet mag afhangen van de geheimhouding van het algoritme(keuze hasfunctie, format inputdata, afknipwijze, etc.) Immers als dat uitlekt (en dat zal vroeg of laat een keer gebeuren) is meteen alle data gecompromitteerd. Dus vermijd dit soort "security by obscurity".Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Sure, maar je vergeet wel dat je dan moet weten wat er gehashed is.
"f7367a2ddeabefd06b2c00d59d1f7e83c1f1b9fb81dd14c847d8be247baf32f0"
Vertel mij maar wat het orgineel was van deze SHA256 string. Is zo te doen toch?
Ik zal je in de goede richting helpen: Het is een emailadres,
Of een IP adres, of een ethernet adres, of een IBAN-nummer, of een creditcardnummer, of een User-Agent-string, of een kort wachtwoord....
Maar het kan ook een combinatie van bovenstaande zijn.
01-05-2021, 13:44 door
Erik van Straten
Wat een "ja duh" reacties (vanzelfsprekend is het zo dat als je een aanvaller een reeks schijnbaar random bytes geeft en er niks bij vertelt, hij/zij daar niets aan heeft). Maar I'll bite.
Door Anoniem 30-04-2021, 15:18:
karma4 heeft wel een punt Erik. Je moet van te voren al weten dat de input een reeks bytes was van 0 tot oneindig tekens. En het is ook handig om te weten welke hash functie er is gebruikt (als je ze niet allemaal wilt proberen).
De laatste 2 zinnen kloppen. De praktijk is echter dat dit bij een deel van de datalekken, zo niet de meeste, het geval is. En dat zijn de situaties waar de AP voor waarschuwt.Door Erik van Straten:
Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.karma4 heeft wel een punt Erik. Je moet van te voren al weten dat de input een reeks bytes was van 0 tot oneindig tekens. En het is ook handig om te weten welke hash functie er is gebruikt (als je ze niet allemaal wilt proberen).
Door Anoniem 30-04-2021, 15:18: karma4 houdt zijn hash en encryptie algoritmes natuurlijk geheim. Zo heeft de aanvaller minder kans om bij zijn data te komen.
Het is onverstandig om van zelf bedachte of weinig/niet beproefde cryptografie gebruik te maken. Bekende en goed geauditte cryptografische algoritmes zijn er niet zo ontzettend veel.Door Anoniem 30-04-2021, 1529: Nou hij heeft wel gelijk dat je moet weten wat voor soort gegevens het zijn ...
Klopt. Zie mijn antwoord hierboven.Door Anoniem 30-04-2021, 1529: ... en hoe ze geformatteerd zijn.
Het kost meer tijd als je met verschillende encodings moet gaan experimenteren, maar vaak zal ASCII of UTF-8 worden gebruikt, en vaak is deze informatie bekend bij de "reverser".Door Anoniem 30-04-2021, 1529: En je moet ook het hashing- en knip algorithme weten.
Allemaal security by obscurity. Insiders zullen deze info meestal hebben, en een externe aanvaller is vaak in de gelegenheid om te achterhalen wat het soort input was, en welke encoding, hash-algo en knipmethode werden gebruikt.Door Anoniem 30-04-2021, 16:04: Een van de eigenschappen van een hash functie is dat je niet van terug kan "rekenen".
Om precies te zijn, dat is een verplichte eigenschap van een cryptografische hashfunctie.Door Anoniem 30-04-2021, 16:04: Dus het is heel makkelijk om de Hash-waarde van "A", te berekenen, maar je kan niet vanuit hash-waarde terug "A" vinden.
Berekenen (in de zin van "omkeren" van de functie) niet, maar vinden wel, zoals je hieronder zelf beschrijft.Door Anoniem 30-04-2021, 16:04: Wat wel kan, is "A" proberen te zoeken als je andere informatie hebt over A.
Als je bijvoorbeeld weet dat "A" een 4-cijferige pincode is, dan kan je makkelijk de hash-waarde van alle 10.000 combinaties berekenen en opzoeken wat de originele pincode was. (Dergelijke data noemt men een rainbow table.)
Je hebt niet altijd een tabel nodig, brute force kan soms ook binnen redelijke tijd.Als je bijvoorbeeld weet dat "A" een 4-cijferige pincode is, dan kan je makkelijk de hash-waarde van alle 10.000 combinaties berekenen en opzoeken wat de originele pincode was. (Dergelijke data noemt men een rainbow table.)
Door Anoniem 30-04-2021, 16:04: Theoretisch kan je steeds een "input" vinden die bij een bepaalde hash output hoort, maar dan ben je nog niet zeker dat het de originele input was. Alle hash functies hebben namelijk collisions, omdat je een onbeperke input-space op een gelimiteerde output-space mapt
Als een aanvaller een database met gehashte ASCII e-mail adressen in handen krijgt, dan vis je de meeste ongeldige adressen er zo uit (verder zoeken dus). Die paar ongeldige die overblijven, zullen spammers een biet zijn. Ook bij wachtwoordhashes zullen criminelen het geen probleem vinden als ze iets minder dan 100% hebben kunnen reversen - en in dit geval is een eventuele collision niet eens een probleem: daar kun je gewoon mee inloggen namens de gebruiker.Het artikel is niet helemaal duidelijk... bij k-anonimity met hashes knip je de hash, niet de input (bijvoorbeeld telefoonnummer of MAC)
Je gebruikt bijvoorbeeld de eerste - of laatste - 5 tekens van de hash. IMHO is dat echt niet terug te berekenen.
SHA1("P@ssw0rd") = 21BD12DC183F740EE76F27B78EB39C8AD972A757
Je gebruikt bijvoorbeeld de eerste - of laatste - 5 tekens van de hash. IMHO is dat echt niet terug te berekenen.
SHA1("P@ssw0rd") = 21BD12DC183F740EE76F27B78EB39C8AD972A757
01-05-2021, 15:55 door
Erik van Straten
Door Anoniem "Q" 30-04-2021, 16:08:
Laat ik beginnen met niet-afgeknipte hashes (want daar had ik het over - niet dat dit veel uitmaakt, zie verderop).Door Erik van Straten:
Erik, kan je uitleggen waarom dat fout is?Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Uit https://www.usenix.org/system/files/sec21fall-heinrich.pdf:
The flaws originate from the exchange of hash values of such contact identifiers during the discovery process, which can be easily reversed using brute-force or dictionary attacks
De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: https://www.security.nl/posting/516418/Zorgverzekeraar+laat+klanten+via+bank+op+account+inloggen#posting516508.
Ik heb (nog) niet kunnen vinden wat de overheid precies van plan is in het wetsvoorstel "Wet Digitale Overheid". Uit https://www.tweedekamer.nl/downloads/document?id=79033b47-c73c-4d9c-94d7-e872870da7a6&title=Beleidsontwikkelingen%20rondom%20het%20Burgerservicenummer%20%28BSN%29.pdf (bron: https://www.security.nl/posting/682986/Kabinet+werkt+aan+breder+gebruik+van+BSN+buiten+de+overheid):
Een andere oplossing die wordt onderzocht voor gevallen waarin het BSN niet mag worden gebruikt is die van de zogenaamde decentralized identifier (DID). Daarmee kan een burger een uniek, van zijn of haar BSN afgeleid, nummer afgeven aan een organisatie, die dat nummer kan verifiëren zonder dat daarvoor het BSN zelf hoeft te worden gedeeld.
Als een organisatie X, zonder derde partij, van een burger diens BSN krijgt maar niet op mag slaan, zou je kunnen denken dat een hash van dat BSN opslaan wel mag: nee dus. Zelfs als je hasht met een salt (niet geheimer dan de hash) moet je ervan uitgaan dat aanvallers (incl. insiders) voldoende gegevens hebben om te kunnen reversen. Bij hashen met pepper (https://en.wikipedia.org/wiki/Pepper_(cryptography)) is dat het geval als de aanvallers die pepper-waarde te weten komen. Dit geldt, voor zover ik overzie, ook voor versleuteling: als een aanvaller de output, het gebruikte algoritme en alle gebruikte secrets kent, weet dat het om geldige BSN's gaat en de encoding kent, kan zij/hij zo'n BSN achterhalen middels brute force.
In een oudere "Memorie van Toelichting" van het "Wetsvoorstel GDI" (de Wet Generieke Digitale Infrastructuur is later veranderd in Wet Digitale Overheid) https://www.internetconsultatie.nl/wetgdi/document/2670 (PDF, bron: https://www.internetconsultatie.nl/wetgdi/details) vond ik aanwijzingen dat er sprake zou zijn van een "koppelregister" genaamd BSN-K, kennelijk de derde partij (de overheid en/of private authenticatiediensverlener) in wat ik hierboven schreef. Als zo'n derde partij er secrets op nahoudt die de doelorganisatie niet kent, kan deze in principe wel met veilige afgeleiden van BSN's werken (mits die derde partij niet gehacked wordt).
Door Anoniem "Q" 30-04-2021, 16:08: Als ik een 32-bit hash (ik weet het, erg kort) heb van een email adres, zeg erik@gmail.com, en ik knip daar 16 bit van af ...
Dan hou je 65536 mogelijke combinaties over en heb je al snel een soort k-anonimity. Belangrijker, uit de AP-pagina waar de redactie naar verwijst (https://autoriteitpersoonsgegevens.nl/nl/nieuws/techblogpost-praktische-problemen-bij-het-afknippen-van-hashes):De juiste vraag is daarom niet hoeveel je moet afknippen, maar hoeveel je kunt bewaren.
Want wat is dan het gevolg van te weinig symbolen van gehashte attributen afknippen? Dat is een dataset die nog steeds persoonsgegevens bevat.
Want te weinig afknippen van hashwaardes laat unieke identificatoren achter. En dan is er dus géén sprake van geanonimiseerde gegevens.
Het gaat dus niet om hoeveel je eraf knipt, maar hoeveel je bewaart: in jouw geval ook 16 bits. Dat is erg weinig. Waar de AP op doelt zijn mensen die bijv. de helft van een 128-bit hash eraf knippen: het probleen is dan dat de resterende 64bits ook in nagenoeg alle gevallen uniek "addresseren".Want wat is dan het gevolg van te weinig symbolen van gehashte attributen afknippen? Dat is een dataset die nog steeds persoonsgegevens bevat.
Want te weinig afknippen van hashwaardes laat unieke identificatoren achter. En dan is er dus géén sprake van geanonimiseerde gegevens.
Maar soit, laten we van jouw resterende 16 bits uitgaan - maar dan wel met enige voorkennis (hiermee ben ik niet meer karma4's stelling aan het ontkrachten), namelijk een aantal bekende e-mail providers (gmail.com, hotmail.com, ...) kiezen. Dan zou ik user-ID's kunnen brute-forcen (of sneller, een tabel met veelgebruikte e-mail user-id's inzetten). Met brute force dus a@example.com, b@example.com, ... aa@example.com etc. (vervang example.com door elke gewenste mail provider). Ik ga ervan uit dat de aanvaller weet welke encoding en welk hash-algoritme gebruikt worden, en welke 2 bytes van de hash bewaard worden. De aanvaller bepaalt dus bijv. MD5("a@example.com") etc. en vergelijkt de gewenste 2 bytes met de 2 bytes uit elk record van de gestolen database (zelfs als de aanvaller niet zou weten om welke 2 bytes uit de hash het gaat, kan hij deze met een statistische analyse waarschijnlijk achterhalen: welke 2 bytes leveren de meeste hits op?).
De e-mail adressen die de aanvaller zo achterhaalt zullen ongetwijfeld niet allemaal van de personen in jouw database zijn, maar dat interesseert spammers/phishers bar weinig. En: als zij zo maar één e-mail adres uit jouw database recoveren, heb je een datalek.
Door Anoniem "Q" 30-04-2021, 16:08: - of de afgeknipte hash met alle mogelijke cijfercombinaties moeten aanvullen tot 32-bit, en voor al die combinaties een "reverse hash" berekening moeten doen (bij langere hashes erg CPU-intensief)
De meeste cryptografische hashes zijn zo ontworpen dat CPU's ze snel kunnen uitvoeren. Verstandige ontwerpers van webapplicaties weten dat serverbeheerders niet van rokende CPU's houden, dus zullen zij geen Argon2 inzetten waar SHA-2 het ook doet.Resumerend: aanvallers hebben bijna altijd veel meer informatie dan brave mensen (willen) bedenken. Kijk "How I met your girlfriend" van Samy Kamkar eens uit (o.a. https://youtube.com/watch?v=fWk_rMQiDGc) om te begrijpen wat ik bedoel. En zonder aannames en/of voorkennis werkt brute force vaak ook.
Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Het hashen van persoonsgegevens zorgt niet voor anonimiteit, het kan in sommige gevallen bijdragen tot privacy, maar lang niet altijd.
Het hashen van persoonsgegevens is een vorm van pseudonimiseren.
Het doel van de ingekorte data is ervoor te zorgen dat er verschillende datasets dezelfde hash krijgen.
Op die manier zijn verschillende datasets niet meer uit elkaar te houden, hetgeen de privacy wel verhoogd.
Dit werk enkel al naargelang de data set.
Vb:
Als in je dataset 10 personen zitten met een leeftijd van 20 t.e.m. 29, dan kan de de data van deze 10 personen niet meer uit elkaar halen.
Als er in de dataset slechts 1 persoon zit in die leeftijdscategorie, dan wordt de privacy niet verhoogd (voor die persoon).
01-05-2021, 16:33 door
Erik van Straten
Door Anoniem: Met MD5 kon met collisions genereren in bv. PDF documenten, door in metadata van de pdf te manipuleren door er "willekeurige" data in te zetten zodat het gehele bestand weer dezelfde hash op leverde. Dat is wat anders dan metadata in een certificate aan te passen: er zijn niet zo veel velden die je onbeperkt kan aanpassen zonder dat het certificate ongeldig wordt. (nou ja, adres, organisatie, hele vreemde waarden in SAN) wanter zijn restricties opdat de velden nog een betekenis hebben. Je kan bv. niet een willekeurige validity start en einddatum kiezen, want er zitten format eisen aan de datum.
Dus zelfs met MD5 en SHA-1 is het eigenlijk niet mogelijk, maar men heeft het zekere voor het onzekere genomen.
Is wel gebeurd: https://www.win.tue.nl/hashclash/rogue-ca/.Dus zelfs met MD5 en SHA-1 is het eigenlijk niet mogelijk, maar men heeft het zekere voor het onzekere genomen.
Om dit soort aanvallen in de toekomst te voorkomen, hebben certificaten al een tijdje een door de uitgever gegenereerd random serienummer van minstens 64 bits lengte (tikkie kinderachtig maar 63 werd niet gedoogd: https://www.security.nl/posting/601483/Logius+laat+duizenden+PKIoverheid-certificaten+intrekken).
01-05-2021, 16:36 door
Erik van Straten
Door Anoniem:
Exact! Zouden maar meer mensen zich dat realiseren...Door botbot:
Sure, maar je vergeet wel dat je dan moet weten wat er gehashed is.
"f7367a2ddeabefd06b2c00d59d1f7e83c1f1b9fb81dd14c847d8be247baf32f0"
Vertel mij maar wat het orgineel was van deze SHA256 string. Is zo te doen toch?
Ik zal je in de goede richting helpen: Het is een emailadres,
Of een IP adres, of een ethernet adres, of een IBAN-nummer, of een creditcardnummer, of een User-Agent-string, of een kort wachtwoord....
Maar het kan ook een combinatie van bovenstaande zijn.
Het probleem is dat de veiligheid niet mag afhangen van de geheimhouding van het algoritme(keuze hasfunctie, format inputdata, afknipwijze, etc.) Immers als dat uitlekt (en dat zal vroeg of laat een keer gebeuren) is meteen alle data gecompromitteerd. Dus vermijd dit soort "security by obscurity".Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Computers zijn zo snel dat het hashen van bijv. telefoonnummers, ethernet-adressen, IP-adressen, pincodes, korte wachtwoorden, BSN's en (in de meeste gevallen) e-mailadressen geen enkel beveiligingsvoordeel oplevert. En natuurlijk ook niet het hashen van ingekorte exemplaren daarvan.
Sure, maar je vergeet wel dat je dan moet weten wat er gehashed is.
"f7367a2ddeabefd06b2c00d59d1f7e83c1f1b9fb81dd14c847d8be247baf32f0"
Vertel mij maar wat het orgineel was van deze SHA256 string. Is zo te doen toch?
Ik zal je in de goede richting helpen: Het is een emailadres,
Of een IP adres, of een ethernet adres, of een IBAN-nummer, of een creditcardnummer, of een User-Agent-string, of een kort wachtwoord....
Maar het kan ook een combinatie van bovenstaande zijn.
Door Erik van Straten:
De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: ..
Goed opletten, ik zeg en herhaal dat het geheim moeten houden van een BSN totaal onzinnig en onwettelijk is.De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: ..
Het is de AP die er een verhaal van probeert te maken dat als je het niet geheim houdt dat dat identiteitsdiefstal verwijtbaar zou zijn. Ze zouden de wet moet volgen en de deugdelijke controle van de juiste persoon moeten meenemen in de handhaving. Dat betekent dat een verwerkingsverantwoordelijke een registratie van die bewijsvoering moet hebben.
Het niet kunnen uitwisselen van een BSN waar dat nodig is veroorzaakt persoonsverwisselingen, dat zijn privacyinbreuken.
Het is de verkeerde vraag om daar waar die registratie nodig en vereist is toch een geheimhouding te willen.
De e-mail adressen die de aanvaller zo achterhaalt zullen ongetwijfeld niet allemaal van de personen in jouw database zijn, maar dat interesseert spammers/phishers bar weinig. En: als zij zo maar één e-mail adres uit jouw database recoveren, heb je een datalek.
Waarmee je enkel aantoont hoe doorgeslagen het anoniem moeten zijn onder alle condities is.Het is superdom om goede algemene encrypties te gebruiken en vervolgens de sleutels en reverse rainbow opties open en bloot te publiceren. Zo'n beetje als git reposities gaan scannen omdat er user/ password en ander sleutels mee naar buiten zijn gegaan.
01-05-2021, 22:36 door
Erik van Straten
Tegen beter weten in toch een reactie.
Maar daar heeft niemand iets aan. Er ontstaan pas privacy-risico's indien 1) malloten denken dat, na identificatie met naam (en evt. aanvullende gegevens) het kennen van een BSN een betrouwbaar authenticatiemiddel is en/of 2) een BSN, gecombineerd met vertrouwelijke informatie van het individu, in verkeerde handen valt en wordt misbruikt.
Wat veel organisaties graag willen is onderling (B2B) gegevens uitwisselen om zo informatie over individuen met gegevens uit andere bronnen te verrijken. Daarbij is het natuurlijk enorm handig als al die partijen een landelijk uniek BSN gebruiken (en niet afhankelijk zijn van verhuisde personen of typo's in namen). Criminelen smullen ook van dit idee; hoe meer je van iemand weet, hoe makelijker je iemand kunt beroven en/of diens identiteit kunt overnemen.
Als security-onderzoeker heb ik bewust geen spamfilter en de betreffende alias (waar ik nooit normale mail op heb ontvangen) zou ik zo kunnen opdoeken - dus neem ik er kennis van en haal er verder m'n schouders over op (ik wil nog wel eens naar de afzendende IP-adressen kijken). Op deze alias ontvang ik ook phishingmails. Probleem: nietsvermoedende mensen krijgen dit soort mails ook. Precies daarom is het een privacy-risico als e-mail adressen worden gelekt, vooral in combinatie met andere vertrouwelijke gegevens. Zoals geslacht en achternaam; immers een van de (dus waardeloze) adviezen om een legitieme mail van een phishing-mail te onderscheiden is de aanhef te checken.
Trouwens, waarom post jij hier onder een pseudoniem? Wat is jouw BSN? En hoe luidt jouw e-mailadres? Telefoonnummer? Geboortedatum en plaats? Woonadres? Werk je en zo ja waar? Welke medische aandoeningen heb je gehad? Covid-19? Ben je dezelfde karma4 als op Tweakers? Zit je op Facebook? Weet Mark Zuckerberg jouw BSN al? Kent Palantir jou al? Experian? Heb je een BKR-registratie? Wat is jouw inkomen? Ben je hetero? Huidskleur? Strafblad? Geloofsovertuiging? Waar stem je op? Bankrekeningnummers? Eigen woning of huur? Waarom niet alles aan elkaar knopen?
De groeiende databerg gaat nog tot zeer veel tranen leiden voor we wijzer worden.
Door karma4:
Daar ging dat niet over en dat is niet het probleem. Als ik dat wil kan ik een programma schrijven dat in no time alle mogelijke BSN's uitrekent (bijna 91 miljoen, ze moeten voldoen aan de 11-proef: https://nl.wikipedia.org/wiki/Burgerservicenummer#11-proef).Door Erik van Straten: De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: ..
Goed opletten, ik zeg en herhaal dat het geheim moeten houden van een BSN totaal onzinnig en onwettelijk is.Maar daar heeft niemand iets aan. Er ontstaan pas privacy-risico's indien 1) malloten denken dat, na identificatie met naam (en evt. aanvullende gegevens) het kennen van een BSN een betrouwbaar authenticatiemiddel is en/of 2) een BSN, gecombineerd met vertrouwelijke informatie van het individu, in verkeerde handen valt en wordt misbruikt.
Door karma4: Het is de AP die er een verhaal van probeert te maken dat als je het niet geheim houdt dat dat identiteitsdiefstal verwijtbaar zou zijn. Ze zouden de wet moet volgen en de deugdelijke controle van de juiste persoon moeten meenemen in de handhaving. Dat betekent dat een verwerkingsverantwoordelijke een registratie van die bewijsvoering moet hebben.
1) Het is niet de AP maar onze wetgever die, volkomen hersenloos, heeft bepaald dat overheden, zorgmedewerkers, ... (elke partij die BSN's mag verwerken) iemand betrouwbaar zouden kunnen authenticeren door naar diens BSN te vragen (en al dan niet te checken of het verstrekte nummer van een bestaand persoon is).Door karma4: Het niet kunnen uitwisselen van een BSN waar dat nodig is veroorzaakt persoonsverwisselingen, dat zijn privacyinbreuken.
2) Ik heb nog nooit gehoord of gelezen dat dit een groot probleem zou zijn bij relaties tussen organisaties en individuen. Dat organisaties klantnummers o.i.d. aan individuen toekennen is geen probleem.Wat veel organisaties graag willen is onderling (B2B) gegevens uitwisselen om zo informatie over individuen met gegevens uit andere bronnen te verrijken. Daarbij is het natuurlijk enorm handig als al die partijen een landelijk uniek BSN gebruiken (en niet afhankelijk zijn van verhuisde personen of typo's in namen). Criminelen smullen ook van dit idee; hoe meer je van iemand weet, hoe makelijker je iemand kunt beroven en/of diens identiteit kunt overnemen.
Door karma4:
Enkele van mijn e-mail aliases zijn gelekt. Daar krijg ik nu spam op (vandaag 5 stuks "hackers hebben toegang tot je apparaat" blabla gefilmd toen ik masturberend een pornosite bezocht, 1250 Euro aan BTC betalen blablabla).De e-mail adressen die de aanvaller zo achterhaalt zullen ongetwijfeld niet allemaal van de personen in jouw database zijn, maar dat interesseert spammers/phishers bar weinig. En: als zij zo maar één e-mail adres uit jouw database recoveren, heb je een datalek.
Waarmee je enkel aantoont hoe doorgeslagen het anoniem moeten zijn onder alle condities is.Als security-onderzoeker heb ik bewust geen spamfilter en de betreffende alias (waar ik nooit normale mail op heb ontvangen) zou ik zo kunnen opdoeken - dus neem ik er kennis van en haal er verder m'n schouders over op (ik wil nog wel eens naar de afzendende IP-adressen kijken). Op deze alias ontvang ik ook phishingmails. Probleem: nietsvermoedende mensen krijgen dit soort mails ook. Precies daarom is het een privacy-risico als e-mail adressen worden gelekt, vooral in combinatie met andere vertrouwelijke gegevens. Zoals geslacht en achternaam; immers een van de (dus waardeloze) adviezen om een legitieme mail van een phishing-mail te onderscheiden is de aanhef te checken.
Trouwens, waarom post jij hier onder een pseudoniem? Wat is jouw BSN? En hoe luidt jouw e-mailadres? Telefoonnummer? Geboortedatum en plaats? Woonadres? Werk je en zo ja waar? Welke medische aandoeningen heb je gehad? Covid-19? Ben je dezelfde karma4 als op Tweakers? Zit je op Facebook? Weet Mark Zuckerberg jouw BSN al? Kent Palantir jou al? Experian? Heb je een BKR-registratie? Wat is jouw inkomen? Ben je hetero? Huidskleur? Strafblad? Geloofsovertuiging? Waar stem je op? Bankrekeningnummers? Eigen woning of huur? Waarom niet alles aan elkaar knopen?
Door karma4: Het is superdom om goede algemene encrypties te gebruiken en vervolgens de sleutels en reverse rainbow opties open en bloot te publiceren.
Bewust publiceren doen niet-criminele organisaties normaal gesproken niet, maar persoonsgegevens slecht beveiligen, waardoor criminelen deze in handen krijgen, is aan de orde van de dag. Data die je niet hebt kan ook niet gelekt worden.De groeiende databerg gaat nog tot zeer veel tranen leiden voor we wijzer worden.
02-05-2021, 00:33 door
Erik van Straten
Door Anoniem: Je gebruikt bijvoorbeeld de eerste - of laatste - 5 tekens van de hash. IMHO is dat echt niet terug te berekenen.
SHA1("P@ssw0rd") = 21BD12DC183F740EE76F27B78EB39C8AD972A757
Niet terug te berekenen, maar je maakt het aanvallers wel enorm veel makkelijker. Die 2,5 bytes (21BD1) betekenen een range van 2^20 = 1.048.576 en dat is best veel.SHA1("P@ssw0rd") = 21BD12DC183F740EE76F27B78EB39C8AD972A757
In juli 2019 heb ik "pwned-passwords-sha1-ordered-by-hash-v5.7z" gedownload vanuit https://haveibeenpwned.com/Passwords. Die file is 9.84GB groot, uitgepakt ca. 24GB. De ASCII regels daarin zien er uit als volgt:
21BD12DC183F740EE76F27B78EB39C8AD972A757:52579
Check 1:
> wc pwned-passwords-sha1-ordered-by-hash-v5.txt
555278657 555278657 24470276290 pwned-passwords-sha1-ordered-by-hash-v5.txt
555278657 555278657 24470276290 pwned-passwords-sha1-ordered-by-hash-v5.txt
Check 2:
> grep "^21BD1" pwned-passwords-sha1-ordered-by-hash-v5.txt > Starts_with_21BD1.txt
Nb. bij een volstrekt random verdeling zou je 555.278.657 / 2^20 regels verwachten = ruim 529 regels.
De hash van het wachtwoord dat daarna het meeste voorkomt:
21BD192580CAD5C57296F8488DF190D23046B05F:3474
Met andere woorden: een aanvaller die weet dat de eerste 2,5 bytes van een SHA1 wachtwoordhash "21BD1" luiden, kan, op basis van deze dataset (en wetende wat de wachtwoorden waren), met slechts 527 (gemiddeld ruim 529) pogingen proberen in te loggen - met succes als het slachtoffer een wachtwoord gebruikt dat in de dataset van haveibeenpwned voorkomt (dikke kans). Die aanvaller begint natuurlijk met het wachtwoord dat in de meeste lekken is aangetroffen, en met een beetje botnet omzeilt hij/zij ook eenvoudig fail2ban-achtige beschermingsmaatregelen.
En als er meer dan 1 item gelekt wordt, kan de aanvaller dit voor meerdere accounts proberen.
Kortom, knippen tot er 2,5 bytes (20 bits) overblijven geeft aanvallers een voordeel van ruim 1 miljoen keer (t.o.v. knippen tot er 1 bit overblijft).
Door Erik van Straten: Tegen beter weten in toch een reactie.
Van mijn kant hetzelfde. Daar ging dat niet over en dat is niet het probleem. Als ik dat wil kan ik een programma schrijven dat in no time alle mogelijke BSN's uitrekent (bijna 91 miljoen, ze moeten voldoen aan de 11-proef:
Ik beschrijf duidelijk het probleem:- Het algemeen bekend zijn van naw dan wel BSN mag geen impact bij verwerking hebben
- De verwerker dient, wettelijke verplichting, te controleren op de juiste persoon. Dat is het noemen van een naam/ BSN niet
- een kopietje paspoort is geen bewijs van de juiste persoon. Als dat zo zou zijn voldoet een kopietje geld ook als echt geld.
Hier wreek zich de foute juridische privacy insteek dat anonimiteit die privacy met administraties zou beschermen.
Die missen het onderscheid in het verschil met identificeren en authenticeren wat nu juist wezenlijk bij security is.
https://nl.wikipedia.org/wiki/Authenticatie je kunt ook het woord in woordenboeken opzoeken
Maar daar heeft niemand iets aan. Er ontstaan pas privacy-risico's indien 1) malloten denken dat, na identificatie met naam (en evt. aanvullende gegevens) het kennen van een BSN een betrouwbaar authenticatiemiddel is en/of 2) een BSN, gecombineerd met vertrouwelijke informatie van het individu, in verkeerde handen valt en wordt misbruikt.
Dat het zo gebruikt wordt is onwettelijk. Dat de AP daarin meegaat is gewoon fout. (Zie heriboven). =punt= [i
1) Het is niet de AP maar onze wetgever die, volkomen hersenloos, heeft bepaald dat overheden, zorgmedewerkers, ... (elke partij die BSN's mag verwerken) iemand betrouwbaar zouden kunnen authenticeren door naar diens BSN te vragen (en al dan niet te checken of het verstrekte nummer van een bestaand persoon is)
In de wet gebruik BSN staat de eis dat voordat de verwerker er mee aan de slag gaat er een een gedegen controle moet zijn of het de juiste persoon is. Van start gaan omdat met een opgegeven BSN iets in de administratie werkt is onwettelijk. 1) Het is niet de AP maar onze wetgever die, volkomen hersenloos, heeft bepaald dat overheden, zorgmedewerkers, ... (elke partij die BSN's mag verwerken) iemand betrouwbaar zouden kunnen authenticeren door naar diens BSN te vragen (en al dan niet te checken of het verstrekte nummer van een bestaand persoon is)
2) Ik heb nog nooit gehoord of gelezen dat dit een groot probleem zou zijn bij relaties tussen organisaties en individuen. Dat organisaties klantnummers o.i.d. aan individuen toekennen is geen probleem.
Dat is gebrek aan de historische kennis. Het Sofi nummer nu BSN was ooit het klantnummer van de belastingdienst. De overheid heeft die bij de verdere doorvoering van de automatisering gekozen omdat het het meest betrouwbare was. De problemen met NAW afleiding om gegevens te koppelen waren te groot, dat moest beter. (stamt uit jaren 80)https://zoek.officielebekendmakingen.nl/kst-30312-3.html
"Het burgerservicenummer is niet «gekoppeld» aan een bepaalde gegevensset. Het burgerservicenummer is een technisch hulpmiddel, om de uitwisseling van gegevens over een persoon correct en doelmatig te laten verlopen. Welke gegevens met behulp van het burgerservicenummer overgebracht mogen of moeten worden, hangt af van de context waarin die gegevensoverdracht plaatsvindt."
... Criminelen smullen ook van dit idee; hoe meer je van iemand weet, hoe makelijker je iemand kunt beroven en/of diens identiteit kunt overnemen. ...
Criminelen willen gewoon niet bekend laten worden hoe ze aan hun vermogen komen. Ze verheerlijken dat recht op privacy op die wijze. Hun slachtoffers hebben in het geheel geen rechten, hadden ze maar beter voor zichzelf moeten zorgen. ..Enkele van mijn e-mail aliases zijn gelekt. Daar krijg ik nu spam op (vandaag 5 stuks "hackers hebben toegang tot je apparaat" blabla gefilmd toen ik masturberend een pornosite bezocht, 1250 Euro aan BTC betalen blablabla) ...
Gebruik dan ook wegwerp mail accounts en meer. Je weet dat op drukke dagen zakkenrollers actief zijn, loop dan niet met de waardevolle spullen - portemonnee in een boodschappentas rond. Je kunt hun aanwezigheid niet voorkomen maar de impact en kans veranderen.
Dat houdt in leren omgaan met spammail. Heel eigenwijs niet zomaar op links in mails reageren.
Leer je persoonlijke omgeving met de zelfde aanpak om te gaan. Dat is: wees vertrouwd maar vertrouw niemand.
Schat risico's in en als het keer mis gaat, dat zij zo. Zonder risico's zou het knap saai zijn.
Trouwens, waarom post jij hier onder een pseudoniem? Wat is jouw BSN? En hoe luidt jouw e-mailadres? Telefoonnummer? Geboortedatum en plaats? Woonadres? Werk je en zo ja waar? Welke medische aandoeningen heb je gehad? Covid-19? Ben je dezelfde karma4 als op Tweakers? ...[
Ik lig in een deuk met die uiting als je snapt wat ik bedoel. Als je denkt dat anonimiteit het enige is, denk nog eens. .. De groeiende databerg gaat nog tot zeer veel tranen leiden voor we wijzer worden.
Het is mijn werkveld, ik zie meer en krijg meer te weten dan je voor mogelijk houdt. De eenvoudige oplossing om de speld in een hooiberg lastiger te maken is om er zeer veel hooibergen van te maken. Voor oude radiotechnologie voeg steeds meer ruis toe dat maakt het signaal uiteindelijk nutteloos.Ik maak mee dat personen die security specialist noemen soms de grootste bedreiging vormen voor een gedegen security.
Er is een te groot gat in wat zou kunnen en wat zou snel mogelijk moet. Hoeveel voorbeelden wil je hebben?
Ik begin:
- ooit was het voorkomen van internetgebruik en html het hoogste want volgens ... waren dat de oorzaken dat het allemaal onveilig was.
Door karma4: In de wet gebruik BSN staat de eis dat voordat de verwerker er mee aan de slag gaat er een een gedegen controle moet zijn of het de juiste persoon is. Van start gaan omdat met een opgegeven BSN iets in de administratie werkt is onwettelijk.
Die wet heeft het niet over een verwerker maar over een gebruiker, en bij de definities aan het begin wordt een gebruiker gedefinieerd als een overheidsorgaan of een ander die wettelijk verplicht is het BSN te gebruiken. De verplichting betreft dus niet iedereen die een BSN verwerkt, hij betreft alleen degenen die wettelijk verplicht zijn een BSN te verwerken.Bij identiteitsfraude waar BSNs bij worden gebruikt ben ik beschrijvingen tegengekomen van criminelen die een woning hebben gehuurd op naam van een ander. De verhuurder stapt met onbetaalde rekeningen op een gegeven moment naar een incassobureau en die gaat het BSN gebruiken als "bewijs" dat het slachtoffer van de identiteitsfraude de huurder was. Bij woninghuur moet het BSN worden geregistreerd, de verhuurder heeft duidelijk de controle niet goed gedaan, en degene wiens BSN is misbruikt krijgt een shitload ellende over zich heen.
Een verhuurder heeft, als ik het goed heb, geen recht om een kopie van een identiteitsbewijs te maken. Dat moet dus op het oog worden gecontroleerd. Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren. Dus als het op een conflict aankomt is zo'n controle niet meer of minder dan het woord van de een tegenover het woord van de ander.
Dat los je niet op door te roepen dat de BSN-gebruiker zich aan de wet moet houden. Je hebt helemaal geen manier om achteraf vast te stellen of dat wel of niet is gebeurd. Dat is de realiteit waar we nu mee te maken hebben.
Dat het zo gebruikt wordt is onwettelijk. Dat de AP daarin meegaat is gewoon fout. (Zie heriboven). =punt=
AP kan moeilijk anders dan erkennen dat de werkelijkheid zoals hij nu is domweg niet waterdicht is. Als iemand claimt slachtoffer te zijn van identeitsdiefstal zijn er (in ieder geval) twee mogelijkheden:• de persoon liegt dat het identiteitsfraude was en is zelf aan het frauderen;
• de persoon is inderdaad slachtoffer, wat impliceert dat het identiteitsbewijs niet of niet goed is gecontroleerd.
Omdat een visuele controle van een identiteitsbewijs geen sporen achterlaat kan je helaas het onderscheid tussen die twee mogelijkheden achteraf niet vaststellen, je weet domweg niet of die controle wel of niet goed is uitgevoerd. Dan schiet je geen donder op met de constatering dat dat wel verplicht is. Daarmee dwing je namelijk op geen enkele manier af dat mensen zich feilloos aan die verplichting houden. En mensen bestraffen voor fouten die maar heel zelden hard genoeg zal kunnen maken om een straf op te kunnen leggen zal ook niet veel zoden aan de dijk zetten. In de meeste gevallen zal het een open vraag zijn wat er nou precies gebeurd is en hoe verwijtbaar dat is.
Wat de AP doet is erkennen dat het systeem niet waterdicht is, dat het dus mogelijk is dat mensen op deze manier slachtoffer worden van identiteitsfraude. Zo lang als dat mogelijk is is het verstandig voor iedereen om zelf voorzorgen te nemen om het risico erop zo klein mogelijk te maken. Daar geeft AP inderdaad adviezen voor. In mijn ogen betekent dat niet dat AP de situatie goedpraat of er medeverantwoordelijk voor is, het betekent alleen maar dat ze hun ogen niet sluiten voor de realiteit van dit moment.
Je vindt dat AP dat niet moet doen. Prima, maar kan jij dan uitleggen hoe je achteraf met zekerheid kan vaststellen of de controle van een identiteitsbewijs en het BSN erop wel of niet goed is gedaan? En dan bedoel ik hoe dat nu kan, en niet pas als er allerlei fancy technologie daartoe algemeen gebruikt wordt.
Ik zal niet de hele post van karma4 quoten (11:15), maar zal het samenvatten met:
1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
02-05-2021, 17:43 door
karma4
Door Anoniem: Ik zal niet de hele post van karma4 quoten (11:15), maar zal het samenvatten met:
1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
Je hebt nog steeds niet. Wat is de kern van de zaak. 1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
- We moeten niet panisch doen over het geheim moeten houden van een BSN
Hij is bedoeld om persoonsverwisselingen te voorkomen.
- Het is geheel fout en onwettelijk om enkel dat ding als bewijs van de juiste persoon te willen zien.
Dat de AP met die foute en onwettelijke insteek meegaat is niet goed.
Voor het big data gebeuren, die heb je ook niet door.
Als je verzamelaars van gegevens overstelpt met nutteloze informatie dan gaat hun verwerking vanzelf fout.
Door Anoniem:
Die wet heeft het niet over een verwerker maar over een gebruiker. hij betreft alleen degenen die wettelijk verplicht zijn een BSN te verwerken.
https://wetten.overheid.nl/BWBR0022428/2018-07-28#Hoofdstuk4_Paragraaf1Die wet heeft het niet over een verwerker maar over een gebruiker. hij betreft alleen degenen die wettelijk verplicht zijn een BSN te verwerken.
"Indien bij het verwerken van persoonsgegevens een burgerservicenummer wordt gebruikt, vergewist de gebruiker zich ervan dat het burgerservicenummer betrekking heeft op de persoon wiens persoonsgegevens hij verwerkt."
De gebruiker die de verwerking doet, ofwel de verwerker in de AVG. Artikle lid d is niet beperkt.e
Een ieder die verplicht is het BSN te verwerken is inmiddels een zeer lange lijst.banken verzekeringen studie zorg en meer.
Bij identiteitsfraude waar BSNs bij worden gebruikt ben ik beschrijvingen tegengekomen van criminelen die een woning hebben gehuurd op naam van een ander. De verhuurder stapt met onbetaalde rekeningen op een gegeven moment naar een incassobureau en die gaat het BSN gebruiken als "bewijs" dat het slachtoffer van de identiteitsfraude de huurder was. Bij woninghuur moet het BSN worden geregistreerd, de verhuurder heeft duidelijk de controle niet goed gedaan, en degene wiens BSN is misbruikt krijgt een shitload ellende over zich heen.
Hier kaart je de kern van de zaak aan. De verhuurder heeft de controle niet goed gedaan. Vanuit zijn machtspositie verlegd hij het onwettelijk naar de huurder. Hoog tijd dat de rechter daar niet in mee gaat.Bol.com laat zich oplichten en probeerde met een machtpositie het probleem bij brabantia neer te leggen. Gelukkig ging de rechter daarin niet in mee. Als de AP om privacy zou geven zouden die er ook niet in meegaan, hun keus is de slachtoffers van onwettelijk handelen (de burger) schuldig te verklaren want ze hebben gegevens niet geheim gehouden.
Een verhuurder heeft, als ik het goed heb, geen recht om een kopie van een identiteitsbewijs te maken. Dat moet dus op het oog worden gecontroleerd. Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren. ..
Oplossing bewaar een scan met alle gegevens als foto met een andere kenmerkend iets. Hier faallt de AP en het RIVM met een totaal gebrek aan invulling van die wettelijke verplichting.
AP kan moeilijk anders dan erkennen dat de werkelijkheid zoals hij nu is domweg niet waterdicht is. Als iemand claimt slachtoffer te zijn van identeitsdiefstal zijn er (in ieder geval) twee mogelijkheden:
• de persoon liegt dat het identiteitsfraude was en is zelf aan het frauderen;
• de persoon is inderdaad slachtoffer, wat impliceert dat het identiteitsbewijs niet of niet goed is gecontroleerd
...
Hier kan je ophouden, zorg dat het dan wel mogelijk wordt en dat het bewijs deugdelijk bewaard kan worden.• de persoon liegt dat het identiteitsfraude was en is zelf aan het frauderen;
• de persoon is inderdaad slachtoffer, wat impliceert dat het identiteitsbewijs niet of niet goed is gecontroleerd
...
De AP steekt er omgekeerd in, ze maken elek bewijsvoering onmogelijk. Daarmee helpen ze oplichters en criminelen.
at de AP doet is erkennen dat het systeem niet waterdicht is, dat het dus mogelijk is dat mensen op deze manier slachtoffer worden van identiteitsfraude. Zo lang als dat mogelijk is is het verstandig voor iedereen om zelf voorzorgen te nemen om het risico erop zo klein mogelijk te maken. ..
Dan moeten ze niet de controles en bewijzen onmogelijk maken en die als niet terechte verwerkingen aanmerken.Laat ze maar eens met oplossingen komen. Een scan en tegelijkertijd een foto met datum tijd zou mogelijkheden bieden. Dan moet je niet eerst gaan emmeren dat alle scans bij voorbaat verboden zijn.
Door karma4:
- We moeten niet panisch doen over het geheim moeten houden van een BSN
Hij is bedoeld om persoonsverwisselingen te voorkomen.
- Het is geheel fout en onwettelijk om enkel dat ding als bewijs van de juiste persoon te willen zien.
Dat de AP met die foute en onwettelijke insteek meegaat is niet goed.
Door Anoniem: Ik zal niet de hele post van karma4 quoten (11:15), maar zal het samenvatten met:
1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
Je hebt nog steeds niet. Wat is de kern van de zaak. 1) Het is oké als karma4 de BSN van iedereen in het forum heeft, want dat is zijn 'werkveld'
2) Het is niet oké als iemand in het forum de BSN van karma4 heeft, want die mogen dat niet verwerken van de wet
De Britten noemen dat: "Do as we say, don't do as we do"
- We moeten niet panisch doen over het geheim moeten houden van een BSN
Hij is bedoeld om persoonsverwisselingen te voorkomen.
- Het is geheel fout en onwettelijk om enkel dat ding als bewijs van de juiste persoon te willen zien.
Dat de AP met die foute en onwettelijke insteek meegaat is niet goed.
Je hebt misschien in theorie gelijk , maar je verliest als je vecht met een windmolen .
Het is _heel veel_ praktijk geworden dat voor 'lichte authenticatie' BSN, NAW, geboortedatum min of meer de standaard zijn waarmee je van alles kunt gaan regelen of navragen , meestal telefonisch .
En dat zijn dus ook dingen waar je , indien iemand anders op die manier voor jou doorgaat - dus ook veel last van hebt .
Het is een erg schrale troost als je tijd moet verdoen met incassoburo's en deurwaarders om je gelijk te krijgen dat de opgelichte partij _geen_ levering of overeenkomst met je heeft. Je tijd, zorgen en frustatie krijg je van niemand vergoed.
Of dus om je telefoonnummer terug te krijgen . En gelekte informatie krijg je al helemaal niet meer 'terug geheim' .
Dus helaas - het is in de praktijk _wel_ zaak om allerhande gegevens wel geheim te houden .
Ook al is de theorie dat het "slechts* bedoeld is als unieke key in een database .
Het zou een goede zaak zijn als je BSNs regelmatig(er) kon wisselen .
Door karma4:
Alleen worden scans van identiteitsbewijzen zelf weer gebruikt om identiteitsfraude mee te plegen. Vandaar alle adviezen om er delen van af te schermen die voor het doel niet noodzakelijk zijn, zoals het BSN, en om een tekst met datum en doel van die specifieke kopie eroverheen te zetten. Wat je natuurlijk allemaal niet in de hand hebt als de partij die je identiteit controleert de scan maakt. En al die maatregelen die mensen kunnen nemen zijn ook nog eens precies waar jij tegen tekeer gaat. Een verhuurder heeft, als ik het goed heb, geen recht om een kopie van een identiteitsbewijs te maken. Dat moet dus op het oog worden gecontroleerd. Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren. ..
Oplossing bewaar een scan met alle gegevens als foto met een andere kenmerkend iets.Dus geef eens aan hoe je jouw oplossing invult zonder die risico's?
Hier kan je ophouden, zorg dat het dan wel mogelijk wordt en dat het bewijs deugdelijk bewaard kan worden.
Ik stelde je, in vette letters, de vraag: hoe dan? En dan niet hoe het in de toekomst mogelijk wordt, maar hoe we er nu zo mee om kunnen gaan dat de risico's er niet zijn en de maatregelen om jezelf ertegen te beschermen niet nodig zijn. Hoe kan dat nu, op dit moment? De AP steekt er omgekeerd in, ze maken elek bewijsvoering onmogelijk.
Ze kijken gewoon verder dan jouw neus lang is.Dan moeten ze niet de controles en bewijzen onmogelijk maken en die als niet terechte verwerkingen aanmerken.
Laat ze maar eens met oplossingen komen. Een scan en tegelijkertijd een foto met datum tijd zou mogelijkheden bieden. Dan moet je niet eerst gaan emmeren dat alle scans bij voorbaat verboden zijn.
Het probleem met jou is dat je steeds aanneemt dat iedereen zoiets goed zou toepassen. Het klopt dat mensen het goed horen toe te passen, maar de realiteit is dat mensen verre van feilloos zijn en heel wat steekjes laten vallen.Laat ze maar eens met oplossingen komen. Een scan en tegelijkertijd een foto met datum tijd zou mogelijkheden bieden. Dan moet je niet eerst gaan emmeren dat alle scans bij voorbaat verboden zijn.
Als mensen volgens de regels het BSN goed controleren en niemand ooit momenten heeft dat hij zijn aandacht even niet erbij heeft, niemand ooit bewust sjoemelt, niemand ooit te dom is om te begrijpen wat er mis kan gaan, dan had je die hele scan niet nodig (en hoefde je zelfs het BSN niet te controleren omdat in een wereld waar niemand ooit liegt of vergissingen maakt het altijd klopt). Je voert die controle uit omdat mensen wél fouten maken. Pas dát besef nou eens toe op die controle. Hoe stel jij veilig dat iemand achter de toonbank bij de autoverhuur, of een particuliere verhuurder van een woning, dit allemaal goed toepast en vervolgens de vastgelegde scans weer goed tegen misbruik beschermt?
Door Anoniem: [...]
Een verhuurder heeft, als ik het goed heb, geen recht om een kopie van een identiteitsbewijs te maken. Dat moet dus op het oog worden gecontroleerd. Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren. Dus als het op een conflict aankomt is zo'n controle niet meer of minder dan het woord van de een tegenover het woord van de ander.
[...]
Een verhuurder heeft, als ik het goed heb, geen recht om een kopie van een identiteitsbewijs te maken. Dat moet dus op het oog worden gecontroleerd. Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren. Dus als het op een conflict aankomt is zo'n controle niet meer of minder dan het woord van de een tegenover het woord van de ander.
[...]
De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
En voor diegenen die geen app willen installeren: zelf een kopie maken en de betreffende delen zwart maken en er met pen de tekst van het watermark overheen schrijven. Dat nogmaals kopieren en de kopie inleveren (want dan is het doorgestreepte deel ook niet meer terug te halen).
Dus waar een wil is is een weg!
Door Anoniem: De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
En voor diegenen die geen app willen installeren: zelf een kopie maken en de betreffende delen zwart maken en er met pen de tekst van het watermark overheen schrijven. Dat nogmaals kopieren en de kopie inleveren (want dan is het doorgestreepte deel ook niet meer terug te halen).
Dus waar een wil is is een weg!
Natuurlijk. Het was een antwoord op karma4, die op deze website regelmatig, en ook nu weer, AP ervan beschuldigt het probleem te veroorzaken door dat soort maatregelen aan te bevelen. Een antwoord op de vraag hoe je het probleem dan oplost zonder dat mensen zichzelf tegen identiteitsdiefstal beschermen met dit soort maatregelen geeft hij niet, behalve met opmerkingen als "zorg dan dat het wel mogelijk wordt" waar niemand op dit moment wijzer van wordt.En voor diegenen die geen app willen installeren: zelf een kopie maken en de betreffende delen zwart maken en er met pen de tekst van het watermark overheen schrijven. Dat nogmaals kopieren en de kopie inleveren (want dan is het doorgestreepte deel ook niet meer terug te halen).
Dus waar een wil is is een weg!
Door Erik van Straten:
Uit https://www.usenix.org/system/files/sec21fall-heinrich.pdf:
De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: https://www.security.nl/posting/516418/Zorgverzekeraar+laat+klanten+via+bank+op+account+inloggen#posting516508.
Ik heb (nog) niet kunnen vinden wat de overheid precies van plan is in het wetsvoorstel "Wet Digitale Overheid". Uit https://www.tweedekamer.nl/downloads/document?id=79033b47-c73c-4d9c-94d7-e872870da7a6&title=Beleidsontwikkelingen%20rondom%20het%20Burgerservicenummer%20%28BSN%29.pdf (bron: https://www.security.nl/posting/682986/Kabinet+werkt+aan+breder+gebruik+van+BSN+buiten+de+overheid):
Als een organisatie X, zonder derde partij, van een burger diens BSN krijgt maar niet op mag slaan, zou je kunnen denken dat een hash van dat BSN opslaan wel mag: nee dus. Zelfs als je hasht met een salt (niet geheimer dan de hash) moet je ervan uitgaan dat aanvallers (incl. insiders) voldoende gegevens hebben om te kunnen reversen. Bij hashen met pepper (https://en.wikipedia.org/wiki/Pepper_(cryptography)) is dat het geval als de aanvallers die pepper-waarde te weten komen. Dit geldt, voor zover ik overzie, ook voor versleuteling: als een aanvaller de output, het gebruikte algoritme en alle gebruikte secrets kent, weet dat het om geldige BSN's gaat en de encoding kent, kan zij/hij zo'n BSN achterhalen middels brute force.
In een oudere "Memorie van Toelichting" van het "Wetsvoorstel GDI" (de Wet Generieke Digitale Infrastructuur is later veranderd in Wet Digitale Overheid) https://www.internetconsultatie.nl/wetgdi/document/2670 (PDF, bron: https://www.internetconsultatie.nl/wetgdi/details) vond ik aanwijzingen dat er sprake zou zijn van een "koppelregister" genaamd BSN-K, kennelijk de derde partij (de overheid en/of private authenticatiediensverlener) in wat ik hierboven schreef. Als zo'n derde partij er secrets op nahoudt die de doelorganisatie niet kent, kan deze in principe wel met veilige afgeleiden van BSN's werken (mits die derde partij niet gehacked wordt).
Maar soit, laten we van jouw resterende 16 bits uitgaan - maar dan wel met enige voorkennis (hiermee ben ik niet meer karma4's stelling aan het ontkrachten), namelijk een aantal bekende e-mail providers (gmail.com, hotmail.com, ...) kiezen. Dan zou ik user-ID's kunnen brute-forcen (of sneller, een tabel met veelgebruikte e-mail user-id's inzetten). Met brute force dus a@example.com, b@example.com, ... aa@example.com etc. (vervang example.com door elke gewenste mail provider). Ik ga ervan uit dat de aanvaller weet welke encoding en welk hash-algoritme gebruikt worden, en welke 2 bytes van de hash bewaard worden. De aanvaller bepaalt dus bijv. MD5("a@example.com") etc. en vergelijkt de gewenste 2 bytes met de 2 bytes uit elk record van de gestolen database (zelfs als de aanvaller niet zou weten om welke 2 bytes uit de hash het gaat, kan hij deze met een statistische analyse waarschijnlijk achterhalen: welke 2 bytes leveren de meeste hits op?).
De e-mail adressen die de aanvaller zo achterhaalt zullen ongetwijfeld niet allemaal van de personen in jouw database zijn, maar dat interesseert spammers/phishers bar weinig. En: als zij zo maar één e-mail adres uit jouw database recoveren, heb je een datalek.
Resumerend: aanvallers hebben bijna altijd veel meer informatie dan brave mensen (willen) bedenken. Kijk "How I met your girlfriend" van Samy Kamkar eens uit (o.a. https://youtube.com/watch?v=fWk_rMQiDGc) om te begrijpen wat ik bedoel. En zonder aannames en/of voorkennis werkt brute force vaak ook.
Erik, dank voor de uitgebreide toelichting. Mijn statement was in de lijn: "Als je niet weet wat gehashed is kan je het niet terugherleiden". Misschien iets te snel gereageerd, want je geeft in het oorspronkelijke statement al aan dat je bewering slaat op een getal of een serie bytes (" Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn."). Ofwel je hebt al wel enige voorkennis wat er gehashed wordt, waardoor het haalbaar wordt. Het is niet een hash over de verzamelde werken van Shakespeare of een andere schrijver :-) Door Anoniem "Q" 30-04-2021, 16:08:
Laat ik beginnen met niet-afgeknipte hashes (want daar had ik het over - niet dat dit veel uitmaakt, zie verderop).Door Erik van Straten:
Erik, kan je uitleggen waarom dat fout is?Door karma4:
Fout. Val jij even door de mand...Door Erik van Straten: Hashen van getallen (of een reeks bytes), met als doel het origineel te verhullen, is zinloos als de reeks, voor computers, zo beperkt is van grootte dat je door alle mogelijke combinaties te hashen binnen afzienbare tijd kunt achterhalen wat het oorspronkelijke getal (of de reeks bytes) geweest moet zijn. ...
Dat reversed hashen achterhalen werkt alleen als je de betreffende gegevens op een andere manier al weet.Uit https://www.usenix.org/system/files/sec21fall-heinrich.pdf:
The flaws originate from the exchange of hash values of such contact identifiers during the discovery process, which can be easily reversed using brute-force or dictionary attacks
De aanval van karma4 op mijn bijdrage suggereert dat hij/zij geen rekening houdt met brute force attacks. In 2017 leek karma4 ook al te suggereren dat het hashen van een BSN zin zou hebben: https://www.security.nl/posting/516418/Zorgverzekeraar+laat+klanten+via+bank+op+account+inloggen#posting516508.
Ik heb (nog) niet kunnen vinden wat de overheid precies van plan is in het wetsvoorstel "Wet Digitale Overheid". Uit https://www.tweedekamer.nl/downloads/document?id=79033b47-c73c-4d9c-94d7-e872870da7a6&title=Beleidsontwikkelingen%20rondom%20het%20Burgerservicenummer%20%28BSN%29.pdf (bron: https://www.security.nl/posting/682986/Kabinet+werkt+aan+breder+gebruik+van+BSN+buiten+de+overheid):
Een andere oplossing die wordt onderzocht voor gevallen waarin het BSN niet mag worden gebruikt is die van de zogenaamde decentralized identifier (DID). Daarmee kan een burger een uniek, van zijn of haar BSN afgeleid, nummer afgeven aan een organisatie, die dat nummer kan verifiëren zonder dat daarvoor het BSN zelf hoeft te worden gedeeld.
Als een organisatie X, zonder derde partij, van een burger diens BSN krijgt maar niet op mag slaan, zou je kunnen denken dat een hash van dat BSN opslaan wel mag: nee dus. Zelfs als je hasht met een salt (niet geheimer dan de hash) moet je ervan uitgaan dat aanvallers (incl. insiders) voldoende gegevens hebben om te kunnen reversen. Bij hashen met pepper (https://en.wikipedia.org/wiki/Pepper_(cryptography)) is dat het geval als de aanvallers die pepper-waarde te weten komen. Dit geldt, voor zover ik overzie, ook voor versleuteling: als een aanvaller de output, het gebruikte algoritme en alle gebruikte secrets kent, weet dat het om geldige BSN's gaat en de encoding kent, kan zij/hij zo'n BSN achterhalen middels brute force.
In een oudere "Memorie van Toelichting" van het "Wetsvoorstel GDI" (de Wet Generieke Digitale Infrastructuur is later veranderd in Wet Digitale Overheid) https://www.internetconsultatie.nl/wetgdi/document/2670 (PDF, bron: https://www.internetconsultatie.nl/wetgdi/details) vond ik aanwijzingen dat er sprake zou zijn van een "koppelregister" genaamd BSN-K, kennelijk de derde partij (de overheid en/of private authenticatiediensverlener) in wat ik hierboven schreef. Als zo'n derde partij er secrets op nahoudt die de doelorganisatie niet kent, kan deze in principe wel met veilige afgeleiden van BSN's werken (mits die derde partij niet gehacked wordt).
Door Anoniem "Q" 30-04-2021, 16:08: Als ik een 32-bit hash (ik weet het, erg kort) heb van een email adres, zeg erik@gmail.com, en ik knip daar 16 bit van af ...
Dan hou je 65536 mogelijke combinaties over en heb je al snel een soort k-anonimity. Belangrijker, uit de AP-pagina waar de redactie naar verwijst (https://autoriteitpersoonsgegevens.nl/nl/nieuws/techblogpost-praktische-problemen-bij-het-afknippen-van-hashes):De juiste vraag is daarom niet hoeveel je moet afknippen, maar hoeveel je kunt bewaren.
Want wat is dan het gevolg van te weinig symbolen van gehashte attributen afknippen? Dat is een dataset die nog steeds persoonsgegevens bevat.
Want te weinig afknippen van hashwaardes laat unieke identificatoren achter. En dan is er dus géén sprake van geanonimiseerde gegevens.
Het gaat dus niet om hoeveel je eraf knipt, maar hoeveel je bewaart: in jouw geval ook 16 bits. Dat is erg weinig. Waar de AP op doelt zijn mensen die bijv. de helft van een 128-bit hash eraf knippen: het probleen is dan dat de resterende 64bits ook in nagenoeg alle gevallen uniek "addresseren".Want wat is dan het gevolg van te weinig symbolen van gehashte attributen afknippen? Dat is een dataset die nog steeds persoonsgegevens bevat.
Want te weinig afknippen van hashwaardes laat unieke identificatoren achter. En dan is er dus géén sprake van geanonimiseerde gegevens.
Maar soit, laten we van jouw resterende 16 bits uitgaan - maar dan wel met enige voorkennis (hiermee ben ik niet meer karma4's stelling aan het ontkrachten), namelijk een aantal bekende e-mail providers (gmail.com, hotmail.com, ...) kiezen. Dan zou ik user-ID's kunnen brute-forcen (of sneller, een tabel met veelgebruikte e-mail user-id's inzetten). Met brute force dus a@example.com, b@example.com, ... aa@example.com etc. (vervang example.com door elke gewenste mail provider). Ik ga ervan uit dat de aanvaller weet welke encoding en welk hash-algoritme gebruikt worden, en welke 2 bytes van de hash bewaard worden. De aanvaller bepaalt dus bijv. MD5("a@example.com") etc. en vergelijkt de gewenste 2 bytes met de 2 bytes uit elk record van de gestolen database (zelfs als de aanvaller niet zou weten om welke 2 bytes uit de hash het gaat, kan hij deze met een statistische analyse waarschijnlijk achterhalen: welke 2 bytes leveren de meeste hits op?).
De e-mail adressen die de aanvaller zo achterhaalt zullen ongetwijfeld niet allemaal van de personen in jouw database zijn, maar dat interesseert spammers/phishers bar weinig. En: als zij zo maar één e-mail adres uit jouw database recoveren, heb je een datalek.
Door Anoniem "Q" 30-04-2021, 16:08: - of de afgeknipte hash met alle mogelijke cijfercombinaties moeten aanvullen tot 32-bit, en voor al die combinaties een "reverse hash" berekening moeten doen (bij langere hashes erg CPU-intensief)
De meeste cryptografische hashes zijn zo ontworpen dat CPU's ze snel kunnen uitvoeren. Verstandige ontwerpers van webapplicaties weten dat serverbeheerders niet van rokende CPU's houden, dus zullen zij geen Argon2 inzetten waar SHA-2 het ook doet.Resumerend: aanvallers hebben bijna altijd veel meer informatie dan brave mensen (willen) bedenken. Kijk "How I met your girlfriend" van Samy Kamkar eens uit (o.a. https://youtube.com/watch?v=fWk_rMQiDGc) om te begrijpen wat ik bedoel. En zonder aannames en/of voorkennis werkt brute force vaak ook.
Mijn tweede stuk in die post heeft meer betrekking op je statement "Het gaat dus niet om hoeveel je eraf knipt, maar hoeveel je bewaart": Als je te weinig weggooit (en dus te veel bewaard) is de resterende hash nog steeds zo uniek dat het misschien niet 1-op-1 terug te brute-forcen is, maar wel gebruikt kan worden om de persoon te herleiden. Toch?
Q
03-05-2021, 16:33 door
Erik van Straten
Door Anoniem: [identiteitsbewijs]
De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het zijn maar pixels. Iedereen die een beetje handig is met Paint, the Gimp of Photoshop kan zo'n watermerk verwijderen.De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het probleem is dat het resultaat in veel te veel gevallen volstaat om online mee te authenticeren.
Door Erik van Straten:
Het probleem is dat het resultaat in veel te veel gevallen volstaat om online mee te authenticeren.
Klopt, maar dat was ook niet mijn stelling: je kan je authenticeren met je echte ID, en de verhuurder mag als "bewijs" dat hij het ID gezien heeft een "veilige" kopie (zonder foto, zonder BSN) achterhouden. Daarmee kan hij aannemelijk (!) maken dat hij het ID gezien heeft (uit de oorspronkelijke post: " Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren.").Door Anoniem: [identiteitsbewijs]
De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het zijn maar pixels. Iedereen die een beetje handig is met Paint, the Gimp of Photoshop kan zo'n watermerk verwijderen.De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het probleem is dat het resultaat in veel te veel gevallen volstaat om online mee te authenticeren.
En omdat het documentnummer gewoon op de kopie mag blijven staan kan bij een strafrechtelijk onderzoek altijd achterhaald worden of het geen fake kopie is.
En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
04-05-2021, 00:35 door
Erik van Straten
Door Anoniem: Mijn tweede stuk in die post heeft meer betrekking op je statement "Het gaat dus niet om hoeveel je eraf knipt, maar hoeveel je bewaart": Als je te weinig weggooit (en dus te veel bewaard) is de resterende hash nog steeds zo uniek dat het misschien niet 1-op-1 terug te brute-forcen is, maar wel gebruikt kan worden om de persoon te herleiden.
Beide. Zie mijn bijdrage over "21BD1" hierboven (https://www.security.nl/posting/701701). Als je die 2,5 bytes uitbreidt tot 4 bytes ben je een factor 4096 nauwkeuriger, waarmee je in de meeste gevallen elk van die 555M hashes uniek adresseert.Om precies te zijn, van de 555.278.657 hashes in een file van haveibeenpwned:
- zijn er 522.337.136 (94%) waarvan de eerste 4 bytes uniek zijn (1x voorkomen);
- zijn er 32.844.941 waarvan de eerste 4 bytes in 2 hashes voorkomen;
- zijn er 96.580 waarvan de eerste 4 bytes in 3 hashes voorkomen;
- zijn er 43.895 waarvan de eerste 4 bytes in 4 hashes voorkomen;
- zijn er 1132 waarvan de eerste 4 bytes in 5 hashes voorkomen;
- zijn er 13 waarvan de eerste 4 bytes in 6 hashes voorkomen.
Kijk je naar de eerste 5 bytes dan vind je 139.551 niet unieke exemplaren (waarvan 24 stuks die 3x voorkomen terwijl de rest 2x voorkomt). Met de eerste 6 bytes zijn er nog 534 niet-unieke exemplaren (allen komen 2x voor). Kap je af tot 7 bytes dan vind je nog maar 4 duplicaten in genoemde file. Ik heb het niet meer getest maar ik vermoed dat in alle hashes de eerste 8 (van de 20) bytes uniek zijn in deze, best grote, dataset.
Veel mensen vinden het lastig om zich een voorstelling te maken van grote decimale getallen; bij binaire getallen (een bit lijkt heel weinig, en hex gaat heel hard) speelt dit nog meer; zie bijv. https://nl.wikipedia.org/wiki/Schaakbord#Legende.
Door Anoniem: Klopt, maar dat was ook niet mijn stelling: je kan je authenticeren met je echte ID, en de verhuurder mag als "bewijs" dat hij het ID gezien heeft een "veilige" kopie (zonder foto, zonder BSN) achterhouden. Daarmee kan hij aannemelijk (!) maken dat hij het ID gezien heeft (uit de oorspronkelijke post: " Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren.").
De aannemelijkheid wordt zwaar onderschat door mensen die zwaar onderschatten hoe makkelijk met grafische software de beelden gemanipuleerd kunnen worden. En omdat het documentnummer gewoon op de kopie mag blijven staan kan bij een strafrechtelijk onderzoek altijd achterhaald worden of het geen fake kopie is.
Het gaat niet alleen om strafzaken, er worden ook civiele zaken gevoerd. Ik kan me bijvoorbeeld een bericht herinneren waar ook een andere pasfoto in de kopie gemonteerd was (of een documentnummer in een scan van een andere id-kaart) en het bij de uiteindelijke rechtzaak alleen maar goed ging omdat de huidskleur van de persoon niet klopte. In zo'n civiele zaak worden de eisen aan bewijzen die in het strafrecht gelden helemaal niet gehanteerd. Een civiele rechter hakt een knoop door in een conflict tussen twee civiele partijen. Dat kan misgaan op wat de rechter, inderdaad, aannemelijk acht, en dat ging hier alleen maar goed omdat er sprake was van een kopie waarin evident iets niet klopte. Als het ingemonteerde portret vaag had geleken had het goed mis kunnen gaan. En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
De KopieID-app maakt helemaal geen gewaarmerkte kopie, die maakt een bewerkte kopie. Daarmee is het lastiger om te frauderen, maar beslist niet onmogelijk. Kennelijk ben jij een van de mensen die zwaar onderschat hoe makkelijk het is voor iemand die vaardig is met grafische software als Photoshop, Gimp etc. om het documentnummer en andere onderdelen uit de ene scan te monteren in een andere scan.Zonder een waarmerk dat bewijst dat een kopie voor een specifiek doel van een specifieke id-kaart is gemaakt, ben je gewoon weer terug bij af: het is het woord van de ene partij tegen het woord van de andere. Met het risico dat het woord van degene die de waarheid spreekt uiteindelijk niet wordt geloofd.
Wat het verder compliceert is dat tegenwoordig de benadeelde organisatie vaak genoeg niet zelf achter de schulden aangaat maar dat er incassobedrijven zijn die schulden overnemen en die heel agressief gaan innen. Die zijn alleen geïnteresseerd in het loskrijgen van het geld, niet in de vraag of ze wel de juiste persoon ermee lastigvallen. Langs die weg kan identiteitsfraude erg veel ellende opleveren.
04-05-2021, 09:34 door
Erik van Straten
Door Anoniem:
En omdat het documentnummer gewoon op de kopie mag blijven staan kan bij een strafrechtelijk onderzoek altijd achterhaald worden of het geen fake kopie is.
En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
1) Als je een watermerk kunt verwijderen, is het toevoegen van een ander watermerk een peuleschil;Door Erik van Straten:
Het probleem is dat het resultaat in veel te veel gevallen volstaat om online mee te authenticeren.
Klopt, maar dat was ook niet mijn stelling: je kan je authenticeren met je echte ID, en de verhuurder mag als "bewijs" dat hij het ID gezien heeft een "veilige" kopie (zonder foto, zonder BSN) achterhouden. Daarmee kan hij aannemelijk (!) maken dat hij het ID gezien heeft (uit de oorspronkelijke post: " Achteraf is op geen enkele manier meer na te gaan of die controle wel of niet goed is gedaan, naar een identiteitsbewijs kijken laat geen sporen achter die je achteraf kan controleren.").Door Anoniem: [identiteitsbewijs]
De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het zijn maar pixels. Iedereen die een beetje handig is met Paint, the Gimp of Photoshop kan zo'n watermerk verwijderen.De verhuurder moet er naar vragen, en jij mag daar een veilige kopie van geven. Dat kan iedereen zelf met bv. de KopieID app, waarbij je én BSN en bv. foto doorkrast, én er een watermark overheen zet dat dit alleen voor het huren van (kamer X op) adres Y op datum Z is. Die mag je sturen, want zo'n kopie is niet bruikbaar op een andere plek.
Het probleem is dat het resultaat in veel te veel gevallen volstaat om online mee te authenticeren.
En omdat het documentnummer gewoon op de kopie mag blijven staan kan bij een strafrechtelijk onderzoek altijd achterhaald worden of het geen fake kopie is.
En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
2) Ik zie niet in hoe het bezitten van een kopie of scan van een identiteitsbewijs "aannemelijk" maakt dat de bezitter daarvan de "eigenaar" in levenden lijve heeft gezien, noch dat diens gezicht nauwgezet is vergeleken met de pasfoto op het originele identiteitsbewijs, noch dat de echtheidskenmerken van dat identiteitsbewijs zijn gecheckt, noch dat het originele identiteitsbewijs op sporen van manipulatie is onderzocht (zoals een vervangen pasfoto).
Versneld door Corona is online (op afstand) "authenticatie" middels het opsturen van een "kopietje paspoort" of het kennen van een BSN populairder dan ooit; daarbij staat vast dat de betrokkene niet in levenden lijve is gezien. Het aantal databases met deze informatie groeit met de dag. En dus het aantal lekken en dus het aantal gevallen van identiteitsfraude. Dus mag je dit m.i. geen authenticatie (meer) noemen.
Zomaar een voorbeeld, in een oogwenk gevonden op Internet:
Een kopie van uw medisch dossier opvragen
Wilt u een kopie van uw medische gegevens opvragen? Print dan onderstaand formulier uit en stuur deze ingevuld en ondertekend samen met een kopie van een geldig identiteitsbewijs naar ons op.
Wilt u een kopie van uw medische gegevens opvragen? Print dan onderstaand formulier uit en stuur deze ingevuld en ondertekend samen met een kopie van een geldig identiteitsbewijs naar ons op.
Door Anoniem:[...]
En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
De KopieID-app maakt helemaal geen gewaarmerkte kopie, die maakt een bewerkte kopie. Daarmee is het lastiger om te frauderen, maar beslist niet onmogelijk. Kennelijk ben jij een van de mensen die zwaar onderschat hoe makkelijk het is voor iemand die vaardig is met grafische software als Photoshop, Gimp etc. om het documentnummer en andere onderdelen uit de ene scan te monteren in een andere scan.Klopt, ik weet het.
Zonder een waarmerk dat bewijst dat een kopie voor een specifiek doel van een specifieke id-kaart is gemaakt, ben je gewoon weer terug bij af: het is het woord van de ene partij tegen het woord van de andere. Met het risico dat het woord van degene die de waarheid spreekt uiteindelijk niet wordt geloofd.
Ik bedoel met een "gewaarmerkte kopie" een kopie waarbij bv. een Notaris heeft aangegeven dat dit een gewaarmerkte kopie is, door handtekening en stempel oid. Niet het bit/pixelpatroon
Wat het verder compliceert is dat tegenwoordig de benadeelde organisatie vaak genoeg niet zelf achter de schulden aangaat maar dat er incassobedrijven zijn die schulden overnemen en die heel agressief gaan innen. Die zijn alleen geïnteresseerd in het loskrijgen van het geld, niet in de vraag of ze wel de juiste persoon ermee lastigvallen. Langs die weg kan identiteitsfraude erg veel ellende opleveren.
Door Erik van Straten: [...]
2) Ik zie niet in hoe het bezitten van een kopie of scan van een identiteitsbewijs "aannemelijk" maakt dat de bezitter daarvan de "eigenaar" in levenden lijve heeft gezien, noch dat diens gezicht nauwgezet is vergeleken met de pasfoto op het originele identiteitsbewijs, noch dat de echtheidskenmerken van dat identiteitsbewijs zijn gecheckt, noch dat het originele identiteitsbewijs op sporen van manipulatie is onderzocht (zoals een vervangen pasfoto).
"Aannemelijk" is natuurlijk geen bewijs, maar als je een kopie hebt met de juiste dingen doorgestreept en het document nummer, dan kan je aannemelijk maken dat je het officiele document gezien hebt.En dat organisaties accoord gaan met een niet gewaarmerkte kopie, tja die moet je aansprakelijk stellen voor de geleden schade, want dan heeft die organisatie nooit het echte ID gezien, dus hebben ze niet aan de onderzoekplicht voldaan.
1) Als je een watermerk kunt verwijderen, is het toevoegen van een ander watermerk een peuleschil;2) Ik zie niet in hoe het bezitten van een kopie of scan van een identiteitsbewijs "aannemelijk" maakt dat de bezitter daarvan de "eigenaar" in levenden lijve heeft gezien, noch dat diens gezicht nauwgezet is vergeleken met de pasfoto op het originele identiteitsbewijs, noch dat de echtheidskenmerken van dat identiteitsbewijs zijn gecheckt, noch dat het originele identiteitsbewijs op sporen van manipulatie is onderzocht (zoals een vervangen pasfoto).
En zoals mijn docent Recht 40 jaar geleden een beetje sarcastisch zei: in een civiele rechtzaak gaat het om aannemelijk maken, en degene die het beste liegt wint. Dus hoe beter je kan aantonen dat je meer dan alleen een papieren kopietje hebt bekeken hoe meer kans je hebt...
Door Anoniem: Ik bedoel met een "gewaarmerkte kopie" een kopie waarbij bv. een Notaris heeft aangegeven dat dit een gewaarmerkte kopie is, door handtekening en stempel oid. Niet het bit/pixelpatroon
Ah, op die manier.Ik ben bang dat notarissen het erg druk gaan krijgen als dat voor elk kopietje van een id-kaart moet gebeuren, en dat het veel te duur wordt voor de meeste mensen.
En dan zijn er nog notarissen die hun diensten online aanbieden en doodleuk vragen om een scan van je identiteitsbewijs per e-mail aan ze op te sturen, zonder zelfs maar een mogelijkheid om een upload via hun website (https) te doen. Het zijn vast wel goede juristen, maar op de een of andere manier bekruipt mij bij dit soort dingen het gevoel dat dit niet de beroepsgroep is waar je technisch al te vooruitstrevende dingen van moet verwachten.
Door Anoniem:
Ik ben bang dat notarissen het erg druk gaan krijgen als dat voor elk kopietje van een id-kaart moet gebeuren, en dat het veel te duur wordt voor de meeste mensen.
Klopt, is alleen voor speciale gevallen, heb dit nog maar één keer hoeven doen de afgelopen 20 jaar)Door Anoniem: Ik bedoel met een "gewaarmerkte kopie" een kopie waarbij bv. een Notaris heeft aangegeven dat dit een gewaarmerkte kopie is, door handtekening en stempel oid. Niet het bit/pixelpatroon
Ah, op die manier.Ik ben bang dat notarissen het erg druk gaan krijgen als dat voor elk kopietje van een id-kaart moet gebeuren, en dat het veel te duur wordt voor de meeste mensen.
Vandaar "aannemelijk": je kan, in tegenstelling tot wat politici (en veel beveiligers) denken, nu eenmaal niet alles zeker stellen, want dat kost te veel. Dus hoe kan dat? Bv. met een half doorgestreepte kopie: dan kan eventueel op basis van het documentnummer eventueel achterhaalt worden of dat klopt. Als dat NIET klopt, heeft de betreffende persoon (in dit geval de huisbaas) nooit naar de echte gekeken, als het WEL klopt had de bedrieger kennelijk toegang tot het echte ID of een kopie ervan, en kan je de goede trouw niet "bewijzen". Maar het is wel aannemelijker...
En dan zijn er nog notarissen die hun diensten online aanbieden en doodleuk vragen om een scan van je identiteitsbewijs per e-mail aan ze op te sturen, zonder zelfs maar een mogelijkheid om een upload via hun website (https) te doen. Het zijn vast wel goede juristen, maar op de een of andere manier bekruipt mij bij dit soort dingen het gevoel dat dit niet de beroepsgroep is waar je technisch al te vooruitstrevende dingen van moet verwachten.
Ja, zucht, meermalen meegemaakt :-( ...
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
