Frameworks voor encrypten database data

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • cripto
  • Registratie: Juni 2018
  • Laatst online: 04-02-2024
Nu Privacy en het beschermen van data steeds meer een ding begint te worden ben ook ik op zoek gegaan naar manieren om bepaalde database-data extra te gaan beschermen. Dat houdt in dat ik de gegevens in sommige tabellen zou willen encrypten omdat ze wat gevoeliger zijn dan 'gewone' persoonsgegevens.

Domweg een sterk encryptie algoritme gebruiken waarbij de secret op de server staat vind ik geen optie. Als iemand zich toegang weet te verschaffen tot de server dan is alles daar aanwezig om alsnog de gegevens te decrypten..

Idealiter zou ik dus iets doen met bvb het wachtwoord van de gebruiker die inlogt, omdat alleen die gebruiker dat weet. Een zero knowledge architectuur is ideaal maar om tot iets te komen wat zowel secure als gebruikersvriendelijk is, is knap lastig. Als ik me niet vergis herinner ik me gelezen te hebben dat een service als protonmail daar maanden mee bezig is geweest. Dat is daarmee ook niet echt een optie. En daarbij is het wellicht ook niet altijd nodig om helemaal 100% alles afgedekt te hebben.

Een gouden regel bij dit soort dingen is dat je niet aan zelfgebrouwen oplossingen moet beginnen omdat - zelfs als je redelijk wat kennis van zaken heb - het makkelijk is om dingen over het hoofd te zien en in bepaalde valkuilen te stappen. Ik vroeg me daarom af of er (al) frameworks bestaan die hier een oplossing voor bieden of iig het belangrijkste uit handen neemt. Het liefst iets wat een geschikt is voor een php/javascript applicatie (omdat daar nu eenmaal veel gebruik van wordt gemaakt)
Hoewel er wel bvb crypto-libraries voor javascript te vinden zijn biedt zoiets maar een heel klein deel van een mogelijke oplossing. Ik zoek meer naar een framework wat een veel totaler pakket biedt en ook goed heeft nagedacht over waar bvb de secret op een veilige manier opgeslagen kan worden. Maar zoiets heb ik niet kunnen vinden.
Bestaat er al zo iets?
Of kent iemand anders voorbeeld architecturen die iig de problemen waar je mee te maken krijgt hebben uitgewerkt zodat die redelijk goed zelf te implementeren zijn?

Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
Als je niet hoeft te zoeken in de database op die data (WHERE data LIKE '') dan kan je het inderdaad beveiligen.
Lees eens Welke versleuteling database voor persoonsgegevens?
cripto schreef op donderdag 14 juni 2018 @ 01:01:
Nu Privacy en het beschermen van data steeds meer een ding begint te worden ben ook ik op zoek gegaan naar manieren om bepaalde database-data extra te gaan beschermen.
Niet "nu" dat was op 6 juli 2000 ook al een "ding".
Verschil is dat sinds 2016 het allemaal een beetje strenger is, en dat is ook al 2 jaar geleden...
En waarom? Nou, omdat iedereen niet zo moeilijk deed over die gegevens, terwijl je dat wel zou moeten doen.

[ Voor 59% gewijzigd door DJMaze op 14-06-2018 10:06 ]

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • aegis
  • Registratie: Augustus 2002
  • Laatst online: 20-07 20:05
