Database (gegevens) encrypten ?

[marcussmit]

Beste specialisten,

Een klant vraagt mij of ik tools ken om een database te encrypten op zo'n manier dat de applicatie de data wel kan lezen, maar een beheerder (lees: concurrent die van de beheerder de data krijgt) dit niet kan.

Mij persoonlijk lijkt het onmogelijk, immers: hoe ziet je database dat de applicatie inlogt of de beheerder en: wil je uberhaupt wel dat je als beheerder niet bij de data kan komen? Maar wellicht zijn er tools die op gebruikersniveau de gegevens versleutelen ?

De optie die ik wel zie is om de data binnen de database te versleutelen, maar aangezien er best zware queries binnen de database worden uitgevoerd lijkt me ook dit een best ingewikkelde opgave.

Ik ben heel benieuwd of jullie opties kennen.

[Apoc]

Uiteraard kan dit. Echter laat je normaliter je applicatie de data versleutelen (encrypten) en weer ontcijferen (decrypten). Dit kan heel makkelijk met PHP gedaan worden.

Een voorwaarde is wel dat je de webserver en database server van elkaar scheidt. Anders zou iemand die de database server gehacked heeft, ook gemakkelijk bij de sleutel kunnen komen.

Feitelijk doe je het volgende:

- Je laat eerst PHP de string je naar de database wilt schrijven, encypten
- Dan schrijf je de encrypted data (op de gebruikelijke manier) naar de database
- Wanneer PHP de data weer opvraagt, laat je PHP zelf de data weer decrypten

Hou er verder wel rekening mee:

- Encryptie kan bijna altijd ontrafeld worden als je maar genoeg tijd hebt
- Hoe beter de encryptie, hoe lastiger het is om de 'code te kraken' (c.q. het kost meer tijd)
- Hoe beter de encryptie, des te meer rekenkracht dit vereist van de (web)server. Erg belangrijk om dit te stress-testen

[Mikey]

Een voorwaarde is wel dat je de webserver en database server van elkaar scheidt. Anders zou iemand die de database server gehacked heeft, ook gemakkelijk bij de sleutel kunnen komen.

Ben het zeer zeker niet met je eens.... Waar zou deze sleutel dan leesbaar moeten staan

[t.bloo]

en als je het encrypted in de database zet, kun je alle queries op inhoud niet meer uitvoeren...

[gjtje]

SQL server kan on the fly een hele database encrypten, de data staat dan versleuteld op disk, de applicatie zelf ziet er niks van.

[KristianT]

Ben het zeer zeker niet met je eens.... Waar zou deze sleutel dan leesbaar moeten staan

De sleutel (hash) zou je bijvoorbeeld zo kunnen opslaan in de database of in een tekst bestand:
xxxxxxxxxxxxxxxxxxxxxxxxxxSLEUTELxxxxxxxxxxxxxxxxx xx

Via PHP lees je dan bijvoorbeeld alleen teken 20 t/m 30 uit voor de sleutel.
De rest zijn zeg maar tekens die je niet gebruikt. (kan je eventueel elke dag veranderen met de rand() functie)

Om een goede hash te maken in PHP gebruik je bijvoorbeeld dit:

// Make password hash
function make_hash($password){
$password = sha1(md5(sha1(md5($password).sha1($password)).md5(md5($password).sha1($password))));;
return $password;
} 

Kijk verder eens naar de AES_Decrypt functie van MySQL, werkt goed.

In een Insert / Update zet je dit:

page_content = AES_ENCRYPT('$page_content','$page_password') 

In een Select zet je het volgende:

AES_DECRYPT(page_content,'$page_password') AS page_content 

EDIT
Ik zie dat dit in het Microsoft Hosting forum staat, om welke database gaat het hier ?

[marcussmit]

Dank voor de reacties. Maar dit zijn opties die het ofwel onmogelijk maken om queries uit te voeren op basis van content (select `name` from `customers` where `name` like `Marcus%`) ofwel de database kan nog steeds gelezen worden.

