Database encrypten / 'afschermen'?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

P-ter AA

P-ter AA

08/02/2012 09:29:27
Quote Anchor link
Hallo,

Ik ben bezig met een eigen CMS. Dit CMS zou op mijn eigen server gaan draaien. De klant logt hier in, en kan zijn website aanpassen via het systeem. Alles wordt weggeschreven naar de database van de klant zelf (op zijn eigen server)

Afbeelding

Stel dat een klant na een jaar zegt te willen stoppen met het CMS (ik vraag een bedrag per jaar), dan wil ik niet dat bijvoorbeeld 'het neefje met wat verstand van PHP' een eigen CMS'je zou kunnen bouwen met mijn database.

Dus dacht ik de database te encrypten. Alleen moet de decryptie-functie ook op de server van de klant staan, dus daar schiet ik niets mee op.

Hoe zou ik dit kunnen oplossen? De database is van de klant, ik kan geen wachtwoorden achterhouden.

Alvast bedankt voor het meedenken!
Gewijzigd op 08/02/2012 09:34:50 door P-ter AA
 
PHP hulp

PHP hulp

22/05/2024 10:42:32
 
- SanThe -

- SanThe -

08/02/2012 11:09:36
Quote Anchor link
Ik snap het probleem waarschijnlijk niet.
Klant weg is toch site en database weg lijkt mij.
 
P-ter AA

P-ter AA

08/02/2012 14:42:42
Quote Anchor link
- SanThe - op 08/02/2012 11:09:36:
Ik snap het probleem waarschijnlijk niet.
Klant weg is toch site en database weg lijkt mij.


Nee, de website draait op de server van de klant. Daar heb ik niets over te zeggen. Het enige dat ik kan tegenhouden is het gebruik van het CMS indien de klant niet meer wilt betalen. Ik wil voorkomen dat iemand verder kan boorduren op de bestaande database van de klant (gegenereerd door mijn CMS).
 
Maikel Doeze

Maikel Doeze

08/02/2012 16:54:04
Quote Anchor link
Ik zie het probleem niet, een database maakt geen CMS. Een database is enkel het opslag medium met data welke feitelijk toebehoort aan de klant. Nieuwe wetgeving verplicht het zelfs de mogelijkheid tot export van data (en hiermee geef je ook je database structuur prijs).

Niet echt zinvol imho.

Quote:
Nee, de website draait op de server van de klant. Daar heb ik niets over te zeggen. Het enige dat ik kan tegenhouden is het gebruik van het CMS indien de klant niet meer wilt betalen.


In dat opzicht kun je dan beter zorgen dat of

a) Het CMS zelf geëncrypt is (Zend Guard bijvoorbeeld) http://www.zend.com/en/products/guard/
b) Het CMS draait op een afgeschermde omgeving in eigen beheer.
Gewijzigd op 08/02/2012 16:57:14 door Maikel Doeze
 
P-ter AA

P-ter AA

09/02/2012 13:59:17
Quote Anchor link
Maar het CMS draait ook op mijn eigen server. En vanuit mijn server wordt er naar de database op de server van de klant geschreven. Dus teksten worden in een WYSIWYG-editor aangepast, en vervolgens in de database van de klant gezet.

Maar als de klant stopt met het gebruik van het CMS, zou hij iemand anders een CMS'je kunnen laten maken op basis van de door mij ontworpen database. Maar als alle data ge-encrypt is, kan hij er niets mee.
 
Pim -

Pim -

09/02/2012 14:40:01
Quote Anchor link
Je kan gewoon op jouw server de html renderen en die dan via PHP FTP uploaden naar de server van de klant. Dan beschikt jouw klant even weinig over jouw code als elke willekeurige bezoeker.
 
P-ter AA

P-ter AA

09/02/2012 17:04:57
Quote Anchor link
Pim - op 09/02/2012 14:40:01:
Je kan gewoon op jouw server de html renderen en die dan via PHP FTP uploaden naar de server van de klant. Dan beschikt jouw klant even weinig over jouw code als elke willekeurige bezoeker.


Daar zat ik ook aan te denken.. Maar dan kan een website van de klant nooit dynamisch zijn..
 
Pim -

Pim -

