[PHP/MySQL] Encrypten opgeslagen data in MySQL

[Roytoch]

Achtergrond: ik heb een kleine webapplicatie gebouwd waarmee ik mijn todo's kan bijhouden. Deze wordt ook gebruikt door enkele collega's. Nu lijkt het me ook handig om notulen bij te kunnen houden van meetings die ik heb, dus die feature wil ik er ook in zetten. Alleen mijn collega's zitten er ook in, en ik vind het geen fijn gevoel dat ook hun gespreksinhoud plaintext in een door mij in te zien pakket zitten. Dus wil ik iets doen met het encrypten van data. In principe kan MySQL dit met AES_Encrypt. Maar dan geef je de key dus mee in je query.

De key zou dan gebaseerd moeten worden op iets wat niet in de database staat of ergens in de code, dus volgens mij heb je dan alleen het wachtwoord waar je het op kan baseren. Maar dan zou je een gehashte variant van het wachtwoord in een sessie moeten houden en dat gebruiken om te en/decrypten.

Mijn vraag is tweeledig:
- Is MySQL encryption/decryption veilig genoeg?
- Is de manier hoe ik hem omschrijf, met hashed password, een goed idee?

[johnkeates]

Geen goed idee. Als je hun data niet wil kunnen decrypten kan je beter asymmetrische encryptie gebruiken. Dan kunnen ze gewoon encrypted data opsturen voor opslag en ontvangen en zelf decoderen client-side.

Als je encryptie/decryptie server-side gaat doen kan je er altijd bij.

Stel dat je het gewoon niet human-readable wil maken, dan kan je veel makkelijker een base64 of rot13 er overheen gooien.

[Roytoch]

Okay, duidelijk. In principe is in de basis je suggestie om base64 te gebruiken genoeg voor deze situatie omdat ik vooral wil voorkomen dat ik dingen kan zien als ik bijvoorbeeld iets wijzig in mysql. Het is namelijk een leerprojectje (wat de gebruikers ook weten) waardoor ik nu nog wel eens wat plaintext data onder ogen krijg.

Maar juist omdat het een leerproject is wil ik ook meteen leren hoe je iets als dit /goed/ aanpakt. Met echte beveiliging/encryptie heb ik nauwelijks ervaring, dus als asymmetrisch encrypten hier het juiste is ga ik me daarop inlezen. Goed om te weten dat mijn oorspronkelijke idee in ieder geval geen stand houdt.

[HollowGamer]

Je zou het ook anders kunnen oplossen:
- I.p.v. dat jij de eigenaar bent van de 'key', geef je de 'key' aan de gebruiker. Je kunt dus zelfs niks decrypten, maar de gebruikers kunnen dit wel (alleen hun eigen data uiteraard).

Een 'key' zou ook het wachtwoord kunnen zijn, of combinatie van meerdere waardes. Je kunt bijvoorbeeld ook de 'key' naar hun mailen als ze deze kwijt zijn.. zoveel leuks te beteken en uiterst leerzaam.

Check even op het net welke tot mogelijk is, zelf heb ik goede ervaring met (php-)mcrypt, check wel even wat veilig is kwa keuze.

Je zou ook eens kunnen zoeken hoe de dienst van onze MEGA het allemaal heeft gedaan.

[ Voor 7% gewijzigd door HollowGamer op 20-08-2014 22:35 ]

[Ramon]

Hash van het wachtwoord gebruiken is niet handig, wat als ze hun wachtwoord wijzigen?

[storeman]

Ik snap je uitgangspunt en heb zelf ook wel eens zoiets uitgewerkt, maar dan wel alles server side. Dat kan een bezwaar zijn, maar in dit geval lijkt mij dat overdreven. Punt is, iemand gebruikt een hosted dienst, dus gegevens kunnen worden ingezien. Wil men dat niet, dan moet je het zelf hosten.

Dat gaat natuurlijk voorbij aan het probleem dat je probeert op te lossen. Je wilt jezelf beschermen tegen info over anderen, terwijl je je db asn het adminnen bent. Dan lijkt mij een base64 of strrot al voldoende. Je kan het ingewikkelder maken, maar je probleem wordt daarmee niet beter opgelost, lijkt me.