Het probleem is dat de ontwikkelaar bang is dat de database in handen van een concurrent komt. Die concurrent krijgt die database dan van de klant natuurlijk, en dat is precies het probleem. Mijn klant is bang dat zijn concurrenten een algemene conversietool kan schrijven om de database naar concurrende databaselayouts te migreren en zo alle klanten simpel overgeheveld kunnen worden. (Die concurrent waar klant nu bang voor is verkoopt nogal agressief)

Overigen (dat had ik niet gemeld) gaat het om een Microsoft SQL Database met een Visual Basic/C# applicatie.

[Triloxigen]

Lijkt mij nogal doelloos, gezien de scripts ook beschikbaar is kan iemand toch zelf de decoder ook zien en alle data decoderen?

[marcussmit]

@Triloxigen: precies mijn probleem. Klant geeft aan dat er wel tools zijn die dit doen (al geeft hij geen voorbeelden) maar die zouden belachelijk duur zijn... Volgens mij is het onmogelijk om data te beveiligen dusdanig dat de beheerder er niets mee kan. Of je moet het al binnen SQL Server op gebruikerscredentials encrypten..

Zou SQL Server plugins/modules aankunnen ?

[kjkoster]

Uhm, als de klant de beheerder niet kan vertrouwen, waarom zoekt hij dan niet een andere beheerder? Eentje die wel te vertrouwen is? Het klinkt mij als of iemand een technische oplossing zoekt voor een niet-technisch probleem.

Two-way encryptie van de data in de database encrypten is vrij zinloos, en helemaal als de sleutel en het decryptie algoritme op dezelfde machine staan. Da's precies even veilig als zonder encryptie, een stuk trager en een stuk laster te onderhouden.

One-way encryptie kan wel zin hebben, voor bijvoorbeeld passwords. Kijk maar hoe dat in /etc/passwd is geregeld.

Dit is typisch zo'n checkbox ergens in het projectoverzicht van je manager. Daarom zijn die tools ook zo duur: het zijn de tekenbevoegde managers die beslissen dat dit belangrijk is en niet de techneuten die er de onzin van inzien.

Kees Jan

[lmp]

Voor MSSQL logins kun je zorgen dat de beheerder de data niet kan querieen. Op de data hoeft een beheerders login namelijk geen select te hoeven doen (insert, drop,.....). Daarnaast kun je je applicatie alleen queries laten doen via stored procedures. Deze geven alleen de benodigde data terug en nooit altijd het geheel. Een beheerder die het wachtwoord dus heeft van he applicatie, moet heel veel queries gaan doen, voordat die alle data zou hebben.

Daarnaast laat je de database files op NTFS encrypted opslaan. De key kan in de AD gezet worden. Je zult dan wel moeten zorgen dat MSSQL onder die bewuste user komt te draaien. Beheerder van AD en Database machine niet de zelfde persoon laten zijn. Ook de backups laat je naar een disk schrijven welke encrypted is.
Voor het op NTFS encrypted op te laten slaan, kost het je wel wat performance op je IO, hou hier dus rekening mee.

Zelf al een paar van dit soort databases onder beheer, alleen hier is het stukje encryptie op disk niet gedaan, omdat ik wel vertrouwd wordt met de database files op disk. Daarnaast geeft het een extra risico dat als het echt mis gaat een encrypted bestand niet meer terug gehaald mag worden. Het zou niet mogen, maar er zou zoveel niet kunnen in de IT wereld die toch dagelijks gebeurt.

[Mikey]

De sleutel (hash) zou je bijvoorbeeld zo kunnen opslaan in de database of in een tekst bestand:
xxxxxxxxxxxxxxxxxxxxxxxxxxSLEUTELxxxxxxxxxxxxxxxxx xx

Via PHP lees je dan bijvoorbeeld alleen teken 20 t/m 30 uit voor de sleutel.
De rest zijn zeg maar tekens die je niet gebruikt. (kan je eventueel elke dag veranderen met de rand() functie)

Om een goede hash te maken in PHP gebruik je bijvoorbeeld dit:

// Make password hash
function make_hash($password){
$password = sha1(md5(sha1(md5($password).sha1($password)).md5(md5($password).sha1($password))));;
return $password;
} 

Kijk verder eens naar de AES_Decrypt functie van MySQL, werkt goed.

