Opslaan van rijksregisternummer als hash

[ONiel]

Ik ben een app aan het maken waarop ouders kunnen inloggen. Ouders kunnen een kind toevoegen, toevoegen betekent gewoon de naam, voornaam en geboortedatum opslaan. Een kind is gelinkt aan de ouder die hem heeft aangemaakt.

Het is echter zo dat een kind meerdere ouders kan hebben, in de situatie van gescheiden ouders of dergelijke. Een tweede ouder kan zou dus hetzelfde kind moeten kunnen toevoegen. In de functionele omschrijving staat het zo dat bij het toevoegen van het kind we ook diens rijksregisternummer opslaan. Als een andere ouder een reeds opgeslagen kind wil toevoegen kan dit gedaan woorden door datzelfde rijksregisternummer in te geven. Als het kind bestaat wordt het ook aan de tweede ouder gelinkt.

Rijksregisternummers van personen opslaan is echter niet toegelaten volgens wet in Belgie. Dus dit moet anders. Wat als ik niet het rijksregisternummer opsla, maar een hash van dit nummer? Is dit dan nog steeds in overtreding van deze wet?

[99ruud99]

Ik zou dit nog eens overlopen met de privacy officer van je organisatie
Is het essentieel om deze gegevens op te slaan van minderjarige kinderen? Waarom kan dit niet gepseudonimiseerd?
Er zit heel wat gdpr wetgeving aan wat je probeert te maken. Ik lees nu een grote ramp

Mocht je geen privacy officer hebben stuur maar even een pm, kan ik hier even mee laten kijken als je wilt

Ps ook de hash is niet toegestaan, omdat het grotendeels geb. Datum + Hash is.

Maareh, naam + geb. Datum mag ook al niet zomaar


Ps, gezien je vorige topics zou ik toch echt eens wat cursussen in de gdpr volgen, dit is al zoveelste extreem privacy schendende topic in korte tijd ondertussen blijkt toch wat meer tijd tussen te zitten, maar cursus gdpr is nooit weg

[ Voor 32% gewijzigd door 99ruud99 op 06-11-2024 23:00 ]

[ONiel]

Dag Ruud, ik ga je volgende week een PM sturen dan, merci voor de hulp.

We hebben geen privacy officier, dit is een project in bijberoep. Ik trek zelf even aan de alarmbel omdat het in de functionele beschrijving v/d klant zat en ik mij afvroeg of dat wel mocht.

Ik hecht zelf heel veel waarde aan privacy, en niet enkel voor mezelf maar ook voor de gebruikers waarvoor ik de app maak. Dus ik wil het zeker conform regels doen.

Even nieuwsgierig: in welk topic zie je nog privacyschendingen staan?

[99ruud99]

Simpele betaaloplossing voor bestellen van broodjes?
Deze is ook een datalek in wording...

Is het retargetten van Website bezoekers op Facebook nog mog
En deze , maar bij beter kijken is het 2022, je hebt gelijk.

[ Voor 39% gewijzigd door 99ruud99 op 06-11-2024 22:59 ]

[ONiel]

Ja akkoord. Maar dat is een heel interne app die niet eens publiek op internet zou komen. Alle 10 gebruikers zouden precies weten wat er met hun data gebeurd. Maar ik snap je punt.

[99ruud99]

Maar je hebt gelijk, heb post even aangepast, zat wat meer tijd tussen dan op profiel meteen zichtbaar was ik herinnerde me het nog die discussie (toevallig heb ik er eentje gebruikt als oefenmateriaal xD)

[franssie]

Het hebben van een BSN/Rijksregisternummer is wel gemakkelijk maar inderdaad niet handig, veilig of toegestaan.
Dus zal je het anders moeten modelleren om je eigen unieke ID te generen.

Dus een N-N relatie oplossen, waarbij een persoon ook meerdere links naar een kind kan hebben (ouder, voogd, zus, broer, bedenk het maar). Die uitdaging is denk ik groter dan het unieke ID.

[cs-tweak]

ONiel schreef op woensdag 6 november 2024 @ 23:00:
Ja akkoord. Maar dat is een heel interne app die niet eens publiek op internet zou komen. Alle 10 gebruikers zouden precies weten wat er met hun data gebeurd. Maar ik snap je punt.

Blijkbaar snap je het punt niet. Of het intern of extern is doet er niet toe.

[franssie]

cs-tweak schreef op woensdag 6 november 2024 @ 23:12:
[...]

Blijkbaar snap je het punt niet. Of het intern of extern is doet er niet toe.

Ga je ook handhaven op een A4 met uitgaven en inkomsten op de koelkast? Dat is dan evenveel data.

[BytePhantomX]

ONiel schreef op woensdag 6 november 2024 @ 21:48:
Rijksregisternummers van personen opslaan is echter niet toegelaten volgens wet in Belgie. Dus dit moet anders. Wat als ik niet het rijksregisternummer opsla, maar een hash van dit nummer? Is dit dan nog steeds in overtreding van deze wet?