[Gomez12]

Roytoch schreef op woensdag 20 augustus 2014 @ 21:22:
De key zou dan gebaseerd moeten worden op iets wat niet in de database staat of ergens in de code, dus volgens mij heb je dan alleen het wachtwoord waar je het op kan baseren. Maar dan zou je een gehashte variant van het wachtwoord in een sessie moeten houden en dat gebruiken om te en/decrypten.

Waarom zou je een gehashte variant van het wachtwoord in een sessie moeten houden?

Hoe ik het ooit eens opgezet heb was als volgt :
De client heeft een clear-text password.
Client-side genereer je hier een hash van en deze vergelijk je met je hash in de dbase
Tegelijkertijd genereer je hier client-side ook een key van (let op dat je dit separaat van het hashen doet, het is simpelweg iets anders) en kan je met bijv crypto-js alles client-side encrypten / decrypten

Op deze manier zie jij op de server nooit iets clear-text aankomen.

Enkel kan je er wel over denken om het in 2'en te hakken zodat mensen kunnen kiezen of ze een andere crypto key dan hun wachtwoord willen (anders moet met een pass-change alles over de lijn dan gedecrypt worden met oude pw en opnieuw ge-encrypt worden met nieuwe pw, leuk als iemand 10 Gig aan data heeft staan)

[Jurgle]

My 2 cents: doe de cryptogrfie client-side. Er zijn in javascript libraries beschikbaar voor zowel symetrische als asymetrische cryptografie, dus je kunt je vingeroefening zo ingewikkeld maken als je zelf wilt . Je kunt dan in de client data invoeren > just in time encrypten > opslaan op server en ophalen van de server > decrypten > weergeven. Het wachtwoord/de sleutel van de data 'leeft' dan alleen in de client.

Met het oog op het wijzigen van een wachtwoord kun je een methode toepassen waarbij je per user een keypair genereerd. Hiervan versleutel je 1 sleutel met een wachtwoord dat de gebruiker (in de client) opgeeft en gebruik je de andere sleutel (versleuteld met de 1e sleutel) om alle data te en/decrypten (in de client). Als een gebruiker zijn wachtwoord wil wijzigen hoef je dan alleen de eerste sleutel opnieuw te versleutelen zonder alle data opnieuw te moeten versleutelen.

Let wel op dat je het op deze manier onmogelijk maakt om een 'ik ben mijn wachtwoord vergeten'-functie in te bouwen. Dit wachtwoord leeft immer alleen in de client en wordt op geen enkele manier (ook niet gehashed) met de server gedeeld.

[BoringDay]

wachtwoorden hashen, gevoelige data encrypten/decrypten.
Base64 zou ik niet voor encryptie gebruiken, te eenvoudig om te decrypten met praktisch elke programmeertaal.

[RobIII]

Bedenk wel even dat je niet (makkelijk) meer in je data kunt zoeken en dus effectief een zoekfunctie overboord gooit.

[Gomez12]

RobIII schreef op donderdag 21 augustus 2014 @ 20:04:
Bedenk wel even dat je niet (makkelijk) meer in je data kunt zoeken en dus effectief een zoekfunctie overboord gooit.

Dat is uiteraard compleet afhankelijk van hoe je het zoeken opzet.

Zolang het een kleine app is zal dit zo zijn, maar bij een grotere app kan je er ook gewoon een separate zoek-app naast neerzetten die via ssh / cleartext de boel ontvangt en een id waarnaar verwezen moet worden en dan is het niet 100% end-to-end encoded, maar zolang jij geen toegang hebt tot de zoek-database dan heb je gewoon een black-box die een antwoord produceert.

Of als je weet dat de datasets per klant altijd klein zullen dan kan je bijv die data-set ook asynchroon in local-storage gaan synchen dan kan iemand door local-storage heenzoeken.

Het is niet zo 1-2-3 op te zetten maar je hoeft ook niet gelijk een extreem moeilijk proces op te zetten.

[RobIII]