09/02/2012 19:56:17
Quote Anchor link
Eventueel kan je die dynamische scripts (nieuwsbrief inschrijven ofzo) op je eigen server draaien, maar ik denk dat je heel veel situaties af kan vangen met statische HTML pagina's en eventueel wat javascript.
 
Joakim Broden

Joakim Broden

09/02/2012 21:21:57
Quote Anchor link
1. Als je toch CMS op je eigen server hebt staan waarom dan de websites van de klant niet op jouw server?
2. Of de database op jouw server hosten en daar de website van de mee laten connecten?
 
P-ter AA

P-ter AA

09/02/2012 21:53:09
Quote Anchor link
Pim - op 09/02/2012 19:56:17:
Eventueel kan je die dynamische scripts (nieuwsbrief inschrijven ofzo) op je eigen server draaien, maar ik denk dat je heel veel situaties af kan vangen met statische HTML pagina's en eventueel wat javascript.


Kan inderdaad, maar dat wordt wel echt een gedoe als ik meerdere klanten krijg. Alles door elkaar.

Hertog Jan op 09/02/2012 21:21:57:
1. Als je toch CMS op je eigen server hebt staan waarom dan de websites van de klant niet op jouw server?
2. Of de database op jouw server hosten en daar de website van de mee laten connecten?


Zit wat in, maar ik heb geen dedicated server. Maar misschien moet ik dit gewoon overwegen en ben ik inderdaad van dit probleem af.

Het leek mij alleen zo mooi als ik de website van mijn CMS 'los kon koppelen'. Zodat het op zich zelf zou kunnen staan.
 
Gerben G

Gerben G

10/02/2012 19:36:14
Quote Anchor link
Wat misschien een makkelijkere manier is om de data in de database te encrypten, en niet de hele database.

Stel je encrypt de html code die je WYSIWYG genereert, en slaat het vervolgens op in de database van de klant.
Bij het uitlezen hiervan (bestand wat nodig is voor de website) decrypt je dit weer. De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zodra de klant geen gebruik meer wil maken van je CMS zal de volledige website blijven werken.
 
P-ter AA

P-ter AA

10/02/2012 20:15:37
Quote Anchor link
Gerben G op 10/02/2012 19:36:14:
Wat misschien een makkelijkere manier is om de data in de database te encrypten, en niet de hele database.

Stel je encrypt de html code die je WYSIWYG genereert, en slaat het vervolgens op in de database van de klant.
Bij het uitlezen hiervan (bestand wat nodig is voor de website) decrypt je dit weer. De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zodra de klant geen gebruik meer wil maken van je CMS zal de volledige website blijven werken.


Was niet duidelijk merk ik nu, maar dit is precies wat ik bedoelde inderdaad! Het probleem is alleen dat de 'buurjongen' die encryptie-functie en decryptie-functie ook vindt en in zijn simpele CMS'je kan zetten.

Is dit te voorkomen?
 
Jeroen VD

Jeroen VD

10/02/2012 20:24:45
Quote Anchor link
Je kunt zelf een encrypt algoritme maken, of op meerdere manieren encrypten. Of je hasht alle gegevens, en gebruikt een dynamische salt die je opslaat in je eigen db.
 
Gerben G

Gerben G

10/02/2012 20:42:21
Quote Anchor link
@Maurice,
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
 
P-ter AA

P-ter AA

10/02/2012 20:48:55
Quote Anchor link
Jeroen vd op 10/02/2012 20:24:45:
Je kunt zelf een encrypt algoritme maken, of op meerdere manieren encrypten. Of je hasht alle gegevens, en gebruikt een dynamische salt die je opslaat in je eigen db.


Maar als ik die op sla in mijn database, moet het wachtwoord van mijn database in de code staan. En dan kunnen ze nog de salt ophalen..

Gerben G op 10/02/2012 20:42:21:
@Maurice,
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.


Maar dan kunnen ze toch ook gewoon de decrypt-functie gebruiken?
 
Kees Schepers

kees Schepers

10/02/2012 21:26:36
Quote Anchor link
Gerben G op 10/02/2012 20:42:21:
@Maurice,
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.


Met Zend Guard encrypt je het niet maar doe je het precompilen. Dus wat je dan doet is het werk van de PHP module in apache alvast (de PHP interpeter), die doet je PHP compilen naar bytecode, dus binair. Binaire code is zo goed als onmogelijk terug te draaien naar leesbaar PHP.

