SSL en beveiliging voor lokale stemwijzer

[thijsguelen22]

Hallo mede-Tweakers,

Ik heb mij onlangs aangesloten bij de lokale omroep van mijn kleine stadje.
Ik ben zelf student Applicatieontwikkelaar, en heb redelijke ervaring met PHP, C# e.d.

Nu is vanuit het bestuur mij gevraagd om een stemwijzer te maken. Allemaal leuk en wel, systeempje is al opgezet.

Nu kwam echter de vraag of we geanonimiseerd antwoorden op kunnen slaan. Nu ben ik als de dood dat er straks een lek ontstaat of dingen onduidelijk zijn, dus dat wil ik ten zeerste voorkomen.

Wat heb ik nodig om dit veilig te laten lopen? De stemwijzer zelf draait op mijn eigen webserver bij Versio, en wordt gelinkt aan een subdomein van de omroep (ook bij Versio). Hebben beide servers een SSL certificaat nodig?
En is het certificaat van 5 euro al voldoende?

Alvast bedankt!

Thijs-Jan Guelen

[emnich]

Ja SSL sowieso. Die van 5 euro is al voldoende, zelfs een gratis is goed.

Zorg er verder voor dat je géén analytics (of Facebook e.d.) op de pagina hebt staan en dat je op geen enkele manier de gebruiker trackt en dat je de resultaten inderdaad volledig anoniem op slaat.

Dan is er ook geen reden tot grote paniek als je toch gehackt wordt.

[Umbrah]

Uiteraard is een SSL certificaat nodig; maar dat vertelt eigenlijk meer over de versluiteling van het verkeer tussen client & server... Ik denk dat je daarmee al één ding hebt opgelost. Je zult echter véél en véél meer willen doen, en juist hierdoor denk ik dat je dit wat professioneler moet gaan oppakken... enkele punten:

• De server zelf, is die versleuteld van begin tot eind?
• De weblogs: houd je 100% geen koppeling tussen bezoek en het werkelijk opslaan van het resultaat?
• De resultaten opslaan: ga je dit ontsluiten via web; en zoja: dezelfde omgeving of een andere? En zonder unieke vermelding: hoe voorkom je fraude? (een geensteil artikel wat mensen massaal foute resultaten laat doen, zodat je omroep straks moet rapporteren: ondanks 90% advies: stem [controversiele partij], stemt iedereen op [niet controversiele partij])
• Eventuele inlog: hoe ga je accounts storen/ontsluiten?
• De stemwijzer zelf: je schrijft dus straks naar een database waarschijnlijk server-side... is alles beveiligd tegen escapes/queries/unsanitised input?

Misschien wil je de hele database als een write-only dump-bak hebben die op een volledig andere machine staat... je zult functioneel en technisch een hóóp meer werk moeten doen dan een SSL certificaatje aan te vragen -- zeker met iets wat zó privé en zó beveiligd is als stemmen... je wilt niet de ambasade zijn van een bepaald land wat door een simpele URL change alle visum requests open en bloot exposed had!

[Boudewijn]

Moet je dit willen als je nog niet goed genoeg weet hoe het werkt? Dit is best wel privacygevoelige informatie en dingen liggen ten tijde van verkiezingen best onder een vergrootglas.

Hoe doen grotere gemeenten dit?

[Puch-Maxi]

Waarom zou je de input van de gebruiker op willen slaan, als het doel is om een stemadvies te geven?
Of is het doel datamining?

[eric.1]

