PDA

Bekijk Volledige Versie : Database (gegevens) encrypten ?



marcussmit
17/01/10, 19:05
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
17/01/10, 19:20
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
17/01/10, 19:34
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 :whistling:

t.bloo
17/01/10, 19:41
en als je het encrypted in de database zet, kun je alle queries op inhoud niet meer uitvoeren...

gjtje
17/01/10, 19:45
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
17/01/10, 19:56
Ben het zeer zeker niet met je eens.... Waar zou deze sleutel dan leesbaar moeten staan :whistling:

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
17/01/10, 20:11
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
17/01/10, 20:17
Lijkt mij nogal doelloos, gezien de scripts ook beschikbaar is kan iemand toch zelf de decoder ook zien en alle data decoderen?

marcussmit
17/01/10, 20:38
@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
17/01/10, 21:41
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
17/01/10, 22:09
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
17/01/10, 22:14
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
18/01/10, 01:24
:), 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
18/01/10, 10:27
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.:thumbdown:

marcussmit
18/01/10, 10:54
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.....

marcussmit
18/01/10, 10:58
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.

Wat een negativiteit... In dit geval gaat het om een VisualBasic/C# applicatie, dus echt cleartext is het nou ook weer niet. Applicaties kunnen inderdaad reversdengineered worden/geworden/ worden gereversed engineered, ach...whatever.. maar dan heb je een heel andere uitdaging. De vraag hier is om het onmogelijk te maken dat de klant zijn database aan een concurrerende leverancier kan geven.

marcussmit
18/01/10, 11:37
Inmiddels heb ik ook de namen van de producten die zouden doen wat de klant wil:

NetLib Encryptionizer (zeer duur daardoor nog niet geprobeerd)
DBdefence encryptor (instabiele werking)

Vanmiddag ga ik een demo-server neerzetten om beide producten uit te proberen !

marcussmit
21/01/10, 22:15
Hm, DBDefence valt alvast af. Een lege database versleutelen en weer leesbaar maken zorgt er alvast voor dat systeemtabellen onleesbaar worden.

stiller
22/01/10, 15:26
Wat een negativiteit... In dit geval gaat het om een VisualBasic/C# applicatie, dus echt cleartext is het nou ook weer niet. Applicaties kunnen inderdaad reversdengineered worden/geworden/ worden gereversed engineered, ach...whatever.. maar dan heb je een heel andere uitdaging. De vraag hier is om het onmogelijk te maken dat de klant zijn database aan een concurrerende leverancier kan geven.

Tsja Marcus, als je om advies vraagt, moet je het wel opvolgen, natuurlijk. Als ik het zo lees, heb je niet genoeg expertise om deze oplossing te bieden. Dat hoeft geen probleem te zijn, maar als de data op die DB genoeg waard is, wordt het wel lastig. Kan jij/jullie een claim verwachten als de boel toch gekraakt wordt?

Als ik het goed begrijp zijn zowel de encrypted DB als de applicatie met decryption en sleutel toegankelijk voor de beheerder? Dat is inderdaad niet erg veilig, want die beheerder kan dan op zijn gemakje:

a) een exploit zoeken voor de applicatie
b) verbanden zoeken tussen user input en applicatie/DB communicatie
c) de applicatie reverse engineeren
d) de DB brute forcen

Het is allemaal niet triviaal, maar als de data genoeg waard is...