Welke versleuteling database voor persoonsgegevens?

[ViNyL]

Op de site van ons bedrijf worden persoonsgegevens op geslagen in een database. Dit zijn bijvoorbeeld contactgegevens van mensen die een formulier invullen. Om de beveiliging aan te scherpen is alles recent onder de loep genomen. Ik ben bij de inrichting nooit betrokken geweest maar nu wel en ben het nodige aan het doornemen over hoe alles nu in elkaar zit. Het opslaan wordt al tot een minimum beperkt net als de periode waarin dit opgeslagen blijft.

Gegevens in de database worden nu wel versleuteld maar er wordt nergens specifiek gemeld hoe, behalve dat dit met Blowfish gebeurt. Ik vraag me af wat voor het versleutelen van persoonsgegevens de minimum eisen zijn. Is Bowfish daar goed genoeg voor? Ik lees enerzijds dat Blowfish nog wel voldoet, aan de andere kant lees ik dat de 64-bit block size achterhaald is en zelfs de bedenker zegt "Blowfish users are encouraged by Bruce Schneier, Blowfish's creator, to use the more modern and computationally efficient alternative Twofish.".

Is bv AES een beter alternatief of voldoet Blowfish nog?

[Barryvdh]

Het is wel echt voor encryptie, niet voor hashing he? Want bcrypt is afgeleid van blowfish, en wordt vaak gebruikt om wachtwoorden te hashen (dus one-way).

En als de auteur zelf al aanraadt om het niet meer te gebruiken, zou ik ook gewoon overstappen
Volgens mij is AES redelijk standaard tegenwoordig.

[ViNyL]

Het gaat om het coderen, er is een sleutel die apart opgeslagen wordt zodat het ook weer omgezet kan worden.

[DJMaze]

Blowfish is symmetrische encryptie, als de sleutel op straat ligt kan je encrypten en decrypten.
Als iemand de server hackt en naast de database dan ook de sleutel (in database of bestand) in handen heeft, ben je alsnog de pineut.

Met een openssl asymmetrische encryptie kan je data beter opslaan, maar waar laat je het wachtwoord van de private key?
Als je de data wil uitlezen heb je namelijk het private key wachtwoord nodig.
Je kan bijvoorbeeld zeggen dat elke computer/gebruiker die de data mag lezen een eigen sleutel heeft en dan met bijvoorbeeld openssl_seal() de data encrypten.
Vervolgens moet elke computer/gebruiker met zijn eigen privé sleutel + wachtwoord de data ontsleutelen.

Maar dit is allemaal afhankelijk van hoe jullie situatie is ingericht en wordt gebruikt.

[ Voor 4% gewijzigd door DJMaze op 09-02-2017 09:37 ]

[Bigs]

Rond Blowfish/Twofish hangt altijd een beetje een hobby sfeertje. Beter kun je een algemeen geaccepteerde standaard als AES gebruiken, daar zal geen audit problemen mee hebben.

Zoals DJMaze al aangeeft is je achterliggende methodiek echter nog veel belangrijker. Als je nu symmetrische versleuteling gebruikt met een wachtwoord dat in de code van je website staat dan bescherm je je eigenlijk alleen tegen diefstal van de database vanaf de database server (of van de hele database server). Het is echter veel waarschijnlijker dat data uitlekt via jullie website, dan via iemand die rechtstreeks de database server hackt (aannemende dat de databaseserver afdoende beveiligd is). Voorbeeld: iemand komt via een gesloten account bij een exportfunctie en downloadt een hele lijst met onversleutelde contactgegevens. Het voorbeeld hierboven met asymmetrische versleuteling en opslag van geheime sleutels per gebruiker helpt hierbij.

[ViNyL]

DJMaze schreef op woensdag 8 februari 2017 @ 10:56:
Blowfish is synchrone encryptie, als de sleutel op straat ligt kan je encrypten en decrypten.
Als iemand de server hackt en naast de database dan ook de sleutel (in database of bestand) in handen heeft, ben je alsnog de pineut.