Waar ik mee zou beginnen is goed de specificaties vastleggen, wat is de reden dat je de data moet encrypten waaraan moet het voldoen? Disk Encryptie/File Encryptie/Data Encryptie op applicatie niveau en wat ook heel belangrijk is wat is de waarde van de data is de data maar 10k waard dan heeft het geen zin om voor 100k techniek/hardware/kennis te investeren om de data te beveiligen. Daarnaast denk ook na over performance zie dat je PHP wilt gaan gebruiken dan kan het snel gaan dat je totale applicatie gewoon super traag word als je meer dan 50 gebruikers online hebt, tijdens testen en bij local development merk je dat niet omdat je dan maar 1 gebruiker online is de developer. Heb dit bij mijn vorig werkgever meegemaakt daar werd de encryptie in php afgehandeld en scheelde het een factor 10 minimaal in performance met encryptie aan of uit.Ook moet je vooruit plannen in de eerste versie was het goed de data encryptie de applicatie te hebben tot dat gebruikers dat werkelijk met het systeem gingen werken, die kwamen al heel gauw met de vraag kan er ook gezocht worden. Wat een hele logische functie is als je als gebruiker steeds meer data in het systeem hebt staan. Maar dat kon niet zomaar geimplementeerd worden omdat een groot deel van de applicatie dan herschreven moest worden.

Dit is geen beklaag van doe dan maar geen encryptie zeker niet ben helemaal pro encryptie ben alleen van mening dat het niet iets is wat je er zo even bij doet. Het is een integraal onderdeel van jou architecture, en moet dan ook goed uitgedacht worden.

Hier onder misschien wat tips waar je naar zou kunnen kijken
MySQL/MariaDB hebben een eigen encrypt/decrypt functie die je kan aanroepen dan kun je de database de encryptie laten afhandelen. Je kan dit ook in de applicatie zelf kunnen doen maar dan moet je het goed programmeren en testen om geen performance drop te krijgen.

De Key zou op je kunnen op slaan in een keystore service zoals Vault(selfhosted)/AWS Key Management Service (KMS)/Google CLOUD KEY MANAGEMENT SERVICE/Speciale Hardware(prijs niveau banken/enterprisse).
Dan geef je de applicatie server toegang to die dienst en dan elke Encrypt/Decrypt operatie moeten de keys opgehaald worden van die services.

Daarnaast is het handig om de een goed key rotatie te bedenken, bijvoorbeeld per encryptie een eigen key en die dan bij decrypten weer weg te gooien en een nieuw key generen voor de volgende encryptie.

https://bettyskitchen.nl


Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
@aegis en hoe heb je het "key" probleem opgelost zodat deze niet per ongeluk in logs voor komt?
Denk aan: PHP (x)debug logs, SQL logs, etc.

Ik zie namelijk nog wel eens:
code:
1
2
3
4
5
mysqli_connect(username, password) failed

of

decrypt(key, password) failed

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • aegis
  • Registratie: Augustus 2002
  • Laatst online: 20-07 20:05
dat heb ik niet opgelost ;) was niet de backend dev. Maar dat zijn ook dingen waar je goed over na moet denken en testen, maakt niet uit in welke taal of applicatie.

Zou zelf verwachten dat als ik aan een platform/framework methode een key/password mee geeft dat ingeval van een error die niet zo in de log komt, voor je eigen code kan je dat nog wel regelen maar voor externe code zoals
PHP:
1
mysqli_connect
zou ik verwachten dat het niet zo in de logs gedumpt wordt. Dat is gewoon een bug en zou gefixed moeten worden.

[ Voor 52% gewijzigd door aegis op 14-06-2018 10:41 ]

https://bettyskitchen.nl


Acties:
  • 0 Henk 'm!

  • REDSD
  • Registratie: Maart 2004
  • Laatst online: 21:41
DJMaze schreef op donderdag 14 juni 2018 @ 10:34:
@aegis en hoe heb je het "key" probleem opgelost zodat deze niet per ongeluk in logs voor komt?
Denk aan: PHP (x)debug logs, SQL logs, etc.

Ik zie namelijk nog wel eens:
code:
1
2
3
4
5
mysqli_connect(username, password) failed

of

decrypt(key, password) failed
Je kan dat oplossen door tijdelijke variabelen eerst te plaatsen en deze te gebruiken met het decrypten, voor mysql ziet dat er als volgt uit:

code:
1
2
3
4
5
SET block_encryption_mode = 'aes-256-cbc';
SET @key_str = SHA2('21KD3658bk65q0SptoVQVYl5k2tc636W',512);#ENCRYPT_KEYSTR 
SET @init_vector = CAST("kP6hT6sOwdv4o0sI" AS BINARY);#ENCRYPT_IV 

SELECT CAST(AES_DECRYPT(email, @key_str,@init_vector) as CHAR) as email  FROM users LIMIT 100

IV zou je ook in een kolom van de tabel die je gebruikt kunnen plaatsen.

PS ik ga er even vanuit dat je encryptie in mysql doet, maar het zelfde geld voor in code, alleen dan gebruik maken van constants zoals de define functie.

[ Voor 8% gewijzigd door REDSD op 14-06-2018 10:46 ]


Acties:
  • 0 Henk 'm!

  • cripto
  • Registratie: Juni 2018
  • Laatst online: 04-02-2024
aegis schreef op donderdag 14 juni 2018 @ 10:12:
Waar ik mee zou beginnen is goed de specificaties vastleggen
Hoewel er een directe aanleiding is wilde ik het eigenlijk algemeen houden.

En in het verlengde daarvan: hoewel ik blij ben met de reacties gaan die allemaal al weer heel erg op implementaties in en daar zoek ik in eerste instantie juist niet naar omdat - zoals ik aangaf - bij een zelfbedachte oplossing het makkelijk is zaken over het hoofd te zien.

Wat er tot dusver bijvoorbeeld aan bod is gekomen zijn vooral serverside oplossingen maar die hebben als nadeel dat het lastig is om te beschermen tegen situaties waarin iemand zichzelf toegang tot de server verschaft. En zelfs als je dat helemaal secure krijgt zit je bvb nog met zaken als session-riding.

Maar goed: hoewel ik dat soort dicussies interessant vind ben ik daar dus eigenlijk niet naar op zoek: ik zoek meer een bestaand framework oid waarin dit soort beslissingen al genomen zijn en binnen het geheel op elkaar afgestemd.
Een discussie over de voors en tegens van bepaalde implementatie-details doe ik graag, maar dan graag in een ander draadje. In dit draadje zou ik graag de voors en tegens van bestaande totaal-oplossingen bespreken (als die er zijn)
aegis schreef op donderdag 14 juni 2018 @ 10:12:
wat is de waarde van de data is de data maar 10k waard dan heeft het geen zin om voor 100k techniek/hardware/kennis te investeren om de data te beveiligen
Precies. Ik hoef ook niet iets wat het security niveau van een bank heeft, maar waar mogelijk wil ik het wel zo goed mogelijk oplossen en dat is wederom een reden dat ik in eerste instantie naar een bestaande oplossing op zoek ben: naast dat die dan (hopelijk) bewezen zou zijn en dus waarschijnlijk veiliger dan iets dat je zelf verzint, scheelt het ook development en dus kosten.

Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
cripto schreef op donderdag 14 juni 2018 @ 11:28:
Precies. Ik hoef ook niet iets wat het security niveau van een bank heeft, maar waar mogelijk wil ik het wel zo goed mogelijk oplossen en dat is wederom een reden dat ik in eerste instantie naar een bestaande oplossing op zoek ben
Zelfs banken worden gehackt met hun bestaande oplossingen. Waar wil je nou heen?

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • cripto
  • Registratie: Juni 2018
  • Laatst online: 04-02-2024
DJMaze schreef op donderdag 14 juni 2018 @ 12:05:
[...]