Als de Belgische wetgeving vergelijkbaar is met de Nederlandse, dan gaat het niet persé om opslaan, maar om verwerken. En zodra je in een invoerveld het nummer vraagt en daarvan een hash opslaat, ben je alsnog dit rijksregistratienummer aan het verwerken. En dat is zeer waarschijnlijk niet toegestaan.

En alhoewel je technisch misschien een aardige oplossing hebt, ga je in de app nog steeds om het nummer vragen. Het zou me niet verbazen als dat veel klachten op gaat leveren en je alsnog moet besluiten dat nummer eruit te halen. En zo te lezen haal je dan heel de architectuur van je datamodel onderuit.

[lordgandalf]

Dit klinkt niet iets wat als een hobby-bob projectje opgepakt zou moeten worden imho.

[cs-tweak]

franssie schreef op woensdag 6 november 2024 @ 23:42:
[...]

Ga je ook handhaven op een A4 met uitgaven en inkomsten op de koelkast? Dat is dan evenveel data.

Met zo’n instelling omtrent privacy hoop ik inderdaad van wel

[DJMaze]

Persoon A geeft bij kind 1 aan dat Persoon B aan dit kind gekoppeld moet worden.
Persoon B krijgt een melding en accepteert/weigert dit verzoek.

Heb je verder niks nodig en niemand die at random alle rijksregisternummers aan zijn account koppelt.

Ik vraag mij wel af waarom jullie bedrijf geen mensen met kennis/ervaring hebben.
Je kan zo toch niet functioneren?

[ Voor 19% gewijzigd door DJMaze op 12-11-2024 17:06 ]

[Blokker_1999]

DJMaze schreef op dinsdag 12 november 2024 @ 17:04:
Persoon A geeft bij kind 1 aan dat Persoon B aan dit kind gekoppeld moet worden.
Persoon B krijgt een melding en accepteert/weigert dit verzoek.

Heb je verder niks nodig en niemand die at random alle rijksregisternummers aan zijn account koppelt.

Ik vraag mij wel af waarom jullie bedrijf geen mensen met kennis/ervaring hebben.
Je kan zo toch niet functioneren?

We kennen uiteraard de context van de app niet, maar ook hier heb je mogelijks weer issues. Wanneer de registratie van ouder B afhankelijk is van een actie van ouder A moet je er maar op vertrouwen dat ouder A dit wel wenst toe te staan.

Je zit hier dus niet alleen met een probleem van wet- en regelgeving, maar ik zie ook dat er vele vraagtekens zijn rondom het uitwerken van een goede, werkbare architectuur.

franssie schreef op woensdag 6 november 2024 @ 23:42:
[...]

Ga je ook handhaven op een A4 met uitgaven en inkomsten op de koelkast? Dat is dan evenveel data.

GDPR en andere privacywetgeving bestaat NIET exclusief in het digitale domein, maar is overal van toepassing. Het maakt niet uit of je een RRN opslaat in een database danwel even opschrijft op een papiertje. In beide gevallen ben je dat nummer aan het verwerken en zijn er mogelijke gevolgen voor de privacy die in kaart moeten gebacht worden en worden geevalueerd. Nog al te vaak gaan mensen er van uit dat het allemaal zoveel kwaad toch niet kan. Totdat het misloopt. En dan begrijpt niemand hoe het zo ver is kunnen komen.

[DJMaze]

Blokker_1999 schreef op zondag 17 november 2024 @ 12:56:
We kennen uiteraard de context van de app niet, maar ook hier heb je mogelijks weer issues. Wanneer de registratie van ouder B afhankelijk is van een actie van ouder A moet je er maar op vertrouwen dat ouder A dit wel wenst toe te staan.

Ja en? Misschien mag B dat helemaal niet door een gerechtelijke uitspraak of éénhoofdig gezag.
Of A mag het niet en is B voor.

Is dat aan jullie of moeten de opvoeders dat maar zelf uitvechten?

Er zijn helemaal geen issues, alleen uitdagingen.

[Aftansert]

Het heeft niet zoveel zin om een hash van een relatief kort getal op te slaan, omdat je makkelijk het originele getal kan vinden. Stel dat je Rijksregisternummer 68942577 is, en je neemt hiervan een SHA256 hash, 87d3d47d8949ef6848b895197391bfe982a0c65512e34d6e2218cbac844a522e.

Dan valt het originele Rijksregisternummer simpelweg terug te vinden met dit kleine stukje Ruby (of willekeurig welke programmeertaal):

code:

require 'digest'

target_sha256 = '87d3d47d8949ef6848b895197391bfe982a0c65512e34d6e2218cbac844a522e'
puts (10**7...10**8).find{|n| Digest::SHA256.hexdigest(n.to_s) == target_sha256}

Bij een echt Rijksregisternummer is het nog eenvoudiger omdat er veel meer structuur in zit qua geboortedatum en controlegetal. De hash van het nummer opslaan is dus niet veel beter dan het nummer zelf.

[DaFeliX]