Gomez12 schreef op donderdag 21 augustus 2014 @ 22:31:
Zolang het een kleine app is zal dit zo zijn, maar bij een grotere app kan je er ook gewoon een separate zoek-app naast neerzetten die via ssh / cleartext de boel ontvangt en een id waarnaar verwezen moet worden en dan is het niet 100% end-to-end encoded, maar zolang jij geen toegang hebt tot de zoek-database dan heb je gewoon een black-box die een antwoord produceert.

M.a.w. je verlegt 't probleem alleen maar naar een andere DB... Ik zie dat niet meteen als "oplossing" voor TS's probleem tbh. Maar hey, misschien werkt 't voor TS wel...

Gomez12 schreef op donderdag 21 augustus 2014 @ 22:31:
Of als je weet dat de datasets per klant altijd klein zullen dan kan je bijv die data-set ook asynchroon in local-storage gaan synchen dan kan iemand door local-storage heenzoeken.

Wat weer problemen geeft als je op meerdere devices dezelfde data wil gebruiken (of iig het syncen ervan weer bemoeilijkt). Of als je wil zoeken in data van een ander account (bijv. in een "teamverband", "projectgroep" o.i.d.)

Gomez12 schreef op donderdag 21 augustus 2014 @ 22:31:
Het is niet zo 1-2-3 op te zetten maar je hoeft ook niet gelijk een extreem moeilijk proces op te zetten.

Ik zei dan ook "niet (makkelijk)..."

[ Voor 3% gewijzigd door RobIII op 22-08-2014 00:49 ]

[BoringDay]

RobIII schreef op donderdag 21 augustus 2014 @ 20:04:
Bedenk wel even dat je niet (makkelijk) meer in je data kunt zoeken en dus effectief een zoekfunctie overboord gooit.

Dat hoeft op zich niet je kan bijvoorbeeld ORM toepassen en m.b.v. getters en setters voor elke gewenste eigenschap pas je encryptie of decryptie toe. In de zoek opdracht geef je gewoon de eigenschap mee (die zoekt dan immers naar de encrypted waarde).

[RobIII]

BoringDay schreef op vrijdag 22 augustus 2014 @ 10:47:
[...]


Dat hoeft op zich niet je kan bijvoorbeeld ORM toepassen en m.b.v. getters en setters voor elke gewenste eigenschap pas je encryptie of decryptie toe. In de zoek opdracht geef je gewoon de eigenschap mee (die zoekt dan immers naar de encrypted waarde).

Ik doelde eerder op een like '%foo%' of FTS variant erop

[BoringDay]

RobIII schreef op vrijdag 22 augustus 2014 @ 14:16:
[...]

Ik doelde eerder op een like '%foo%' of FTS variant erop

Daar heb je gelijk in. Het lijkt me dan ook niet de bedoeling je letterlijk elk veld gaat encrypten maar alleen de data dat relevant is voor het herleiden naar of dat privacy gevoelig is. 100% waterdicht krijg je het toch niet want dan kan de software er ook al niet meer mee overweg.

[Soultaker]

Eigenlijk lijkt me de manier die TS voorstelt best een goed idee, mits je er voor kan zorgen dat sessie data vertrouwelijk behandeld wordt. Als eigenaar van de website heb je altijd de mogelijkheid om data te onderscheppen; het gaat erom dat je dat ten eerste niet doet omdat je enige professionele integriteit hebt, en ten tweede je je wil indekken tegen het lekken van andermans gegevens in het geval dat derden toegang krijgen tot de database.

Ramon schreef op woensdag 20 augustus 2014 @ 22:37:
Hash van het wachtwoord gebruiken is niet handig, wat als ze hun wachtwoord wijzigen?

De manier waarop dit soort systemen meestal werken is dat er een random (zeg) 256-bit sleutel wordt gegenereerd voor het account. Die sleutel wordt symmetrisch (zeg, met AES) versleuteld met het wachtwoord. Als het wachtwoord gewijzigd moet worden, decodeer je de sleutel met het oude wachtwoord en versleutel je 'm opnieuw met het nieuwe wachtwoord.