Ik zou er nog eens goed over nadenken. Een certificaat is 1 (kan zelfs gratis via Let's Encrypt), maar dat is natuurlijk maar een van de vele maatregelen die je zal moeten nemen.

Het klinkt flauw, maar je zal ook hack-bestendig moeten zijn. Een verkiezing beinvloeden door de resultaten van een stemwijzer te manipuleren....het zal niet de eerste noch de laatste keer zijn.

Dan zet je die stemwijzer op jouw eigen servertje, zou ik nooit doen. Laat die Omroep maar wat regelen.

Plaats ook geen overbodige cookies!

Sla je alles versleuteld op?

Hoe is die server verder ingeregeld en beveiligd?

...

[McKaamos]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:05:
Hallo mede-Tweakers,

Ik heb mij onlangs aangesloten bij de lokale omroep van mijn kleine stadje.
Ik ben zelf student Applicatieontwikkelaar, en heb redelijke ervaring met PHP, C# e.d.

Nu is vanuit het bestuur mij gevraagd om een stemwijzer te maken. Allemaal leuk en wel, systeempje is al opgezet.

Nu kwam echter de vraag of we geanonimiseerd antwoorden op kunnen slaan. Nu ben ik als de dood dat er straks een lek ontstaat of dingen onduidelijk zijn, dus dat wil ik ten zeerste voorkomen.

Wat heb ik nodig om dit veilig te laten lopen? De stemwijzer zelf draait op mijn eigen webserver bij Versio, en wordt gelinkt aan een subdomein van de omroep (ook bij Versio). Hebben beide servers een SSL certificaat nodig?
En is het certificaat van 5 euro al voldoende?

Alvast bedankt!

Thijs-Jan Guelen

Ja, SSL is nodig.
Echter, doet dat niks tegen de dingen waar jij bang voor bent.

SSL is encryptie van de communicatie. De verzender verpakt zijn antwoord in encryptie, en jouw server pakt het weer uit. Op die manier kan iemand die tussen de twee punten zit te luisteren niet lezen wat er heen en weer gestuurd wordt.
Dat is uiteraard belangrijk, en opzich kan je daar b.v. prima een gratis LetsEncrypt certificaat voor gebruiken.

Echter, wat ik lees is dat je bang bent dat gegevens gestolen of gemanipuleerd worden. Daar helpt SSL niet tegen.
Wil je dat beveiligen, dan moet je eerst eens gaan kijken naar wat jij zelf hebt geprogrammeerd.
Kan je daar bijvoorbeeld een XSS attack op uitvoeren? Zijn er mogelijkheden om SQL injectie te doen?
Dat kan je (laten) testen middels een zogeheten Pen-test.
Er bestaan kant-en-klare linux distributies met alle noodzakelijke tooling aan boord om dat te doen. Denk aan Kali Linux.
Je moet uiteraard wel weten waar je dan mee bezig bent.
Je zou ook een licentie op ReadyAPI (met SecurePro uitbreiding) kunnen nemen (vrij prijzig) en daarmee alle API's onderwerpen aan een common vulnerabilities test. DIe genereert hij vol automatisch voor je, al zal dat niet per definitie volledig dekkend zijn. Je moet alleen even je API definitie inladen (WADL, WSDL, Swagger) en dan kan je aan de slag.

Daarnaast moet ook je server beveiliging op orde zijn. Ik ga er even vanuit dat je bij een doodnormale webhoster zit en daar een shared hosting pakketje afneemt.
Daar kan je helaas zelf weinig aan doen. Eigenlijk het enige wat je dan kan doen, is zorgen voor goede, complexe wachtwoorden.

Heb je je eigen dedicated server of een VPS, dan kan je dat wel.
Je zou kunnen beginnen met IP bans uitdelen op basis van activiteit die gelogd wordt. Een tool zoals Fail2Ban helpt daar enorm bij en bevat al een hoop standaard regels.
Of toegang tot SSH of RDP laten werken met een certificaat ipv een wachtwoord. Certificaten zijn vele malen sterker dan wachtwoorden.
Monitoren van wijzigingen op het filesystem met een tool als AIDE zou ook heel nuttig kunnen zijn. Dat is dan al wel na een inbraak, maar dan krijg je wel een alert als er bestanden zijn gewijzigd die niet mogen wijzigen.

Edit:
leuk kijkvoer, de basis waarop de meeste gebruikelijke hacks werken.

[ Voor 5% gewijzigd door McKaamos op 17-01-2018 13:34 ]

[lonkhuijzen]

Denk ook goed na over je datamodel.

Je logging van je webserver welk ip je op bezoek je hebt gehad en een losse database met daarin de anonieme uitslag maar wel met timestamp is al weer samen te brengen tot de persoon herleidbare informatie.

Als het mis gaat heb je redelijk snel brenno de winter op bezoek

[thijsguelen22]

McKaamos schreef op woensdag 17 januari 2018 @ 13:27:
[...]

Ja, SSL is nodig.
Echter, doet dat niks tegen de dingen waar jij bang voor bent.

SSL is encryptie van de communicatie. De verzender verpakt zijn antwoord in encryptie, en jouw server pakt het weer uit. Op die manier kan iemand die tussen de twee punten zit te luisteren niet lezen wat er heen en weer gestuurd wordt.
Dat is uiteraard belangrijk, en opzich kan je daar b.v. prima een gratis LetsEncrypt certificaat voor gebruiken.

Echter, wat ik lees is dat je bang bent dat gegevens gestolen of gemanipuleerd worden. Daar helpt SSL niet tegen.
Wil je dat beveiligen, dan moet je eerst eens gaan kijken naar wat jij zelf hebt geprogrammeerd.
Kan je daar bijvoorbeeld een XSS attack op uitvoeren? Zijn er mogelijkheden om SQL injectie te doen?
Dat kan je (laten) testen middels een zogeheten Pen-test.
Er bestaan kant-en-klare linux distributies met alle noodzakelijke tooling aan boord om dat te doen. Denk aan Kali Linux.
Je moet uiteraard wel weten waar je dan mee bezig bent.
Je zou ook een licentie op ReadyAPI (met SecurePro uitbreiding) kunnen nemen (vrij prijzig) en daarmee alle API's onderwerpen aan een common vulnerabilities test. DIe genereert hij vol automatisch voor je, al zal dat niet per definitie volledig dekkend zijn. Je moet alleen even je API definitie inladen (WADL, WSDL, Swagger) en dan kan je aan de slag.

Daarnaast moet ook je server beveiliging op orde zijn. Ik ga er even vanuit dat je bij een doodnormale webhoster zit en daar een shared hosting pakketje afneemt.
Daar kan je helaas zelf weinig aan doen. Eigenlijk het enige wat je dan kan doen, is zorgen voor goede, complexe wachtwoorden.

Heb je je eigen dedicated server of een VPS, dan kan je dat wel.
Je zou kunnen beginnen met IP bans uitdelen op basis van activiteit die gelogd wordt. Een tool zoals Fail2Ban helpt daar enorm bij en bevat al een hoop standaard regels.
Of toegang tot SSH of RDP laten werken met een certificaat ipv een wachtwoord. Certificaten zijn vele malen sterker dan wachtwoorden.
Monitoren van wijzigingen op het filesystem met een tool als AIDE zou ook heel nuttig kunnen zijn. Dat is dan al wel na een inbraak, maar dan krijg je wel een alert als er bestanden zijn gewijzigd die niet mogen wijzigen.

Edit:
leuk kijkvoer, de basis waarop de meeste gebruikelijke hacks werken.
[video]
[video]
[video]
[video]

Van wat ik zo hoor, is het allemaal erg ingewikkeld.

Hier was ik natuurlijk op voorbereid, maar ik hoor zo dingen voorbij komen die mij nog niet eerder opkwamen. Dank daarvoor.

Ik denk dat ik met het bestuur in overleg ga om in ieder geval aan te geven dat de resultaten niet doorberekend moeten worden naar harde percentages vanwege de betrouwbaarheid. Mijn prioriteit ligt er nu vooral bij om het veilig in de database te krijgen en het daar veilig te kunnen houden. In principe loopt alles met PDO en wordt data intern verstuurd via een session of via post. Ik neem aan dat hier van buitenaf niet een injectie plaats kan vinden toch? Er zit een check in die de radiobuttons uitleest (waarde 1, 2 of 3, die in die volgorde staan voor eens, oneens en geen mening). Als iemand bijvoorbeeld het cijfer 4 verstuurd, wordt dit automatisch "geen mening".

Nogmaals, dank voor de tips!

[Gomez12]

Bedenk ook heel goed wat je wilt met de opgeslagen gegevens.

Als je die anoniem wilt opslaan dan zijn het ook minder betrouwbare gegevens want iedereen kan dan opeens 10.000 x op zijn partij stemmen waardoor die naar boven schiet in jouw stemwijzer terwijl het maar 1 persoon is.

[Stoelpoot]

Hetgeen wat ik me afvraag is: Waarom sla je antwoorden op, en wat wil je er extra bij hebben zodat het mogelijk *niet* anoniem is?

Het is eigenlijk heel simpel: Voor een stemwijzer heb je alleen de antwoorden nodig om een berekening te maken. Daar zitten geen prive gegevens in. Dus wat komt er bovenop de antwoorden waardoor dit *wel* prive gegevens bevat?

Overigens mis ik ook nog de reden dat je antwoorden uberhaupt opslaat...

[McKaamos]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:39:
[...]


Van wat ik zo hoor, is het allemaal erg ingewikkeld.

Hier was ik natuurlijk op voorbereid, maar ik hoor zo dingen voorbij komen die mij nog niet eerder opkwamen. Dank daarvoor.

Ik denk dat ik met het bestuur in overleg ga om in ieder geval aan te geven dat de resultaten niet doorberekend moeten worden naar harde percentages vanwege de betrouwbaarheid. Mijn prioriteit ligt er nu vooral bij om het veilig in de database te krijgen en het daar veilig te kunnen houden. In principe loopt alles met PDO en wordt data intern verstuurd via een session of via post. Ik neem aan dat hier van buitenaf niet een injectie plaats kan vinden toch? Er zit een check in die de radiobuttons uitleest (waarde 1, 2 of 3, die in die volgorde staan voor eens, oneens en geen mening). Als iemand bijvoorbeeld het cijfer 4 verstuurd, wordt dit automatisch "geen mening".

Nogmaals, dank voor de tips!

Daar zit al een denkfoutje
Session of Post is van nature niet intern. Dat is juist je communicatie met de gebruiker.
Elke keer dat de gebruiker ergens op klikt, gaat er een GET, POST of ander HTML method over de lijn, met daarbij een set variabelen die door de gebruiker zijn opgestuurd.
Een normale gebruiker komt er niet op om die berichten te manipuleren. Er staat een formulier met een selectievakje, en daar kan hij/zij op klikken en dat is wat verstuurd wordt.
Echter, je hoeft niet heel handig te zijn om dat te manipuleren. Gewoon de developerconsole van je browser openen (F12) en dan b.v. namen van je checkboxes vervangen voor iets anders, of de waarde die daar aan gekoppeld is.
En dan druk je op "verzend".
Dat is iets wat je wil afvangen. Never trust user input.

En dan hoeft het b.v. geen SQL injectie te zijn, omdat je prepared statements gebruikt. Maar XSS is dan nogsteeds een optie.
Of misschien triggert het wel een foutmelding, waarbij je server een stacktrace uitspuugt. Die geeft dan mogelijk handvatten wat de volgende stap is om een succesvolle hack te plaatsen.

[thijsguelen22]

Stoelpoot schreef op woensdag 17 januari 2018 @ 13:44:
Hetgeen wat ik me afvraag is: Waarom sla je antwoorden op, en wat wil je er extra bij hebben zodat het mogelijk *niet* anoniem is?

Het is eigenlijk heel simpel: Voor een stemwijzer heb je alleen de antwoorden nodig om een berekening te maken. Daar zitten geen prive gegevens in. Dus wat komt er bovenop de antwoorden waardoor dit *wel* prive gegevens bevat?

Overigens mis ik ook nog de reden dat je antwoorden uberhaupt opslaat...

In principe wil ik voorkomen dat de gegevens te herleiden zijn. Als je ip adressen opslaat, kun je het een en ander natuurlijk herleiden

Het doel van het opslaan in om een peiling te kunnen maken van wat het volk straks gaat stemmen. Bestuur heeft aangegeven dat ze die data mee willen nemen naar een debat. Ik heb uiteraard wel aangegeven (na jullie info) dat deze data sterk onderhevig is aan beïnvloeding van groepen als GeenStijl, 4Chan etc.

[McKaamos]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:49:
[...]


In principe wil ik voorkomen dat de gegevens te herleiden zijn. Als je ip adressen opslaat, kun je het een en ander natuurlijk herleiden

Het doel van het opslaan in om een peiling te kunnen maken van wat het volk straks gaat stemmen. Bestuur heeft aangegeven dat ze die data mee willen nemen naar een debat. Ik heb uiteraard wel aangegeven (na jullie info) dat deze data sterk onderhevig is aan beïnvloeding van groepen als GeenStijl, 4Chan etc.

Wat je zou kunnen doen, is Oauth gebruiken (aanmelden met facebook, google, etc) en dan wél opslaan dat de persoon ingelogd is plus een waarde "stemwijzer is doorlopen = true", maar de resultaten slechts optellen bij een losstaande teller.
Je hebt dan geen verbinding tussen de gebruiker en het resultaat, maar je weet wel wie de wijzer heeft gebruikt zodat je bij een volgende poging de resultaten gewoon niet optelt bij je teller.
Iemand kan dan 1000x de stemwijzer doorlopen, maar alleen de eerste poging telt mee.

[thijsguelen22]

McKaamos schreef op woensdag 17 januari 2018 @ 13:48:
[...]


Daar zit al een denkfoutje
Session of Post is van nature niet intern. Dat is juist je communicatie met de gebruiker.
Elke keer dat de gebruiker ergens op klikt, gaat er een GET, POST of ander HTML method over de lijn, met daarbij een set variabelen die door de gebruiker zijn opgestuurd.
Een normale gebruiker komt er niet op om die berichten te manipuleren. Er staat een formulier met een selectievakje, en daar kan hij/zij op klikken en dat is wat verstuurd wordt.
Echter, je hoeft niet heel handig te zijn om dat te manipuleren. Gewoon de developerconsole van je browser openen (F12) en dan b.v. namen van je checkboxes vervangen voor iets anders, of de waarde die daar aan gekoppeld is.
En dan druk je op "verzend".
Dat is iets wat je wil afvangen. Never trust user input.

En dan hoeft het b.v. geen SQL injectie te zijn, omdat je prepared statements gebruikt. Maar XSS is dan nogsteeds een optie.
Of misschien triggert het wel een foutmelding, waarbij je server een stacktrace uitspuugt. Die geeft dan mogelijk handvatten wat de volgende stap is om een succesvolle hack te plaatsen.

-insert facepalm-

Je hebt helemaal gelijk... Verrek...

Wat zou de beste manier zijn? Kan ik data plaatsen in $_SEERVER? Ik ga in ieder geval een functie schrijven die code afvangt.

[P_Tingen]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:49:
[...]Het doel van het opslaan in om een peiling te kunnen maken van wat het volk straks gaat stemmen. Bestuur heeft aangegeven dat ze die data mee willen nemen naar een debat. Ik heb uiteraard wel aangegeven (na jullie info) dat deze data sterk onderhevig is aan beïnvloeding van groepen als GeenStijl, 4Chan etc.

En aan de aard van de partij. Stel dat er lokaal een 80+partij is. Het is niet onredelijk om aan te nemen dat 80+'ers minder vaak op internet zitten en dus minder vaak jouw stemwijzer zullen invullen. Gevolg: voorspelling voor 80+ was 0%, bij verkiezingen ineens X%

McKaamos schreef op woensdag 17 januari 2018 @ 13:52:
[...]
Wat je zou kunnen doen, is Oauth gebruiken (aanmelden met facebook, google, etc) en dan wél opslaan dat de persoon ingelogd is plus een waarde "stemwijzer is doorlopen = true", maar de resultaten slechts optellen bij een losstaande teller.

Dan moeten de gebruikers dat wel vertrouwen. Persoonlijk zou ik me dan al op mijn achterhoofd krabben wanneer ik me moet aanmelden voor een anoniem stemadvies.

Misschien is het dan beter om op een andere manier een fingerprint samen te stellen van de bezoeker aan de hand van browsergegevens en dat op te slaan icm 'stemwijzer doorlopen = true'

[ Voor 33% gewijzigd door P_Tingen op 17-01-2018 13:55 ]

[P_Tingen]

.

[ Voor 99% gewijzigd door P_Tingen op 17-01-2018 13:55 ]

[McKaamos]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:52:
[...]


-insert facepalm-

Je hebt helemaal gelijk... Verrek...

Wat zou de beste manier zijn? Kan ik data plaatsen in $_SEERVER? Ik ga in ieder geval een functie schrijven die code afvangt.

Ik zou beginnen met het uitmappen wat bepaalde waardes wel en niet mogen zijn.
Bijvoorbeeld: invulveld X is een cijfer van 1 teken, range 1 t/m 4.
En dan maak je daar checks voor. Indien check niet goed gegaan, geef gebruiker de melding dat er iets mis is met de ingevulde waarde.

Verder, gebruik zo min mogelijk globals (zoals $_SERVER).
Sessie gebonden informatie zet je uiteraard gewoon in $_SESSION, maar je controleert het wel elke keer.
Ingekomen POSTs, GETs, etc haal je ook door een check heen, etc.

[emnich]

McKaamos schreef op woensdag 17 januari 2018 @ 13:52:
[...]

Wat je zou kunnen doen, is Oauth gebruiken (aanmelden met facebook, google, etc) en dan wél opslaan dat de persoon ingelogd is plus een waarde "stemwijzer is doorlopen = true", maar de resultaten slechts optellen bij een losstaande teller.
Je hebt dan geen verbinding tussen de gebruiker en het resultaat, maar je weet wel wie de wijzer heeft gebruikt zodat je bij een volgende poging de resultaten gewoon niet optelt bij je teller.
Iemand kan dan 1000x de stemwijzer doorlopen, maar alleen de eerste poging telt mee.

Ik zal dus nooit gaan inloggen om een stemwijzer in te vullen.

@thijsguelen22 zorg er ook voor dat je in een privacy statement duidelijk omschrijft wát je bij houdt, waarom en hoe lang. Politieke voorkeur is een bijzonder persoonsgegeven waar je heel erg voorzichtig mee om moet gaan. Nogmaals, hoe minder je op slaat des te beter (en dus veiliger) het is.

Dat mensen de wijzer meerdere keren in kunnen vullen is waar maar ik zou me daar niet echt zorgen over maken. Je bouwt geen voorspeller van de uitslag maar een stemwijzer. Om een betrouwbare uitslag te gaan voorspellen op basis van die gegevens zal je op allerlei manieren een weging moeten maken en dat gaat echt veel te ver.

[ Voor 6% gewijzigd door emnich op 17-01-2018 13:58 ]

[McKaamos]

P_Tingen schreef op woensdag 17 januari 2018 @ 13:52:
[...]

En aan de aard van de partij. Stel dat er lokaal een 80+partij is. Het is niet onredelijk om aan te nemen dat 80+'ers minder vaak op internet zitten en dus minder vaak jouw stemwijzer zullen invullen. Gevolg: voorspelling voor 80+ was 0%, bij verkiezingen ineens X%

[...]

Dan moeten de gebruikers dat wel vertrouwen. Persoonlijk zou ik me dan al op mijn achterhoofd krabben wanneer ik me moet aanmelden voor een anoniem stemadvies.

Misschien is het dan beter om op een andere manier een fingerprint samen te stellen van de bezoeker aan de hand van browsergegevens en dat op te slaan icm 'stemwijzer doorlopen = true'

Ja, daar is natuurlijk ook wat voor te zeggen.
Je zal dan moeten vertrouwen dat de betreffende site geen informatie opslaat, afgezien van je Oath userid oid, zonder dat te koppelen aan een daadwerkelijk resultaat.

Een fingerprint samenstellen is een optie, maar om dat goed sluitend te maken is pittig.
Koekjes achterlaten is niet heel betrouwbaar.

[Stoelpoot]

Oke, dat zijn logische redenen. Maar je wilt dus eigenlijk geen persoonsgegevens opslaan, maar een aan/uit vlaggetje of de stemwijzer al eens is ingevuld?

In dat geval mogelijk een sterke cryptografische hash van het IP address? Niet herleidbaar, wel verifieerbaar. Uiteraard te omzeilen, maar hoe vaak is dat te omzeilen dat het een verschil zal maken?

Mogelijk ook IP adres van te voren scannen op afkomst zodat er geen buitenlandse VPN servers worden meegenomen in de telling (maar wel de pagina te zien krijgen zodat ze denken dat het effect heeft, dat geld ook voor de IP hash).

[McKaamos]

Stoelpoot schreef op woensdag 17 januari 2018 @ 14:13:
Oke, dat zijn logische redenen. Maar je wilt dus eigenlijk geen persoonsgegevens opslaan, maar een aan/uit vlaggetje of de stemwijzer al eens is ingevuld?

In dat geval mogelijk een sterke cryptografische hash van het IP address? Niet herleidbaar, wel verifieerbaar. Uiteraard te omzeilen, maar hoe vaak is dat te omzeilen dat het een verschil zal maken?

Mogelijk ook IP adres van te voren scannen op afkomst zodat er geen buitenlandse VPN servers worden meegenomen in de telling (maar wel de pagina te zien krijgen zodat ze denken dat het effect heeft, dat geld ook voor de IP hash).

Ahh yes, een GeoIP scan. Dat is een goeie.

[thijsguelen22]

Stoelpoot schreef op woensdag 17 januari 2018 @ 14:13:
Oke, dat zijn logische redenen. Maar je wilt dus eigenlijk geen persoonsgegevens opslaan, maar een aan/uit vlaggetje of de stemwijzer al eens is ingevuld?

In dat geval mogelijk een sterke cryptografische hash van het IP address? Niet herleidbaar, wel verifieerbaar. Uiteraard te omzeilen, maar hoe vaak is dat te omzeilen dat het een verschil zal maken?

Mogelijk ook IP adres van te voren scannen op afkomst zodat er geen buitenlandse VPN servers worden meegenomen in de telling (maar wel de pagina te zien krijgen zodat ze denken dat het effect heeft, dat geld ook voor de IP hash).

Nee, geen persoonsgegevens. Wel wat het persoon in kwestie ingevuld heeft. Bijkomend is inderdaad dat je het ip adres (of een hash ervan) bij wilt houden om tegen te gaan dat het persoon niet meerdere malen de stemwijzer invult.

Wat daar wel bij komt: hoe bepaal je dat vanaf één ip een stemwijzer twee keer (bijna) hetzelfde is ingevuld? Je kunt niet een resultaat weglaten van één hetzelfde ip puur omdat Theo en Beppie beide bijna hetzelfde denken. Maar goed, dan kun je inderdaad werken met cookies e.d.

[Stoelpoot]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 14:15:
[...]


Nee, geen persoonsgegevens. Wel wat het persoon in kwestie ingevuld heeft. Bijkomend is inderdaad dat je het ip adres (of een hash ervan) bij wilt houden om tegen te gaan dat het persoon niet meerdere malen de stemwijzer invult.

Wat daar wel bij komt: hoe bepaal je dat vanaf één ip een stemwijzer twee keer (bijna) hetzelfde is ingevuld? Je kunt niet een resultaat weglaten van één hetzelfde ip puur omdat Theo en Beppie beide bijna hetzelfde denken. Maar goed, dan kun je inderdaad werken met cookies e.d.

Iets wat me opvalt: Geen persoonsgegevens, maar wel direct aan een IP Adres denken met erachter de kanttekening over een hash. Een IP adres is een persoonsgegeven. Dat sla je dus niet raw op tenzij je het echt nodig hebt voor identificatie.

Hoe vaak verwacht je meerdere personen per IP Adres te krijgen, dat je die er niet snel en vlug uit zou willen filteren?

[emnich]

Ik vul een stemwijzer heel vaak meerdere keren in en binnen mijn huishouden zal het nog wel vaker gebeuren.

Ook een hash van een IP kan een persoonsgegeven zijn. Het blijft herleidbaar tot een IP adres. Tenzij je het dagelijks hashed met een andere (random) salt en de bijbehorende salt weg gooit zodat je het nooit meer kan herleiden.

[McKaamos]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 14:15:
[...]


Nee, geen persoonsgegevens. Wel wat het persoon in kwestie ingevuld heeft. Bijkomend is inderdaad dat je het ip adres (of een hash ervan) bij wilt houden om tegen te gaan dat het persoon niet meerdere malen de stemwijzer invult.

Wat daar wel bij komt: hoe bepaal je dat vanaf één ip een stemwijzer twee keer (bijna) hetzelfde is ingevuld? Je kunt niet een resultaat weglaten van één hetzelfde ip puur omdat Theo en Beppie beide bijna hetzelfde denken. Maar goed, dan kun je inderdaad werken met cookies e.d.

IP adres alleen is ook geen goede check.
Daar moet nog iets bij, bijvoorbeeld de identificatie van een webbrowser (de zogeheten User Agent String).
Als je die informatie hasht, is dat niet omkeerbaar (of nou ja, extreem moeilijk, dat kost je jaren), maar wel herhaalbaar (makkelijk om een hash te maken, moeilijk om te decoderen)
Je zou dan zelfs het resultaat kunnen koppelen aan die hash en het nogsteeds anoniem kunnen noemen. Dat is technisch misschien een beetje op het randje lopen, maar het is interpreteerbaar als anoniem. (c.q. je kan niet één persoon aanwijzen)

[P_Tingen]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 14:15:
[...]
Wat daar wel bij komt: hoe bepaal je dat vanaf één ip een stemwijzer twee keer (bijna) hetzelfde is ingevuld? Je kunt niet een resultaat weglaten van één hetzelfde ip puur omdat Theo en Beppie beide bijna hetzelfde denken. Maar goed, dan kun je inderdaad werken met cookies e.d.

Ik denk dat je dit wel moet doen omdat je simpelweg geen fatsoenlijk alternatief hebt. In laten loggen met oAuth gaan Theo en Beppie ook niet afzonderlijk doen dus zullen ze dan ook dubbel geteld worden. Je zult toch moeten accepteren dat het een peiling is en dat het dus nooit nauwkeurig zal zijn.

Daarnaast: wat @emnich zegt geldt ook voor mij; ik vul ook een stemwijzer vaak meerdere keren in.

[emnich]

McKaamos schreef op woensdag 17 januari 2018 @ 14:22:
[...]

IP adres alleen is ook geen goede check.
Daar moet nog iets bij, bijvoorbeeld de identificatie van een webbrowser (de zogeheten User Agent String).
Als je die informatie hasht, is dat niet omkeerbaar (of nou ja, extreem moeilijk, dat kost je jaren), maar wel herhaalbaar (makkelijk om een hash te maken, moeilijk om te decoderen)
Je zou dan zelfs het resultaat kunnen koppelen aan die hash en het nogsteeds anoniem kunnen noemen. Dat is technisch misschien een beetje op het randje lopen, maar het is interpreteerbaar als anoniem. (c.q. je kan niet één persoon aanwijzen)

Natuurlijk wel. Zodra die persoon op een door jou beheerde website komt, weet je precies wat de politieke voorkeur van die bezoeker is. Het blijft een persoonsgegeven. Sterker nog, door de user agent mee te nemen maak je het alleen maar nog specifieker.

[thijsguelen22]

Stoelpoot schreef op woensdag 17 januari 2018 @ 14:19:
[...]


Iets wat me opvalt: Geen persoonsgegevens, maar wel direct aan een IP Adres denken met erachter de kanttekening over een hash. Een IP adres is een persoonsgegeven. Dat sla je dus niet raw op tenzij je het echt nodig hebt voor identificatie.

Hoe vaak verwacht je meerdere personen per IP Adres te krijgen, dat je die er niet snel en vlug uit zou willen filteren?

Tja, ik kan het natuurlijk niet bewijzen. Ik heb geen bewijsmateriaal.
Maar de huidige omroep waar ik bij zit is onlangs (december) aangewezen als de nieuwe omroep. Er is veel heisa en gedonder geweest toen de gemeente bekend maakte niet meer met de vorige omroep in zee te willen. De ouds bestuursleden zitten namelijk boven op ons, en hebben dan ook zo hun uitlatingen op facebook.

Ik wil er voor waken dat de ouds (bestuurs)leden hiermee aan de haal gaan. Natuurlijk ook omdat je niet wilt dat de gloednieuwe omroep bestempeld wordt als slordig en erg onzorgvuldig, maar ook omdat deze mensen binnen hun eigen fantasie (wij zijn slachtoffer) erg ver gaan en bijna hun mening opdrukken.

[emnich]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 14:25:
[...]


Tja, ik kan het natuurlijk niet bewijzen. Ik heb geen bewijsmateriaal.
Maar de huidige omroep waar ik bij zit is onlangs (december) aangewezen als de nieuwe omroep. Er is veel heisa en gedonder geweest toen de gemeente bekend maakte niet meer met de vorige omroep in zee te willen. De ouds bestuursleden zitten namelijk boven op ons, en hebben dan ook zo hun uitlatingen op facebook.

Ik wil er voor waken dat de ouds (bestuurs)leden hiermee aan de haal gaan. Natuurlijk ook omdat je niet wilt dat de gloednieuwe omroep bestempeld wordt als slordig en erg onzorgvuldig, maar ook omdat deze mensen binnen hun eigen fantasie (wij zijn slachtoffer) erg ver gaan en bijna hun mening opdrukken.

Dus moet je duidelijk uitleggen dat je de privacy van je bezoekers veel belangrijker vindt dan een betrouwbare voorspelling doen van de uitslag. Als jij een stemwijzer gaat vermommen als opiniepeiling dan krijg je hoe dan ook gezeik.

[Tjolk]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:49:
Het doel van het opslaan in om een peiling te kunnen maken van wat het volk straks gaat stemmen. Bestuur heeft aangegeven dat ze die data mee willen nemen naar een debat.

Dan ben je dus bezig met een peiling. Bij een stemwijzer verwacht ik (als burger) niet dat mijn anonieme gegevens worden opgeslagen. Je zult dit dus sowieso duidelijk kenbaar moeten maken:

"Indien u deze stemwijzer invult worden de resultaten gebruikt voor het opstellen van een peiling"

Dat sneaky doen geeft de burger weinig vertrouwen.

Verder vind ik het laakbaar dat een gemeente een dergelijke opdracht waar privacygevoelige data verwerkt en opgeslagen wordt aan een student met naar eigen zeggen "redelijke ervaring" geven. NOFI, maar dat is vragen om problemen. Jij gaat je methodes nu van internet en Tweakers halen en dat naar ongetwijfeld beste eer en geweten toepassen, maar als je met zulke gegevens werkt moet dat gebeuren door iemand die beslagen ten ijs komt. Niet door iemand die eerst nog eens gaat kijken wat voor ijzers hij nou eigenlijk nodig heeft.

Mijn welgemeende advies: sla de resultaten niet op. Of hooguit volledig geanonimiseerde tellertjes: uitslag X is Y keer voorgekomen. Dat er dan wellicht een aantal trollen tussen zitten en de data waarschijnlijk toch sterk beïnvloed is door diverse factoren is niet jouw probleem als je dat van tevoren communiceert. Indien de gemeente per se een peiling wil doen moeten ze daarvoor bij een bureau zijn wat daarin gespecialiseerd is. En ja, dat kost meer dan een student.

[McKaamos]

emnich schreef op woensdag 17 januari 2018 @ 14:25:
[...]

Natuurlijk wel. Zodra die persoon op een door jou beheerde website komt, weet je precies wat de politieke voorkeur van die bezoeker is. Het blijft een persoonsgegeven. Sterker nog, door de user agent mee te nemen maak je het alleen maar nog specifieker.

Hoe dan? Hoe herleid je uit een hash wie wie is?
Misschien over 10 jaar en investering van heul veul geld voor apparatuur, maar niet zolang het nog relevant is.
Daarbij zal je dan ook nog terug moeten zien te vinden welk adres dat IP bij hoorde. ISP's hebben daar allicht informatie over, maar die bewaren ze niet zo lang.
En je useragent verandert bij elke software update (dus elke paar weken), dus je moet ook nog zien te bepalen of iemand softwarepakket X met versienummer Y gebruikte.

Alleen door het apparaat van de betreffende persoon te bemachtigen en dezelfde internet verbinding te gebruiken, kan je de hash reproduceren.
En dan moet je de database met resultaten nog zien te jatten.

Edit: en uit een IP adres + useragent haal je alleen maar welk apparaat via welke internet verbinding. Niet 'wie'. Alleen de "met wat" en "vanaf waar".

[ Voor 7% gewijzigd door McKaamos op 17-01-2018 14:47 ]

[Tjolk]

McKaamos schreef op woensdag 17 januari 2018 @ 14:43:
[...]

Hoe dan? Hoe herleid je uit een hash wie wie is?

De hash is het resultaat van een verzameling gegevens die jij afleidt. Die gegevens kun je op een willekeurige andere website (met bijvoorbeeld iets onschuldigs als een contactformulier) ook opvragen en hashen. Zelfde resultaat == zelfde persoon.
Ga dat op 5 lokale websites doen over 5 verschillende onderwerpen en je hebt al een aardig profiel.

[emnich]

@McKaamos TS (en dus de omroep) weet de voorkeur van de gebruiker, óók als die later op een ander deel van de site terecht komt omdat je die hash opnieuw kan berekenen.

Je voorkomt er wel mee dat iemand die alleen de database bemachtigd er iets mee kan maar dan kan je ook de gegevens encrypted op slaan. Er mag gewoon nooit een koppeling zijn tussen de ingevulde antwoorden (of het advies) en de pc/persoon/verbinding van de gebruiker. Sla het volledig annoniem op, je haalt je allerlei shit op de hals terwijl dat totaal onnodig is.

Met de huidige opzet kan je nooit een echt betrouwbare uitslag gaan voorspellen en je moet je daar dus ook helemaal niet aan gaan wagen.

McKaamos schreef op woensdag 17 januari 2018 @ 14:43:


Edit: en uit een IP adres + useragent haal je alleen maar welk apparaat via welke internet verbinding. Niet 'wie'. Alleen de "met wat" en "vanaf waar".

Maar dát is voor de wet een persoonsgegeven. We kunnen er over discussiëren of jij en ik dat ook vinden maar dat doet er niet veel toe. Wettelijk is een IP adres een persoonsgegeven die je met een user agent nog iets specifieker maakt. Daarbij is de politieke voorkeur een bijzonder persoonsgegeven waar je nog voorzichtiger mee moet zijn.

[ Voor 31% gewijzigd door emnich op 17-01-2018 14:52 ]

[McKaamos]

@Ger en @emnich , Ja daar heb je wel gelijk in.
En ja, ik ben het er mee eens dat het volledig anoniem moet.

Echter, zodra je wil gaan beperken dat er meermaals gebruik wordt gemaakt van het systeem om zo de resultaten te manipuleren, zal je toch iets moeten doen.
Wat ik al eerder aanhaalde, is een vlaggetje zetten en simpelweg resultaten optellen zonder de infividuele resultaten op te slaan, is dan een goede kandidaat.

Het enige wat je dan weet, is dat iemand het systeem heeft gebruikt. Maar dat kan je ook herleiden uit serverlogs e.d. en is daarmee dus ook niet een significant gegeven.

[emnich]

@McKaamos Maar waarom wil je dat gaan beperken. Zoals gezegd, ik vul het vaak (serieus) meerdere keren in. Welke neem je dan mee en waarom precies die? En wat doe je met het IP adres van een school, kantoor, huis met meerdere mensen.

En hoe ga je je resultaten wegen. Immers als een paar klassen dit als opdracht moeten invullen dan wordt je uitslag al behoorlijk beïnvloed.

Je moet, m.i. dus helemaal geen beveiliging er op zetten omdat je sowieso geen betrouwbare voorspelling er mee kan doen.

Wat je zou kunnen doen is in een aparte tabel bijhouden welk IP adres hoe vaak gestemd heeft. Zorg ervoor dat er dan geen timestamp bij staat en sla het IP adres gehashed of encrypted op. Als er dan 1.000 stemwijzers door één IP adres gedaan is kan je in elk geval zeggen dat je resultaten zeer waarschijnlijk erg onbetrouwbaar zijn.

[McKaamos]

emnich schreef op woensdag 17 januari 2018 @ 15:00:
@McKaamos Maar waarom wil je dat gaan beperken. Zoals gezegd, ik vul het vaak (serieus) meerdere keren in. Welke neem je dan mee en waarom precies die? En wat doe je met het IP adres van een school, kantoor, huis met meerdere mensen.

En hoe ga je je resultaten wegen. Immers als een paar klassen dit als opdracht moeten invullen dan wordt je uitslag al behoorlijk beïnvloed.

Je moet, m.i. dus helemaal geen beveiliging er op zetten omdat je sowieso geen betrouwbare voorspelling er mee kan doen.

Wat je zou kunnen doen is in een aparte tabel bijhouden welk IP adres hoe vaak gestemd heeft. Zorg ervoor dat er dan geen timestamp bij staat en sla het IP adres gehashed of encrypted op. Als er dan 1.000 stemwijzers door één IP adres gedaan is kan je in elk geval zeggen dat je resultaten zeer waarschijnlijk erg onbetrouwbaar zijn.

Hmm, zo kan je het natuurlijk ook benaderen.
Ik zat een beetje vast in het willen hebben van solide statistieken.

Om daar toch een beetje aan vast te houden, wat voor creatiefs kan je doen om de foutmarge relatief klein te houden?

Wat als je de resultaten elke nacht op een vast tijdstip uit de database trekt, minus de IP hashes? (hashes, want encrypted is omkeerbaar)
Dan heb je een lijst getallen zonder terugverwijzing naar wie het was.
Dat reken je om naar percentages en benadeelt de grootste partij (volgens resultaten) het hardste op basis daar van.

Die dagelijkse stats leg je dan weer naast elkaar om daar een gemiddelde uit te berekenen, en eventuele groei per dag (of week bijvoorbeeld) te plotten.

En natuurlijk knikker je elke dag je resultaten en IPhash-teller weg om elke dag met een schone lei te beginnen.

[ Voor 3% gewijzigd door McKaamos op 17-01-2018 15:43 ]

[emnich]

McKaamos schreef op woensdag 17 januari 2018 @ 15:42:
[...]

Hmm, zo kan je het natuurlijk ook benaderen.
Ik zat een beetje vast in het willen hebben van solide statistieken.

Om daar toch een beetje aan vast te houden, wat voor creatiefs kan je doen om de foutmarge relatief klein te houden?

Wat als je de resultaten elke nacht op een vast tijdstip uit de database trekt, minus de IP hashes? (hashes, want encrypted is omkeerbaar)
Dan heb je een lijst getallen zonder terugverwijzing naar wie het was.
Dat reken je om naar percentages en benadeelt de grootste partij (volgens resultaten) het hardste op basis daar van.

Die dagelijkse stats leg je dan weer naast elkaar om daar een gemiddelde uit te berekenen, en eventuele groei per dag (of week bijvoorbeeld) te plotten.

En natuurlijk knikker je elke dag je resultaten en IPhash-teller weg om elke dag met een schone lei te beginnen.

Je zou per sessie een random hash kunnen genereren en die opslaan bij de uitslag. Na het beëindigen van de sessie tel je alle uitslagen van die sessie en slaat een percentage op van de uitslag.

Dus als in een sessie 1 stemwijzer is ingevuld dan krijgt die een weging van 100%. Als er in een sessie 3 keer iets in ingevuld dan krijgen die elk 25%.

Je uiteindelijke tabel laat dan iets zien als:
CDA 0.333
VVD 0.333
D66 0.333
of
Groen Links 1

Na het beëindigen van de sessie en het aggregeren, hash je de sessieID opnieuw met een random salt. Op die manier kan je nooit meer achterhalen wie dat heeft ingevoerd maar zie je wel dat het bij elkaar hoort.

Uiteraard ga je daar geen moedwillige beïnvloeding mee tegen omdat het enige wat nodig is, is het vernieuwen van de sessie. Er zijn zo veel manieren om die uitslag te beïnvloeden dat je je daar nooit echt goed tegen kan wapenen (met de huidige wetgeving en de scope van dit project).

[P_Tingen]

Ik denk eerlijk gezegd dat je moet oppassen dat je geen gedrocht gaat bouwen voor iets wat inherent onvoorspelbaar is.

Het gevaar is dat je constructies bouwt waar je U tegen zegt die uiteindelijk net zo onbetrouwbaar zijn als wanneer je domweg alle resultaten zonder verdere beperking zou hebben meegenomen. Misschien moet je accepteren dat het geven van de verdeling van de stemadviezen geen voorspelling is. En misschien is het handig om dat op je site ook zo te vermelden, dus iets als: "Bekijk de verdeling van uitgebrachte stemadviezen hier: <klik>"

[Giesber]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:52:
[...]
Ik ga in ieder geval een functie schrijven die code afvangt.

Ik ken PHP en C# niet goed, maar functies die code afvangen gaan al bestaan in die talen. Dat zijn doorgaans geen zaken die je gewoon kan gebruiken. Sterker nog, dat zijn functies die in de loop der jaren door veel mensen zijn verfijnd, dus de kans dat jij (of ik, of eender welke programmeur) dat beter kan is nogal klein.

Dus gebruik voor deze zaken (of andere dingen waarvan je vermoed dat veel programmeurs dat nodig hebben) zo veel mogelijk standaard functionaliteit.

[Verwijderd]

Ik zou gewoon de IP-nummers hashen, en van varianten die meer dan x (2? 3? Hoeveel stemmen per huishouden?) keer voorkomen in eerste instantie alleen de eerste meetellen.

De kans dat dat er veel zijn lijkt me niet zo groot, dus die kun je handmatig controleren, en als het een rDNS oplevert die de aantallen verklaart, dan kun je ze alsnog allemaal meetellen.

[DJMaze]

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:05:
Wat heb ik nodig om dit veilig te laten lopen? De stemwijzer zelf draait op mijn eigen webserver bij Versio

Versio voldoet toch niet aan ISO 27001 ?
Dan moet je idd zorgen dat je niks opslaat (dus ook geen e-mailadres), dan zit je daar safe.

Er is reeds genoemd dat men kan inloggen met OAuth (Facebook) of OpenID Connect (google), maar zorg dan dat je de 'ID' die je terug krijgt ook even sha512 hasht.

[ Voor 32% gewijzigd door DJMaze op 18-01-2018 23:10 ]

[farlane]

Verwijderd schreef op donderdag 18 januari 2018 @ 10:47:
Ik zou gewoon de IP-nummers hashen,

Wat zou dat moeten opleveren?

[Verwijderd]

farlane schreef op donderdag 18 januari 2018 @ 23:39:
Wat zou dat moeten opleveren?

Dat je geen persoonsgegevens opslaat?

[emnich]

Verwijderd schreef op vrijdag 19 januari 2018 @ 01:05:
[...]

Dat je geen persoonsgegevens opslaat?

Met hashen blijft het een persoonsgegeven, zie ook de discussie eerder in deze thread.

Voor meer informatie:
https://blog.iusmentis.co...dressen-persoonsgegevens/

[thijsguelen22]

Iedereen bedankt voor de reacties.

Ik heb de kwestie ook voorgelegd bij de andere ICT'er binnen de omroep, en ook hij geeft aan dat het onverstandig is om een systeem te bouwen dat de stemgegevens opslaat.

We hebben er nu voor gekozen enkel IP adressen te loggen in de database, en of ze de stemwijzer afgemaakt hebben of niet. Meer dan dat ook niet. Dit om aan te kunnen geven hoe vaak de stemwijzer in ieder geval gebruikt is.

We hebben bij het bestuur aangekaart dat het te kortdag is om het gewenste systeem te realiseren, en dat ik mijzelf niet capabel genoeg bevind om mijn vingers hieraan te branden (natuurlijk heb ik ook mijn eigen belang aangegeven dat ik straks niet verantwoordelijk gesteld wil worden voor een mogelijk lek).

Gelukkig is het bestuur niet oud en stug (wat je zo wel eens hoor bij lokale omroepen), dus het bestuur had vrede met het besluit.

Uiteraard gaat alles alsnog via HTTPS lopen, en wordt alles dichtgetimmerd om afluisteren van de verbinding, SQL injections e.d tegen te gaan.

Dank voor de tips iedereen!

[Verwijderd]

emnich schreef op vrijdag 19 januari 2018 @ 07:42:
Met hashen blijft het een persoonsgegeven, zie ook de discussie eerder in deze thread.

Ah, die had ik gemist - dank!

Maar het kan in dit geval dus wel een oplossing zijn: "Er is die uitzondering voor de eigen dringende noodzaak, en daarbij moet je een afweging maken of de privacy van de betrokkenen zwaarder weegt of niet dan jouw noodzaak. Onderdeel van die afweging is hoe makkelijk of moeilijk het is om mensen te identificeren (direct of indirect)."

En TS blijkt van plan de IP-nummers inderdaad te gebruiken, ongehasht zelfs.

[HansvDr]

Waarschijnlijk bekijken een paar mensen die lokale stemwijzer. Ik zou er niet te veel van verwachten en ook niks doen met ip logging, dan vullen ze hem maar vaker in.

Gewoon de stemwijzer niets laten opslaan, niet te veel tijd in stoppen en hopen dat er meer mensen dan 10 dat ding gaan raadplegen.

[emnich]

Verwijderd schreef op vrijdag 19 januari 2018 @ 11:13:
[...]

Ah, die had ik gemist - dank!

Maar het kan in dit geval dus wel een oplossing zijn: "Er is die uitzondering voor de eigen dringende noodzaak, en daarbij moet je een afweging maken of de privacy van de betrokkenen zwaarder weegt of niet dan jouw noodzaak. Onderdeel van die afweging is hoe makkelijk of moeilijk het is om mensen te identificeren (direct of indirect)."

En TS blijkt van plan de IP-nummers inderdaad te gebruiken, ongehasht zelfs.

Maar niet gekoppeld aan de politieke voorkeur! Politieke voorkeur is een bijzonder persoonsgegeven die je nooit mag verwerken tenzij de wet daar expliciet een uitzondering voor maakt.

Voor zover ik het kan beoordelen slaat TS alleen het IP adres op en of de stemwijzer is afgemaakt. Als daar geen timestamp (of auto id!) bij staat en ook bij het antwoord van de stemwijzer geen timestamp of (auto id) dan is er niets aan de hand

[Verwijderd]

emnich schreef op vrijdag 19 januari 2018 @ 11:30:
Maar niet gekoppeld aan de politieke voorkeur!

Ik had het begin gevolgd (voor jouw eerste post), en de discussie daarna gemist...my bad!

[thijsguelen22]

emnich schreef op vrijdag 19 januari 2018 @ 11:30:
[...]

Maar niet gekoppeld aan de politieke voorkeur! Politieke voorkeur is een bijzonder persoonsgegeven die je nooit mag verwerken tenzij de wet daar expliciet een uitzondering voor maakt.

Voor zover ik het kan beoordelen slaat TS alleen het IP adres op en of de stemwijzer is afgemaakt. Als daar geen timestamp (of auto id!) bij staat en ook bij het antwoord van de stemwijzer geen timestamp of (auto id) dan is er niets aan de hand

Vergeten te vernoemen Ik ga de IP adressen wel hashen. We slaan alleen die hash, een timestamp en boolean waarin staat of de stemwijzer is afgemaakt of niet op. Verder verwerken we dan ook helemaal niks. De uitkomst wordt niet bewaard.

[farlane]

Verwijderd schreef op vrijdag 19 januari 2018 @ 01:05:
[...]
Dat je geen persoonsgegevens opslaat?

Een hash van een ip adres is waarschijnlijk vrij makkelijk te herleiden naar het origineel.

[DJMaze]

farlane schreef op vrijdag 19 januari 2018 @ 11:36:
Een hash van een ip adres is waarschijnlijk vrij makkelijk te herleiden naar het origineel.

Als je een rainbow table maakt van 4294967296 addressen wel

Maar als je password_hash($_SERVER['REMOTE_ADDR']) gebruikt weer niet zo makkelijk, maar dan kan je weer niet controleren tenzij je alle DB records af gaat met password_verify().
Je kan dan een combi maken door de twee laatste int bytes van een IP op te slaan (dus: .255.255)

Iets doen met IP addressen is sowieso onhandig, zeker bij mensen die van IP kunnen wisselen (TOR, VPN, etc. etc.)

[ Voor 43% gewijzigd door DJMaze op 19-01-2018 11:51 ]

[ytterx]

DJMaze schreef op vrijdag 19 januari 2018 @ 11:45:
[...]

Als je een rainbow table maakt van 4294967296 addressen wel

Maar als je password_hash($_SERVER['REMOTE_ADDR']) gebruikt weer niet zo makkelijk, maar dan kan je weer niet controleren tenzij je alle DB records af gaat met password_verify().
Je kan dan een combi maken door de twee laatste int bytes van een IP op te slaan (dus: .255.255)

Iets doen met IP addressen is sowieso onhandig, zeker bij mensen die van IP kunnen wisselen (TOR, VPN, etc. etc.)

Daar heb je salts voor, heb jij niet zoveel aan jouw rainbow table..

Even terugkomend op:

thijsguelen22 schreef op woensdag 17 januari 2018 @ 13:39:
[...]
Ik neem aan dat hier van buitenaf niet een injectie plaats kan vinden toch? Er zit een check in die de radiobuttons uitleest (waarde 1, 2 of 3, die in die volgorde staan voor eens, oneens en geen mening). Als iemand bijvoorbeeld het cijfer 4 verstuurd, wordt dit automatisch "geen mening".

Waarom niet direct een ban? Iemand probeert verkeerde info in te vullen wat niet mogelijk moet zijn == hacker / script-kiddie in mijn opinie en hoort niet op je site..

[farlane]

ytterx schreef op vrijdag 19 januari 2018 @ 13:13:
[...]
Daar heb je salts voor, heb jij niet zoveel aan jouw rainbow table..

De salt moet je ook opslaan bij je gehashte IP.

Het gaat hier niet over kraken van een password, maar in hoeverre het opgeslagen ding een persoonsgegeven is. Een gehasht IP adress + salt is volgens mij dan nog immer een "persoonsgegeven".

[ytterx]

farlane schreef op vrijdag 19 januari 2018 @ 16:12:
[...]
Het gaat hier niet over kraken van een password, maar in hoeverre het opgeslagen ding een persoonsgegeven is. Een gehasht IP adress + salt is volgens mij dan nog immer een "persoonsgegeven".

Ik kan geen duidelijk artikel vinden of een gehashed IP nou wel of niet een persoonsgegeven is, een gehashed wachtwoord is dat echter niet volgens deze site: https://ictrecht.nl/2013/...chtwoord-persoonsgegeven/

Iemand die een bron heeft?

[emnich]

ytterx schreef op vrijdag 19 januari 2018 @ 16:22:
[...]

Ik kan geen duidelijk artikel vinden of een gehashed IP nou wel of niet een persoonsgegeven is, een gehashed wachtwoord is dat echter niet volgens deze site: https://ictrecht.nl/2013/...chtwoord-persoonsgegeven/

Iemand die een bron heeft?

emnich in "SSL en beveiliging voor lokale stemwijzer"

In principe is het een persoonsgegeven als het door iemand aan een persoon gelinkt kan worden.

[ytterx]

emnich schreef op vrijdag 19 januari 2018 @ 16:24:
[...]

emnich in "SSL en beveiliging voor lokale stemwijzer"

In principe is het een persoonsgegeven als het door iemand aan een persoon gelinkt kan worden.

Wat als je dus nadat je de stemwijzer sluit, de salts weg gooit? Dan kan het niet meer achterhaald worden. Je zit dan met de wet nog wel met de verwerking van persoonsgegevens, maar alleen tot het punt dat het niet meer nodig is (stemwijzer gesloten) hierdoor toch unieke resultaten, maar geen mogelijkheid tot identificatie.

Maar dit gaat wellicht wat verder wat de TS doet.

[Tjolk]

thijsguelen22 schreef op vrijdag 19 januari 2018 @ 10:28:

We hebben er nu voor gekozen enkel IP adressen te loggen in de database, en of ze de stemwijzer afgemaakt hebben of niet. Meer dan dat ook niet. Dit om aan te kunnen geven hoe vaak de stemwijzer in ieder geval gebruikt is.

Wat is dan de toegevoegde waarde van het IP adres opslaan?

Ga je scholen (die actuele verkiezingen en stemwijzers vaak verwerken in hun lessen) uitsluiten van je resultaten? Of bibliotheken/verzorgingstehuizen, etc?

Ik zou gewoon 2 tellertjes handhaven: stemwijzer gestart en stemwijzer compleet. Eventueel verder uitsplitsen naar iedere stap in de stemwijzer en naar het stemadvies, maar verder heb je echt geen meerwaarde van dat IP adres volgens mij.

[emnich]

ytterx schreef op vrijdag 19 januari 2018 @ 16:35:
[...]

Wat als je dus nadat je de stemwijzer sluit, de salts weg gooit? Dan kan het niet meer achterhaald worden. Je zit dan met de wet nog wel met de verwerking van persoonsgegevens, maar alleen tot het punt dat het niet meer nodig is (stemwijzer gesloten) hierdoor toch unieke resultaten, maar geen mogelijkheid tot identificatie.

Maar dit gaat wellicht wat verder wat de TS doet.

Dat is wat ik ook eerder voorstelde, bij het beëindigen van de sessie anonimiseer je alles. Ik denk dat je daarmee wel weg komt maar ik durf er geen geld op te zetten.

[Verwijderd]

Ger schreef op vrijdag 19 januari 2018 @ 16:35:
Wat is dan de toegevoegde waarde van het IP adres opslaan?

Nu niet echt meer iets - het oorspronkelijke plan was om de resultaten geanonymiseerd op te slaan, maar dat is inmiddels geschrapt.