Aftansert schreef op donderdag 21 november 2024 @ 22:17:
Het heeft niet zoveel zin om een hash van een relatief kort getal op te slaan, omdat je makkelijk het originele getal kan vinden. Stel dat je Rijksregisternummer 68942577 is, en je neemt hiervan een SHA256 hash, 87d3d47d8949ef6848b895197391bfe982a0c65512e34d6e2218cbac844a522e.

Dan valt het originele Rijksregisternummer simpelweg terug te vinden met dit kleine stukje Ruby (of willekeurig welke programmeertaal):

code:

require 'digest'

target_sha256 = '87d3d47d8949ef6848b895197391bfe982a0c65512e34d6e2218cbac844a522e'
puts (10**7...10**8).find{|n| Digest::SHA256.hexdigest(n.to_s) == target_sha256}

Bij een echt Rijksregisternummer is het nog eenvoudiger omdat er veel meer structuur in zit qua geboortedatum en controlegetal. De hash van het nummer opslaan is dus niet veel beter dan het nummer zelf.

Nu is dit hele specifieke probleem eenvoudig op te lossen. ipv alleen het korte nummer te encrypten, zet je er een lange string met willekeurige tekens bij: salt. Zolang deze salt geheim blijft, en goed willekeurig is, heb je dit probleem afgevangen.

Waarmee ik het overigens nog geen goed idee vind om rijksnummers op te slaan. De beste remedie tegen het potentieel lekken van gegevens, is ze simpelweg niet op te slaan.

[Croga]

BytePhantomX schreef op donderdag 7 november 2024 @ 08:16:
Als de Belgische wetgeving vergelijkbaar is met de Nederlandse, dan gaat het niet persé om opslaan, maar om verwerken. En zodra je in een invoerveld het nummer vraagt en daarvan een hash opslaat, ben je alsnog dit rijksregistratienummer aan het verwerken. En dat is zeer waarschijnlijk niet toegestaan.

What he ^^ says....

Je mag niet eens naar het nummer vragen. Hoe je het opslaat is niet interessant; je mag het niet verwerken, mag het niet hebben en mag er dus überhaupt niet naar vragen.

En daarmee heb je dus inderdaad een issue in de architectuur; je zult nooit een optie hebben om een kind uniek te identificeren. Je zult de architectuur daarom volledig om moeten gooien; Als de kinderen al in kaart zijn zul je zelf een sleutel moeten genereren en op basis daarvan de relatie moeten gaan maken. Maar daar zit je met het volgende probleem: Zodra je in je database een kind met een sleutel hebt is die sleutel een persoonsgegeven geworden en moet die dus ook beschermd worden.

Dit is een heel groot zwart gat waar je in aan het duiken bent en zonder gedegen privacy kennis ga je hier nooit uit komen. Terug naar je opdrachtgever dus en de opdracht teruggeven totdat dit allemaal goed geregeld is.

[Aftansert]

DaFeliX schreef op vrijdag 22 november 2024 @ 07:20:
[...]


Nu is dit hele specifieke probleem eenvoudig op te lossen. ipv alleen het korte nummer te encrypten, zet je er een lange string met willekeurige tekens bij: salt. Zolang deze salt geheim blijft, en goed willekeurig is, heb je dit probleem afgevangen.

Je bedoelt wellicht de secret key van een HMAC in plaats van een salt. Een salt is een gegeven dat naast een hash wordt opgslagen, en is dus niet geheim (of in ieder geval net zo geheim als de hash). Een salt wordt gebruikt bij wachtwoordopslag om het moeilijker te maken dezelfde precomputed hashes (een rainbow table) te gebruiken voor verschillende wachtwoorden. Niet van toepassing hier.

Maar ook een HMAC met secret key lost in het scenario van OP weinig op, zowel qua beveiliging als qua AVG-plicht. Qua beveiliging lost het weinig op omdat de applicatie nog steeds de secret key moet kennen, en ongeveer net zo makkelijk lekt als de database met hashes (tenzij je speciale maatregelen treft). Qua AVG-plicht lost het weinig op omdat je alsnog (uniek) identificeerbare gegevens verwerkt en opslaat. Het scriptje hierboven werkt net zo goed met een HMAC.

Redeneer: als een secret key een oplossing zou zijn, zou je net zo goed elk Rijksregisternummer zelf geheim kunnen houden.

[jurroen]

Maar... Je geeft aan dat de app tien gebruikers zou hebben. Dat zegt nog niet bijster veel. Want over hoeveel mensen aan data hebben we het? Tien waarbij iedereen zijn / haar / hun eigen data beheerd? Paar honderd want basisschool? Of miljoenen want een of andere overheidsklus die via aanbesteding had moeten gaan maar is weggemoffeld naar een handig neefje?

Zoals anderen al aangaven: BSN / rijksregisternummer is een big no. Niet met een hash, niet met een salt en ook niet met pepper. Gewoon helemaal niet. Als je het vraagt ben je zeer waarschijnlijk al in overtreding.

Je kunt iedereen in die databank ook een random UUID geven... Maar of dat binnen het beoogde scenario past weet ik niet, omdat daarvoor informstke ontbreekt.