(Dat betekent wel dat als iemand z'n wachtwoord kwijt is, je geen nieuw wachtwoord in kunt stellen.)

[Gomez12]

Soultaker schreef op zaterdag 23 augustus 2014 @ 12:27:
Als eigenaar van de website heb je altijd de mogelijkheid om data te onderscheppen; het gaat erom dat je dat ten eerste niet doet omdat je enige professionele integriteit hebt, en ten tweede je je wil indekken tegen het lekken van andermans gegevens in het geval dat derden toegang krijgen tot de database.

Als je als eigenaar die mogelijkheid hebt dan heb je het als hacker ook. En als eigenaar van de vps en ... en...

Maar waarom zou je het nog gaan encrypten als je als eigenaar er nog steeds bijkan? Uit de TS begrijp ik juist dat het hem erom gaat dat hij het niet meer wil kunnen zien.

[BoringDay]

Soultaker schreef op zaterdag 23 augustus 2014 @ 12:27:
Eigenlijk lijkt me de manier die TS voorstelt best een goed idee, mits je er voor kan zorgen dat sessie data vertrouwelijk behandeld wordt. Als eigenaar van de website heb je altijd de mogelijkheid om data te onderscheppen; het gaat erom dat je dat ten eerste niet doet omdat je enige professionele integriteit hebt, en ten tweede je je wil indekken tegen het lekken van andermans gegevens in het geval dat derden toegang krijgen tot de database.


[...]

De manier waarop dit soort systemen meestal werken is dat er een random (zeg) 256-bit sleutel wordt gegenereerd voor het account. Die sleutel wordt symmetrisch (zeg, met AES) versleuteld met het wachtwoord. Als het wachtwoord gewijzigd moet worden, decodeer je de sleutel met het oude wachtwoord en versleutel je 'm opnieuw met het nieuwe wachtwoord.

(Dat betekent wel dat als iemand z'n wachtwoord kwijt is, je geen nieuw wachtwoord in kunt stellen.)

Zou dat nu zoveel schelen?
Ligt het probleem niet meer bij het feit als iemand toegang tot de database heeft en daar een copy van maakt en door de database wachtwoord zelf heen komt gewoon toegang heeft tot alle tabellen.

Voor een webbased oplossing zou ik gewoon naar een x-aantal pogingen het account laten blokkeren je kan het account wel 100 constructies bedenken voor een wachtwoord beveiliging maar de rest is minstens zo belangrijk.

[TweakMDS]

Voor een systeem waar je notulen in gebruikt zou ik dit eigenlijk simpelweg niet encrypted op willen slaan.
Dat kan je in de toekomst enorm in de weg gaan staan als je je systeem uit wil breiden met bijvoorbeeld een elastic search of zoek opties die werken met bijvoorbeeld "soundex" (klinkt als), of migreren naar een andere database (bijvoorbeeld mongodb ofzo).

Onder de streep zou ik dit probleem langs een heel andere kant oplossen. Je zegt dat het een systeem is waar je veel in wil experimenteren en hobby-en, maar denk dan eerder aan een volwaardige OTAP omgeving. Op Ontwikkel en Test kan je spelen wat je wil met gegenereerde test data. Op Acceptatie laat je je collega's een nieuwe feature zien en kan je enkele mensen een "pilot" geven, en op Productie zetten zij hun gespreksverslagen. Daar hoef je over het algemeen ook veel minder in te debuggen.

Daarnaast is het gewoonweg discipline om niet te gaan neuzen in notulen van gevoelige vergaderingen. Eventueel zou je ook in de UI een "slotje" kunnen maken waarbij de gegevens van gevoelige data client-side encrypted (en decrypted) worden met een wachtwoord wat de gebruiker in geeft (en jij dus ook niet uit de user tabel zou kunnen halen). Daar kan je dan niet of beperkt in zoeken, tenzij je alles naar de client op gaat halen en op die manier zoeken. Lijkt niet handig.

Als je dit goed implementeerd geeft het je gebruikers wellicht ook een beter gevoel van veiligheid bij het opslaan van gegevens, en weet jij ook zeker dat collega's met minder eervolle intenties er niet bij kunnen, al zouden ze het willen.

Wie weet waar zo'n systeem nog naartoe kan groeien. Voor je het weet staat er HR info en contracten in, en wordt het door 4 man beheerd. Dan ben je toch blij als je fatsoenlijke security hebt ingebouwd zonder functionaliteit in te leveren op triviale todo-lijstjes en contactgegevens.