Met een openssl asynchrone encryptie kan je data beter opslaan, maar waar laat je het wachtwoord van de private key?
Als je de data wil uitlezen heb je namelijk het private key wachtwoord nodig.
Je kan bijvoorbeeld zeggen dat elke computer/gebruiker die de data mag lezen een eigen sleutel heeft en dan met bijvoorbeeld openssl_seal() de data encrypten.
Vervolgens moet elke computer/gebruiker met zijn eigen privé sleutel + wachtwoord de data ontsleutelen.

Maar dit is allemaal afhankelijk van hoe jullie situatie is ingericht en wordt gebruikt.

Dit is eigenlijk in dit geval de mooiste/beste/veiligste oplossing voor dit geval. Zal eens kijken of ik daar een praktisch voorbeeld van kan vinden.

Bedankt voor de input!

[Haan]

E.e.a. is ook afhankelijk van de database, zou heeft MSSQL Server bijvoorbeeld column encryption

[Barryvdh]

ViNyL schreef op woensdag 8 februari 2017 @ 11:18:
[...]


Dit is eigenlijk in dit geval de mooiste/beste/veiligste oplossing voor dit geval. Zal eens kijken of ik daar een praktisch voorbeeld van kan vinden.

Bedankt voor de input!

Assymetrische encryptie is voornamelijk handig als je bepaalde data alleen door een bepaalde gebruiker wil laten uitlezen toch? Dus bijv chatberichten van User A naar User B encrypt je met de public keys van A + B, zodat alleen zij erbij kunnen.

Maar als je een admin panel hebt waarbij verschillende managers/gebruikers de data moeten kunnen bekijken, is dat niet zo praktisch toch. Of je moet elke keer als er een user bijkomt/weg gaat alle data opnieuw sealen met de nieuwe keys.
Daarbij, waar sla je de private keys van die gebruikers op? Ga je de data client-side decrypten in je browser? Of alsnog ergens opslaan (en bijv. laten decrypten met passphrase). Volgens mij is dat allemaal niet even praktisch. (Want als die uitlekt, heb je hetzelfde als met symmetrische encryptie natuurlijk).

En de kans dat je decryption key uitlekt is in principe kleiner dan dat je database lekt (mysqldumps, sql injectie, wachtwoord van phpmyadmin gelekt?), dus vraag of je je niet veel problemen op de hals haalt met assymetrische decryptie voor relatief weinig voordeel.

Maargoed, dat alles hangt er weer vanaf hoe 'prive' het is. Als het gaat om contactaanvragen om langs te komen in de winkel, of creditcard/bsn nummers..

[FrankHe]

Een focus op uitsluitend versleuteling van de database heeft voor mijn gevoel weinig zin. Ik zou me eerder druk maken over beveiliging van de webserver.

Hoe is de input sanitation, worden alle velden en waardes netjes opgeschoond voordat de SQL query naar de database wordt afgevuurd? Software updates, zijn alle modules up to date.

Hoe is de netwerkbeveiliging bij de webserver, wat zijn de instellingen van de firewall. Kunnen de rules nog strakker worden gemaakt, alleen poorten open die daadwerkelijk nodig zijn, white listing van IP-adressen die toegang mogen hebben tot SSH en dergelijke. Database poorten alleen beschikbaar maken lokaal, wanneer via SSH tunnel of VPN verbonden met de webserver. Bouw een muur, graaf een gracht en bouw nog een muur. Dan maak je het heel lastig om binnen te komen.

Wat rest is een lek van binnenuit. Zorg voor duidelijk procedures rondom toegang tot de database en verwerking van gegevens uit de database. Monitor netwerkverkeer, denk na over het scannen van e-mailbijlagen, het versleutelen van hardeschijven op desktop en laptop. Het verbieden van USB sticks in het gebouw.

Negen van de tien datalekken zijn toe te schrijven aan menselijk falen. En natuurlijk zet je logs aan en analyseer je log bestanden regelmatig.