Zelfs banken worden gehackt met hun bestaande oplossingen.
wel eens van beeldspraak gehoord? ;)
Ik wist niet dat alles hier zo letterlijk opgevat wordt, maar waar ik zei dat ik niet het beveiligingsniveau van een bank hoef bedoel ik dat het geen 100% waterdichte oplossing hoef te zijn (en nee, ik ben niet bang voor waterlekkage ;-) dit is wederom beeldspraak).
Waar wil je nou heen?
Zoals reeds aangegeven ben ik op zoek naar bestaande oplossingen die een framework bieden om database data op een veilige manier te encrypten, er van uitgaande dat de server mogelijk een keer gehackt wordt.
Ik had graag een voorzet gegeven om daar dan gelijk de voors en tegens van te bespreken, maar helaas heeft mijn eigen zoektocht niets opgeleverd.

Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
@cripto zoals ik al aangaf, in de topic link die ik poste, gebruik ik dus private/public key enevelope sealing.
Op de server staat het dus encrypted met een public key en alleen een client kan decrypten.
Echter heeft dit dus ook een nadeel: de server kan nooit decrypten.
cripto schreef op donderdag 14 juni 2018 @ 11:28:
Hoewel er een directe aanleiding is wilde ik het eigenlijk algemeen houden.
Zoals je ziet bestaat "algemeen" dus niet ;)

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • cripto
  • Registratie: Juni 2018
  • Laatst online: 04-02-2024
DJMaze schreef op donderdag 14 juni 2018 @ 13:09:
@cripto zoals ik al aangaf, in de topic link die ik poste, gebruik ik dus private/public key enevelope sealing.
Op de server staat het dus encrypted met een public key en alleen een client kan decrypten.
Echter heeft dit dus ook een nadeel: de server kan nooit decrypten.
Dat vind ik juist een voordeel :-)

Maar wat zijn veilige manieren op de private key op te slaan? Ik wilde naar iets toe waarbij dit op basis van het wachtwoord is waarmee ze inloggen, maar ik wil niet iedere keer bij het weergeven van gegevens om het wachtwoord moeten vragen. Maarja, het wachtwoord ergens plain-text opslaan lijkt me ook geen optie. Wat zijn goeie manieren om dat veilig te doen?
Zoals je ziet bestaat "algemeen" dus niet ;)
Nou, iedere situatie is natuurlijk verschillend - dat klopt. Maar bepaalde problematiek kent ook vaak een bepaalde algemene aanpak

Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 22:28
cripto schreef op donderdag 14 juni 2018 @ 01:01:
Idealiter zou ik dus iets doen met bvb het wachtwoord van de gebruiker die inlogt, omdat alleen die gebruiker dat weet. Een zero knowledge architectuur is ideaal maar om tot iets te komen wat zowel secure als gebruikersvriendelijk is, is knap lastig.
Wat ik nog niet zo goed begrijp is het praktische doel van je vraag. Een wachtwoord wordt gehashed omdat de gebruiker als enige mag weten wat het wachtwoord is.

Als er dus gegevens extra beschermd moeten worden zoals een wachtwoord, dan betekent dat dat je dingen opslaat die alleen de gebruiker mag weten, want niemand anders kan immers bij die gegevens. Helemaal als het informatie is die met een wachtwoord van de gebruiker versleuteld wordt.

Dan is dus de eerste vraag. Waarom sla je het sowieso op? Regel 1 van de oude WBP en de nieuwe AVG is doelbinding. Heb je een goede reden om privacy gevoelige data op te slaan? Zo niet, sla het niet op en probleem opgelost.

Kan je iets meer informatie geven over de gegevens die je wilt versleutelen en het doel daarbij? Is het bijvoorbeeld wel belangrijk dat je kunt decrypten of is een hashen voldoende?
Ik zoek meer naar een framework wat een veel totaler pakket biedt en ook goed heeft nagedacht over waar bvb de secret op een veilige manier opgeslagen kan worden. Maar zoiets heb ik niet kunnen vinden.
Omdat je dat ook niet veilig zelf kunt opslaan. Dat is de reden dat er bij echt privacy gevoelige gegevens die gepseudonimiseerd moeten worden met een Trusted Third Party wordt gewerkt. Een partij die de sleutel voor jou in beheer neemt en de gegevens namens jou pseudonimiseerd (nadat je ze eerst gepseudonimiseerd hebt aangeleverd).