Het is een performance winst en beveiliging van je applicatie eigenlijk.

Verder zou ik de data in je database absoluut niet encrypten. Dat is een enorme performance killer. Ik zou het hosten op een eigen server, virtueel eventueel.
 
Jeroen VD

Jeroen VD

10/02/2012 21:27:05
Quote Anchor link
Er zijn encrypt methoden die je niet kunt decrypten als je alleen de uitkomst weet
 
P-ter AA

P-ter AA

11/02/2012 00:02:02
Quote Anchor link
Kees Schepers op 10/02/2012 21:26:36:
Gerben G op 10/02/2012 20:42:21:
@Maurice,
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.

Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.


Met Zend Guard encrypt je het niet maar doe je het precompilen. Dus wat je dan doet is het werk van de PHP module in apache alvast (de PHP interpeter), die doet je PHP compilen naar bytecode, dus binair. Binaire code is zo goed als onmogelijk terug te draaien naar leesbaar PHP.

Het is een performance winst en beveiliging van je applicatie eigenlijk.

Verder zou ik de data in je database absoluut niet encrypten. Dat is een enorme performance killer. Ik zou het hosten op een eigen server, virtueel eventueel.


Oke! Dat is wel een goed idee. Moet me toch maar eens in Zend gaan verdiepen. Bevat Zend misschien ook een functie waarmee het mogelijk is een query uit te voeren op een eerder gedane query? Adobe Coldfusion heeft die mogelijkheid. Zo hoeft de database alleen maar bij de 1e query aangeroepen te worden.


Jeroen vd op 10/02/2012 21:27:05:
Er zijn encrypt methoden die je niet kunt decrypten als je alleen de uitkomst weet


Waar moet ik dan aan denken? Maar als ik de uitkomst al weet, bereik ik er toch niets mee?
 
Jeroen VD

Jeroen VD

11/02/2012 00:11:40
Quote Anchor link
Uit een hash-uitkomst kan je volgens mij niet het oorspronkele bericht krijgen. Maar ik had er niet aan gedacht dat je het alleen wil opvragen, geen controle. Dus kun je beter niet hashen
 
Eddy B

Eddy B

11/02/2012 01:58:45
Quote Anchor link
Waarom moet de database perse op de server staan van de klant? Ik zelf hou de database in eigen beheer en geef de klant daarvan de inloggegevens. Natuurlijk kan de klant een export uitdraaien, maar goed.. dat risico loop je. Daarnaast is een database structuur over het algemeen makkelijk in elkaar te flansen, met bijv. varchar(2000) op elk veld.

Accepteer gewoon je verlies als de klant dat doet, de bug's en dergelijke krijgt de klant op de koop toe. Natuurlijk kan je ook de export functie uitzetten, maar daar maak je geen vrienden mee. En zelfs dan.. is het mogelijk d.m.v. inserts en updates de structuur te kopiëren.

Dus accepteer je verlies en/of laat de klant een contract tekenen waarin de klant verklaard database structuren en programmatuur nooit te zullen kopiëren.
 
P-ter AA

P-ter AA

11/02/2012 08:37:33
Quote Anchor link
Eddy Bisschops op 11/02/2012 01:58:45:
Waarom moet de database perse op de server staan van de klant? Ik zelf hou de database in eigen beheer en geef de klant daarvan de inloggegevens. Natuurlijk kan de klant een export uitdraaien, maar goed.. dat risico loop je. Daarnaast is een database structuur over het algemeen makkelijk in elkaar te flansen, met bijv. varchar(2000) op elk veld.

Accepteer gewoon je verlies als de klant dat doet, de bug's en dergelijke krijgt de klant op de koop toe. Natuurlijk kan je ook de export functie uitzetten, maar daar maak je geen vrienden mee. En zelfs dan.. is het mogelijk d.m.v. inserts en updates de structuur te kopiëren.

Dus accepteer je verlies en/of laat de klant een contract tekenen waarin de klant verklaard database structuren en programmatuur nooit te zullen kopiëren.


Ik denk dat ik dit dan maar moet doen inderdaad.

Iedereen heel erg bedankt! Fijn dat er zo wordt meegedacht. Ik ga me eens verdiepen in Zend en ga accepteer het als een klant dingen zou willen overnemen. Indien ik de klante tevreden hou is dit natuurlijk allemaal niet nodig.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.