[ Voor 2% gewijzigd door FrankHe op 08-02-2017 14:20 . Reden: logs ]

[DJMaze]

Barryvdh schreef op woensdag 8 februari 2017 @ 13:11:
Maar als je een admin panel hebt waarbij verschillende managers/gebruikers de data moeten kunnen bekijken, is dat niet zo praktisch toch. Of je moet elke keer als er een user bijkomt/weg gaat alle data opnieuw sealen met de nieuwe keys.

Nee, nee, nee.

The key is encrypted with each of the public keys associated with the identifiers in pub_key_ids and each encrypted key is returned in env_keys.

Je hoeft alleen met 1 private key de "key" te decrypten en dan met de nieuwe gebruiker zijn public key de "key" weer te encrypten.
Hier zit het data lek als je dit door de website laat doen, maar je kan dit net zo makkelijk afvangen door het een gebruiker te laten doen (zie mijn eerste post).

Op deze manier werken ook de "cloud" storage/password managers.
Als je daar het wachtwoord wijzigd re-encrypt je de seal "key"

Voorbeeld
encrypt:

code:

generate pub/priv key pair
encrypt data with pub key
encrypt priv key with public keys
return array(
    'encrypted priv key 1', // public key 1
    'encrypted priv key 2', // public key 2
    .....
)

decrypt:

code:

decrypt 'encrypted priv key 1' with private key 1 or 'encrypted priv key 2' with private key 2 or ....
decrypt data with decrypted priv key
return data

add public key:

code:

decrypt 'encrypted priv key 1' with private key 1 or 'encrypted priv key 2' with private key 2 or ....
encrypt priv key with new public key
return encrypted priv key

Je kan het ook iets simpeler doen:

1. Generate general pub/priv key pair
2. Encrypt general private key with public keys
3. Encrypt any data with general public key
4. Decrypt any data with general private key (decrypt general private key with user private key)

Als er een gebruiker bij komt hoef je dan alleen die ene general private key opnieuw te encrypten.

[ Voor 33% gewijzigd door DJMaze op 09-02-2017 09:42 ]

[Barryvdh]

DJMaze schreef op woensdag 8 februari 2017 @ 15:53:
[...]

Nee, nee, nee.

[...]

Je hoeft alleen met 1 private key de "key" te decrypten en dan met de nieuwe gebruiker zij public key de "key" weer te encrypten.
Hier zit het data lek als je dit door de website laat doen, maar je kan dit net zo makkelijk afvangen door het een gebruiker te laten doen (zie mijn eerste post).

Op deze manier werken ook de "cloud" storage/password managers.
Als je daar het wachtwoord wijzigd re-encrypt je de seal "key"

Oh zo, je versleuteld de encryptie key (bijv de AES symmetrische key) met de public keys en gebruikt dezelfde key voor alle data. Als iedereen bij dezelfde data kan, kan dat ook inderdaad.

Maar dan zou je dus je private key lokaal opslaan, wat voor veel toepassingen niet zo praktisch is toch (afhankelijk van de situatie).

[DJMaze]

Juist, afhankelijk van de situatie.
Je zou dit zelfs met de browser HTML5 Web Cryptography API kunnen doen als de kennis er is.

[Hydra]

Hoe is je systeem gehost trouwens? Als het een VPS is kan een admin natuurlijk vrij simpel je VM pauzeren en de sleutel uit 't geheugen lezen. Sowieso is encryptie niet het grootste probleem (AES is veilig genoeg); de vraag is waar sla je je sleutel op.

[DJMaze]

Hydra schreef op woensdag 8 februari 2017 @ 17:02:
Als het een VPS is kan een admin natuurlijk vrij simpel je VM pauzeren en de sleutel uit 't geheugen lezen.

Als ik Wireshark op de LAN kabel plug kan ik alles lezen!
En daarom hebben een aantal providers:

