[PHP] Gegevens beveiligen (encrypt/decrypt)

[Verwijderd]

Ik hoop dat dit het goede subforum is, het gaat namelijk niet zozeer over hoe encryptie/decryptie werkt (dat is al duidelijk).

De situatie:
Ik heb een database met extreem gevoelige informatie (adressenbestand) welke ik wil beveiligen tegen ongewenste mensen. De front-end beveiligen is geen probleem, kwestie van wachtwoord controle en wat andere checks (IP, encrypted cookies, etc.). Echter, de back-end zit ik mee in mijn maag.
Ik heb een MySQL server de gegevens in de tabellen moeten beveiligd worden. Encrypten en decrypten is geen probleem, echter: ik moet ergens een sleutel gaan definieëren. En hier zit het probleem, ik wil deze sleutel absoluut niet opslaan in de PHP file. Er zijn meerdere mensen met toegang tot de server (virtual hosting) en die zouden theoretisch (zeker de beheerders) in de MySQL tabel kunnen loeren.

Nu vroeg ik me af, wat zou de beste protectie voor zoiets zijn? Het is slechts voor een beperkt aantal gebruikers dus tokens en dat soort dingen lijken me wat tever gaan en zijn tevens te duur. Zijn er hier mensen met ervaring in dit soort dingen en hoe dit aan te pakken?

[Verwijderd]

Extreem gevoelige informatie laat je niet op een systeem staan waarvan je de beheerder niet kunt vertrouwen. En vertrouwen in de zin van: iemand heeft een geheimhoudingsplicht.

Dus je moet ofwel die informatie op een server in eigen beheer zetten, of je moet zorgen dat de beheerder een contract tekent.

[mocean]

Je kan dergelijke gegevens ook via apache definieren, als je apache gebruikt dan...
Hier staat het ongeveer uitgelegd:
http://www.garayed.com/ap...tom-variables-config.html

[Verwijderd]

Verwijderd schreef op dinsdag 08 augustus 2006 @ 20:10:
Extreem gevoelige informatie laat je niet op een systeem staan waarvan je de beheerder niet kunt vertrouwen. En vertrouwen in de zin van: iemand heeft een geheimhoudingsplicht.

Dus je moet ofwel die informatie op een server in eigen beheer zetten, of je moet zorgen dat de beheerder een contract tekent.

Tis wel een eigen bak overigens die ik deel met een maat van me. Probleem is echter dat het een W2k3 bak is en ik ben niet overtuigd van de veiligheid van W2k3. Ik ben eik als de dood dat de bak gehackt wordt en er op die manier gevoelige info uitlekt

[Verwijderd]

mocean schreef op dinsdag 08 augustus 2006 @ 20:11:
Je kan dergelijke gegevens ook via apache definieren, als je apache gebruikt dan...
Hier staat het ongeveer uitgelegd:
http://www.garayed.com/ap...tom-variables-config.html

Helaas, IIS

[Soultaker]

Als de gegevens niet tussen gebruikers (van de 'front end' dus) gedeeld hoeven worden, kun je ze versleutelen met (een hash van) het wachtwoord waarmee ook ingelogd wordt. Het versleutelen zelf gebeurt dan ook op de server dus daar heb je niets aan als de server niet betrouwbaar is (zoals Cheatah terecht zegt) maar zonder je code te bewerken of op een andere manier de webserver te compromitteren kan een hacker de gegevens niet lezen.

[BCC]

Ik weet niet hoor, maar je werkt volgens jezelf met extreem delicate informatie. Maar je slaat het op op een slecht beveiligde W2K machine (met IIS ) waarvan je de beheerder niet vertrouwd. Ik weet niet hoor, maar volgens mij ben je dan echt verkeerd bezig. Je kan er nog zoveel handige truuks tegenaan gooien, meet het is gewoon een kwestie van tijd totdat zo'n onveilige situatie misloopt.

[Verwijderd]