[ Voor 18% gewijzigd door CurlyMo op 16-06-2018 23:42 ]

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
cripto schreef op zaterdag 16 juni 2018 @ 23:15:
Ik wilde naar iets toe waarbij dit op basis van het wachtwoord is waarmee ze inloggen, maar ik wil niet iedere keer bij het weergeven van gegevens om het wachtwoord moeten vragen.
En wat als "ze" hun wachtwoord wijzigen?

Je zou sleutels kunnen opslaan in de browser met webcrypt, maar wat als ze een andere browser gebruiken?

Je zou ook een sha256 van het wachtwoord kunnen gebruiken. Bij inloggen deze genereren en opslaan in de session, en vervolgens gebruiken in de private key als passphrase.
Bij wijzigen wachtwoord de private key passphrase resetten.
Dan heb je een kleine "waterlekkage".
Echter, als ze hun wachtwoord niet meer weten kan je de private key ook niet meer gebruiken, en moet er een nieuwe key pair komen.
Iemand anders moet diegene dan weer toevoegen aan de seal.
Is iedereen zijn wachtwoord kwijt, dan is de data verloren.

Vandaar dat ik sowieso lokaal een private key heb ;)

[ Voor 17% gewijzigd door DJMaze op 16-06-2018 23:48 ]

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

DJMaze schreef op donderdag 14 juni 2018 @ 09:40:
Als je niet hoeft te zoeken in de database op die data (WHERE data LIKE '') dan kan je het inderdaad beveiligen...
Dit is het probleem. Je hebt feitelijk geen database meer, maar alleen nog maar remote storage.
Dan kun je wel je private key opsturen naar de server, maar dan heeft die zowel je private- als je public key in het geheugen, die dan beiden voor een hacker toegankelijk zijn.

QnJhaGlld2FoaWV3YQ==


Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
Brahiewahiewa schreef op zondag 17 juni 2018 @ 15:20:
Dit is het probleem. Je hebt feitelijk geen database meer, maar alleen nog maar remote storage.
Dat is geen probleem, dat is een keuze.
Net als andere binaire data in een database, zoals afbeeldingen.

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • cripto
  • Registratie: Juni 2018
  • Laatst online: 04-02-2024
CurlyMo schreef op zaterdag 16 juni 2018 @ 23:31:
[...]

Wat ik nog niet zo goed begrijp is het praktische doel van je vraag. Een wachtwoord wordt gehashed omdat de gebruiker als enige mag weten wat het wachtwoord is.

Als er dus gegevens extra beschermd moeten worden zoals een wachtwoord
Nee, het gaat niet om het wachtwoord zelf - die sla ik gewoon gehashed op.
Vanuit een stukje gebruikersgemak wilde ik het wachtwoord gebruiken om de data te encrypten en decrypten. Net zoals bvb protonmail dat doet.
Kan je iets meer informatie geven over de gegevens die je wilt versleutelen en het doel daarbij? Is het bijvoorbeeld wel belangrijk dat je kunt decrypten of is een hashen voldoende?
Het is een vrij beperkte data-set die zowel geëncrypt als gedecrypt moet kunnen worden. Ik hoef er verder niet op te kunnen zoeken, maar moet het wel gedecrypt aan de client kunnen tonen.
DJMaze schreef op zaterdag 16 juni 2018 @ 23:44:

En wat als "ze" hun wachtwoord wijzigen?
Hmm...da's toch niet zo'n probleem? Met die openssl_seal bvb zou dat hetzelfde zijn als dat je een gebruiker toevoegt
Je zou sleutels kunnen opslaan in de browser met webcrypt, maar wat als ze een andere browser gebruiken?
Ja, dat lijkt me niets idd.
Je zou ook een sha256 van het wachtwoord kunnen gebruiken. Bij inloggen deze genereren en opslaan in de session, en vervolgens gebruiken in de private key als passphrase.
Bij wijzigen wachtwoord de private key passphrase resetten.
Dan heb je een kleine "waterlekkage".
Wat zie jij hier precies als lekkage?
Het nadeel wat ik zelf zie is dat alles dan op de server aanwezig is om de gegevens te kunnen decrypten. Weet iemand zich toegang tot de server te verschaffen dan kan ie de session uitlezen en daarmee de data.
Echter, als ze hun wachtwoord niet meer weten kan je de private key ook niet meer gebruiken, en moet er een nieuwe key pair komen.
Iemand anders moet diegene dan weer toevoegen aan de seal.
Is iedereen zijn wachtwoord kwijt, dan is de data verloren.

Vandaar dat ik sowieso lokaal een private key heb ;)
Ja, precies. Ik zal er zelf voor zorgen dat ik lokaal een backup veilig heb opgeslagen.

Acties:
  • 0 Henk 'm!

  • kodak
  • Registratie: Augustus 2001
  • Laatst online: 21:09

kodak

FP ProMod
Als we de techniek los laten dan komt je wens het dichtste in de buurt van frameworks voor secure storage. Specifieker voor web applicaties. Graag voor een bepaald platform. En niet theoretisch maar implementeerbaar als code. Je vraagt nogal wat.

Ik heb geen antwoord op je vraag, maar wel een verwijzing.
Bij owasp.org komen thema's als security frameworks of andere beveiligings vraagstukken en uitwerkingen voor web applicaties aan bod.
Domweg een sterk encryptie algoritme gebruiken waarbij de secret op de server staat vind ik geen optie.
Als je meer encryptie wil toepassen dan gebruikelijk is dan zou ik met toch afvragen of je daarmee ook de zwakste schakel aanpakt. Secrets op de server is een rekbaar begrip, zoals heartbleed, spectre en meltdown al lieten zien.

Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 22:28
cripto schreef op donderdag 14 juni 2018 @ 01:01:
Domweg een sterk encryptie algoritme gebruiken waarbij de secret op de server staat vind ik geen optie. Als iemand zich toegang weet te verschaffen tot de server dan is alles daar aanwezig om alsnog de gegevens te decrypten..
Na je laatste post een reactie op dit punt. Hoe je het ook doet. Het encrypten en decrypted zal altijd ergens moeten gebeuren en de webapplicatie zal toegang tot die locatie moeten hebben. Op het moment dat je server gehacked wordt geef je dus ofwel je algoritme bloot ofwel je geheime sleutel voor het decrypten. Dat maakt dus allemaal niet uit. 100% veilig krijg je het dus nooit op je eigen server.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
WebCrypto kan RSA-OAEP je kan dus de browser een key-pair laten genereren en exporteren.
Als je dat netjes doet kan je dus de data encrypted naar de client sturen en daar decrypten.

Setup:
  1. Webbrowser crypto.subtle.generateKey()
  2. Webbrowser crypto.subtle.exportKey()
  3. Webbrowser store private key in localStorage
  4. Webbrowser store private key on disk (ja, je kan een "opslaan als" aanbieden) voor evt. import in andere webbrowser
  5. Server: store public key
  6. Server: store private key (encrypted als backup)
Gebruik:
  1. Server stuurt data encrypted
  2. Webbrowser private key foetsie (dus niet in localStorage): gebruik importKey() enzo
  3. Webbrowser decrypt met private key
Zijn zo je problemen weg?

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • The Realone
  • Registratie: Januari 2005
  • Laatst online: 23-07 12:39
Komt een oplossing als deze niet aardig in de buurt, al dan niet i.c.m. KeySecure?

Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
@The Realone als ik het plaatje bekijk zie ik nog steeds "data in the clear".
Dan heb je nog steeds een probleem op de "application server" (wat toch al de zwakste schakel is).

Maak je niet druk, dat doet de compressor maar

Pagina: 1