• PCI/DSS
• ISO 27001
• ISO 9001
• NEN 7510 (specifiek voor de zorgsector voldoen aan de security standaarden voor informatiebeveiliging die nodig zijn voor het Elektronisch Patiënten Dossier)
• accreditatie van ISAE 3402 type 1, een internationaal erkende assurance standaard (financiële markt).
• etc.

En alle andere hosting boeren moet je gewoon links laten liggen.

Been there, done that.
Gelukkig mag ik nu na € 10.000 lichter wel alles verwerken

Ik verwerk credit cards voor online boekingen bij hotels, campings, boten, etc. en die data staat dus in een seal (key per klant natuurlijk).
De private key staat alleen bij de klant en eentje lokaal bij mij.
Ik kan dan de key van de klant intrekken (stel klant PC is gestolen) of mijn eigen (bij inbraak).

[ Voor 18% gewijzigd door DJMaze op 08-02-2017 17:23 ]

[DiedX]

Mag ik vragen wáárom je gebruikersgegevens op je site wil houden? Kan je toch beter crypten, mailen en dan moeve met die data?

[ Voor 0% gewijzigd door DiedX op 08-02-2017 19:23 . Reden: Typo ]

[DJMaze]

DiedX schreef op woensdag 8 februari 2017 @ 17:20:
Kan je toch beter crypte, mailen en dan moeve met die data?

Hoe leg jij aan de eigenaar uit hoe SMIME of PGP werkt?

[DiedX]

DJMaze schreef op woensdag 8 februari 2017 @ 17:25:
[...]

Hoe leg jij aan de eigenaar uit hoe SMIME of PGP werkt?

Wie zegt dat de eigenaar dat moet doen?

[qless]

DJMaze schreef op woensdag 8 februari 2017 @ 17:11:
[...]

Als ik Wireshark op de LAN kabel plug kan ik alles lezen!
En daarom hebben een aantal providers:

Niet bij SSH/HTTPS etc.

[ViNyL]

Dank voor alle andere stof tot nadenken. Ik heb zelf ook aangeven dat het opslaan van gegevens voor bijvoorbeeld sollicitaties op de webserver onzinnig en vragen om problemen is. Waarom wil je deze gegevens daar namelijk hebben, dit kun je veel beter meenemen in een face-to-face gesprek.

Ook voor andere zaken is prima een alternatief te bedenken. Dat iets namelijk via het web kan wil niet zeggen dat je dit ook moet doen.

Het uitgangspunt is dus ook om te stoppen met het opslaan. Anders is mailen en encrypten/decrypten is bijvoorbeeld ook een oplossing die ik zelf al heb aangedragen heb aangezien we hier binnen onze organisatie al gebruiken van maken.

[DJMaze]

ViNyL schreef op donderdag 9 februari 2017 @ 11:56:
Ik heb zelf ook aangeven dat het opslaan van gegevens voor bijvoorbeeld sollicitaties op de webserver onzinnig en vragen om problemen is.

Daar denk ik persoonlijk anders over.

Stel ik upload mijn C.V. die gaat naar e-mailadres X:

1. De andere personeelsleden kunnen er dan niet bij
2. Dan maar opslaan op de NAS
3. NAS nadeel: "alle" personeelsleden kunnen op de NAS?
4. NAS nadeel: wat als iemand ransomware heeft geopend en de NAS is encrypted?
5. Nadeel: wat als iemand de c.v. of e-mail wist?

Één server veilig maken/beheren is makkelijker dan 30 werk computers + NAS.
Nadeel hiervan is dat de meeste organisaties gewoon zeggen dat er geen budget is om de server veilig te maken. Zeg zou zelf, wat je niet visueel ziet ga je toch geen geld aan besteden (totdat het te laat is)

Zorg gewoon voor een goede beheerder met kennis en betaal hem gewoon € 4000 per maand ofzo.
En zorg dat het getoetst wordt volgens de normen die gelden (als het zo belangrijk is)

[ Voor 8% gewijzigd door DJMaze op 09-02-2017 14:26 ]