In een Insert / Update zet je dit:

page_content = AES_ENCRYPT('$page_content','$page_password') 

In een Select zet je het volgende:

AES_DECRYPT(page_content,'$page_password') AS page_content 

EDIT
Ik zie dat dit in het Microsoft Hosting forum staat, om welke database gaat het hier ?

, ik bedoelde, op moment je je source encrypt kan het zonder problemen samen op een machine kunnen staan. Verder zou je ervoor kunnen zorgen door middel van een timestamp toe te voegen het terugrekenen van de key dusdanig lastig wordt omdat niet alleen de input encrypted wordt maar ook de timestamp, hiermee heb je elke (m)s een andere output van dezelfde data die erin gezet wordt...

[Apoc]

, ik bedoelde, op moment je je source encrypt kan het zonder problemen samen op een machine kunnen staan. Verder zou je ervoor kunnen zorgen door middel van een timestamp toe te voegen het terugrekenen van de key dusdanig lastig wordt omdat niet alleen de input encrypted wordt maar ook de timestamp, hiermee heb je elke (m)s een andere output van dezelfde data die erin gezet wordt...

Dan zou je dus dubbel moeten encrypten (database en source). Het lijkt me dan makkelijker om gewoon twee aparte servers te gebruiken. Daarnaast; zeker als het een zware applicatie betreft, kan het scheiden van database- en webserver geen kwaad.

Daarnaast denk ik dat het decrypten van source bestanden makkelijker is dan het decrypten van een zelfgemaakte encryptiealgoritme in PHP. Dit voornamelijk met het oog op het feit dat source bestanden vaak door Zend of Ioncube encrypted worden, welke door heel veel mensen reverse-engineered worden.

[Mikey]

Dan zou je dus dubbel moeten encrypten (database en source). Het lijkt me dan makkelijker om gewoon twee aparte servers te gebruiken. Daarnaast; zeker als het een zware applicatie betreft, kan het scheiden van database- en webserver geen kwaad.

Dat het jou makkelijker lijkt, en het scheiden van de database server van de webserver geen kwaad kan, daar ging het toch niet om ? Wat jij hier zo verkoopt is gewoon schijnveiligheid. Zolang je source gewoon leesbaar blijft en daarin de key van de database staat, heb je gewoon je deur op slot met een "my little diary" slotje. Het slotje zit erop, maar het is wachten tot iemand met de paperclip hem eraf haalt.

Daarnaast denk ik dat het decrypten van source bestanden makkelijker is dan het decrypten van een zelfgemaakte encryptiealgoritme in PHP. Dit voornamelijk met het oog op het feit dat source bestanden vaak door Zend of Ioncube encrypted worden, welke door heel veel mensen reverse-engineered worden.

Heb je wel eens met zend of ioncube gewerkt ? Dan weet je ook heel goed dat er een hoop instellingen zijn om te voorkomen dat reverse engineering makkelijk toegepast kan worden. Je kan zelfs sleutels aan de encryptie toevoegen. Maar uiteindelijk geld ook hier dat alles ooit wel eens te kraken is, zelfs je encryptie sleutel die je bedenkt voor de database. Dus ik vind je vergelijking kant noch wal slaan.

[marcussmit]

Uhm, als de klant de beheerder niet kan vertrouwen, waarom zoekt hij dan niet een andere beheerder? Eentje die wel te vertrouwen is? Het klinkt mij als of iemand een technische oplossing zoekt voor een niet-technisch probleem.

Zou leuk zijn, maar in dit geval gaat het om een beheerder van de eindklant ;- ) Mijn klant schrijft alleen de software met de opzet van de database..

Maar op zich ben ik wel met je eens dat vertrouwen tussen klant en beheerder/leverancier een erg belangrijke basis is voor een zakelijke relatie. Maar helaas leven we niet in een perfecte wereld (hence the question).

De enige min of meer veilige oplossing die ik zelf zie is als mijn klant zelf de databases gaat hosten van zijn klanten. Dan hoeft hij alleen maar te zorgen dat de wachtwoorden niet uit de applicatie teruggevonden kunnen worden.....