BCC, Windows Server 2003 (daar ging 't hier om) is prima te beveiligen, en een beetje hosting provider die virtual hosting op dat platform biedt zal daar ook wel voor gezorgd hebben.
Idem met IIS 6. Niet minder onveilig dan een virtual hosting site op een shared Linux/Apache bak.

Blijft over de kans dat eventueel systeembeheerders "in de MySQL tabel kunnen loeren". Dat risico heb je ook op een LAMP virtual hosting systeem, maar een goede hosting provider biedt garanties dat de data in de database nooit gebruikt zullen worden dan voor opslag.
En zelfs wanneer een systeembeheerder data onder ogen komt die 'ie niet had mogen zien zal 'ie zich wel 2x bedenken: misbruik kan 'm zijn baan kosten, en een goede systeembeheerder is 't ook z'n eer te na.

Maar de vraag "waar laat ik m'n encryptie-sleutel" is best relevant. In de VS en Canada mogen bv. creditcard nummers binnenkort niet meer unencrypted opgeslagen worden, en aan degene die ze opslaat worden een hoop eisen gesteld: de keys moeten veilig zijn, en om de paar maand gewijzigd worden.
Juist het veilig stellen van die keys is lastig, zeker wanneer je een scripttaal gebruikt als PHP, of een eenvoudig te disassemblen omgeving als Java of .NET.

De keys ophalen via SSL van een servertje in eigen beheer is dan denk ik de goedkoopste optie (en naar ik begrepen heb geaccepteerd door de VS en Canadese wetgeving).

[Verwijderd]

Verwijderd schreef op dinsdag 08 augustus 2006 @ 22:17:
BCC, Windows Server 2003 (daar ging 't hier om) is prima te beveiligen, en een beetje hosting provider die virtual hosting op dat platform biedt zal daar ook wel voor gezorgd hebben.
Idem met IIS 6. Niet minder onveilig dan een virtual hosting site op een shared Linux/Apache bak.

Mee eens, al ben ik wel van mening dat Linux/Apache in ieder geval een drempel is tegen script kiddies.

Blijft over de kans dat eventueel systeembeheerders "in de MySQL tabel kunnen loeren". Dat risico heb je ook op een LAMP virtual hosting systeem, maar een goede hosting provider biedt garanties dat de data in de database nooit gebruikt zullen worden dan voor opslag.
En zelfs wanneer een systeembeheerder data onder ogen komt die 'ie niet had mogen zien zal 'ie zich wel 2x bedenken: misbruik kan 'm zijn baan kosten, en een goede systeembeheerder is 't ook z'n eer te na.

Ik ben zelf systeembeheerder Ik ben dan ook niet bang voor mezelf, maar de bak is (zoals al gezegd dacht ik) ook van een maat van me. Ik zit vooral met de angst om ooit gehacked te worden, want niets is 100% save. Echter, mocht dat gebeuren dan wil ik niet gelijk hoeven te vrezen voor de info, omdat daar nog een extra stap voor nodig is die gewoon moeilijk te kraken is.

Maar de vraag "waar laat ik m'n encryptie-sleutel" is best relevant. In de VS en Canada mogen bv. creditcard nummers binnenkort niet meer unencrypted opgeslagen worden, en aan degene die ze opslaat worden een hoop eisen gesteld: de keys moeten veilig zijn, en om de paar maand gewijzigd worden.
Juist het veilig stellen van die keys is lastig, zeker wanneer je een scripttaal gebruikt als PHP, of een eenvoudig te disassemblen omgeving als Java of .NET.

En dat is met name het probleem, de key veiligstellen. Voor het data invoeren kan ik wel iets bedenken (is eenmalig zowat) maar het ophalen van de data moet voor de gebruikers (5 stuks ofzo) simpel zijn omdat ze geen computerkennis hebben.

De keys ophalen via SSL van een servertje in eigen beheer is dan denk ik de goedkoopste optie (en naar ik begrepen heb geaccepteerd door de VS en Canadese wetgeving).

Dat is een optie, alleen die eigen server komt alles op

Om iets meer details te geven, het gaat om het adresboek van mijn familie. We hebben onderwijl tig adreslijsten her en der en niet altijd beschikbaar. Ik wil die altijd beschikbaar hebben op een eenvoudige manier vanaf zowel thuis, werk als evt. een internet verbinding op een camping bij verlies van de lijst. Laatst liepen we tegen een overlijden aan van een familielid ver weg en ik moest adressen etc. hebben. Ik heb me de blubber gezocht op dat moment, en dat was niet handy. Nu staan de gegevens op een thuisserver die ik wel kan benaderen, maar met vakanties staat die uit (veiligheid) en ik vertrouw meer op Redbus met mijn provider dan op mijn huis/tuin/keuken provider waar de andere server staat. De gegevens moeten zo snel mogelijk en veilig te benaderen zijn.

Kortweg heeft de server 2 beheerders met admin rechten waarvan evt. wachtwoord geraden/gekraakt kan worden en draait er MySQL en PHP script, ik kan niet altijd overzien wat de lekken in evt. scripts zijn en ze ook niet altijd voor zijn. Mijn idee is dat als de data redelijk safe in de MySQL zit dat het dan de mensen die erin komen zoveel tijd kost om het te ontcijferen dat het gewoon teveel tijd kost. Als ik de key in een PHP file of een local file op de server prop is dat makkelijk te achterhalen. Ook het ophalen van de key ergens anders is eigenlijk nogal makkelijk uit broncode te trekken en dus te doen.

Maar eigenlijk is de vraag niet of mijn server wel beveiligd is en hoe veilig, want dat is eigenlijk het minst boeiend, daar vertrouw ik wel op op dit moment. Ik ben echt op zoek naar een manier om de data zo te encrypten dat het niet eenvoudig terug te halen is.

Volgens mij is het nog het meest veilig om de key elke keer via een form (jah, met de nodige beveiliging bij verzending van gegevens) in te voeren als er data opgehaald moet worden. Het is wel een extra code om te onthouden wat het lastiger maakt voor de gebruikers maar het lijkt me vrij safe. Het boeit dan ook niet dat mijn gebruikers de code opschrijven en meenemen in de portomonee. Zolang er geen URL bijstaat en de login/password combi om in te loggen WEL eenvoudig en te onthouden is dan heb je nog steeds safe gegevens bij diefstal van de portomonee oid. En bij diefstal is de key eenvoudig te changen. Met het form ding kan je dan een md5 hash van de huidige key meegeven en in de code de md5 key opslaan en die laten checken bij het opvragen van gegevens. Of zie ik dat verkeerd? Zitten er lekken in mijn gedachtegang of niet?

Alvast thx voor de reacties, het helpt in ieder geval al goed op weg!

[alienfruit]

Ik heb ook een server waar dit ook belangrijk waardoor we dus alles dicht gooien qua poorten behalve poort 80. Al het overige verkeer zoals beheer, shell e.d. staan allemaal dicht in principe zolang je van niet het niet vanaf onze vaste ip adres benadert wordt. Verder nog een paar van deze dingen zodat alleen maar bevoegde mensen er gebruik van kunnen maken (klanten) en niet een of andere lamlul.
Werkt tot heden aardig.

[Verwijderd]

Je kan een MD5 niet decoden .

Je kan wel de key encrypten, de data mee geven aan de gebruiker, en de key voor het decrypten van de data staan op de server. Mocht iemand jou server hacken, dan heeft hij de key om de data te decrypten die je familie op zak heeft. Zolang hij dan niet beschikt over de data van je familie zal hij nooit bij het wachtwoord van je database kunnen komen.

Je kan ook een 2e server plaatsen (of een gehackte router alla Sweex / Asus), deze via een seriele verbinding (en niets anders!) verbinden met de server. Een stukje software schrijven die de key continu via de seriele kabel uitleest. Zodra je een verkeerde request doet over de seriele kabel dan moet dat apparaat zichzelf uitschakelen.
Op deze manier worden de rootcertificate passwords/key's/etc bewaard van bijvoorbeeld CAcert.

[Tofu]

Kan je niet gewoon de ingelogde gebruiker gewoon 3 dingen laten opgeven: User, Pasw en Sleutel? Die sleutel zet je dan gewoon op papier wat je bij je hebt, non-digitaal, de beste beveiliging
Of denk ik nu te simpel?

[LionOne]

Verwijderd schreef op dinsdag 08 augustus 2006 @ 23:00:

....

Volgens mij is het nog het meest veilig om de key elke keer via een form (jah, met de nodige beveiliging bij verzending van gegevens) in te voeren als er data opgehaald moet worden. Het is wel een extra code om te onthouden wat het lastiger maakt voor de gebruikers maar het lijkt me vrij safe. Het boeit dan ook niet dat mijn gebruikers de code opschrijven en meenemen in de portomonee. Zolang er geen URL bijstaat en de login/password combi om in te loggen WEL eenvoudig en te onthouden is dan heb je nog steeds safe gegevens bij diefstal van de portomonee oid. En bij diefstal is de key eenvoudig te changen. Met het form ding kan je dan een md5 hash van de huidige key meegeven en in de code de md5 key opslaan en die laten checken bij het opvragen van gegevens. Of zie ik dat verkeerd? Zitten er lekken in mijn gedachtegang of niet?

Nou, lekken geen idee maar 'n punt wat je hierin niet moet vergeten heb ik wel, de kans dat een portemonnee verloren gaat met hierin een papiertje met de key, userid, wachtwoord en url, of dat het papiertje uit de portemonnee valt bij het pakken van bijv een bankpasje, is vele malen groter dan dat iemand je server kraakt en de key daar weg zou halen.

Niet vergeten hè, als het op wachtwoorden en moeilijk te onthouden dingen aankomt, zijn de meeste mensen hier heel makkelijk in, zeker als ze zelf het belang niet zo inzien....(iets wat al snel vervaagt wanneer de gemak zucht in het geding komt.)

Daarnaas bedenk ik me nog het volgende.
Als het de data is die zo belangrijk is en juist die data met een encryptie sleutel toegankelijk wordt, moet je er dus voor zorgen dat die key niet 'rond zwerft'.

Dit is eigenlijk wel een erg interessant probleem.... beide manieren (op de server of juist bij de gebruikers) zijn veilig, maar ja, bij de een heb je een key bij de data (op zich niet handig) en bij de ander heb je d'r geen zicht op. (zeker niet handig)

Ik zelf zou voor de server kiezen, enerzijds omdat ik wel zicht op de key zou willen hebben en anderzijds omdat, naar mijn idee, de ‘kans klein is dat de server gehacked wordt, de key wordt gevonden EN de DB ook daadwerkelijk wordt ingezien (of erger, gewijzigd).

[BCC]

Verwijderd schreef op dinsdag 08 augustus 2006 @ 22:17:
BCC, Windows Server 2003 (daar ging 't hier om) is prima te beveiligen, en een beetje hosting provider die virtual hosting op dat platform biedt zal daar ook wel voor gezorgd hebben.
Idem met IIS 6. Niet minder onveilig dan een virtual hosting site op een shared Linux/Apache bak.

Uiteraard, maar ik kreeg van de TS nou niet bepaald de indruk dat de server door een nette hosting provider beheerd werd.

Ik vind het trouwens nogal overdreven om een adressenboekje te encrypten met een remote key, maar goed.

Maar on topic: Kun je niet wat mooie dingen doen met PGP?

[ Voor 8% gewijzigd door BCC op 09-08-2006 00:50 ]