[PHP] licentiesysteem

woensdag 16 februari 2011 22:02

Acties:

0 Henk 'm!

Topicstarter

De situatie:
Ik heb een webapplicatie lopen die gebruikers toe laat staan om hun download servertje te beheren (Download's toevoegen, bekijken enzovoort.). Nu heb ik meerdere keren het verzoek gehad om het script beschikbaar te stellen voor eigen hosting. Dit vinden de eind gebruikers fijner omdat ze dan hun eigen gegevens in handen hebben. (Begrijpelijk uiteraard)

Nu wil ik dit gaan doen, op licentie basis, zodat gebruikers het script niet kunnen delen. (Daarnaast komt de prijs laag te liggen, denk aan 5 euro ofzo) Alleen ben ik een beetje aan het dubben hoe ik dit het beste kan doen.

Wat ik tot nu toe voor ogen heb:

Een client heeft een key, deze is uniek natuurlijk.
Bij het eerste gebruik wordt deze key aan het IP van de webserver gekoppeld.

Bij bepaalde handelingen wordt deze key geverifieerd met mijn server key server. Mocht er wat mis zijn met de key (IP anders ofzo) dan wordt de key geblokkeerd en kan de gebruiker geen gebruik meer maken van zijn licentie en moet hij contact met mij op nemen.

Nu is mijn vraag aan jullie: hoe zou ik dit het beste kunnen realiseren?
Zou ik de client CURL kunnen laten doen naar mijn server? Hoe kan ik op de client kant het beste registreren dat de licentie niet meer geldig is?

Uiteraard wil ik er voor zorgen dat het zo 'moeilijk mogelijk' te nullen is.

Bedankt!

woensdag 16 februari 2011 22:04

Acties:

0 Henk 'm!

Verwijderd

Zend Guard

woensdag 16 februari 2011 22:05

Acties:

0 Henk 'm!

CodeCaster

Can I get uhm...

Je PHP obfuscaten en een challenge-responsesysteem implementeren natuurlijk.

Ik zal omdat ik in een goede bui ben mijn twee opmerkingen toelichten. Obfuscaten zul je moeten doen omdat ze anders de verificatie simpelweg uit je code kunnen slopen en challenge-response omdat ze anders jouw server kunnen naspelen die simpelweg een "ja hoor, de key is ok, laat de beheerder maar inloggen!" terugstuurt.

Dus, wat had je zelf zoal bedacht en gevonden?

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...

woensdag 16 februari 2011 22:06

Acties:

0 Henk 'm!

t1mmy

Topicstarter

Verwijderd schreef op woensdag 16 februari 2011 @ 22:04:
Zend Guard

Kost geld en aangezien het om een klein projectje gaat wil ik de kosten drukken.

woensdag 16 februari 2011 22:08

Acties:

0 Henk 'm!

Verwijderd

t1mmy schreef op woensdag 16 februari 2011 @ 22:06:

Kost geld en aangezien het om een klein projectje gaat wil ik de kosten drukken.

Je zei niet dat het geen geld mocht kosten. Veel succes met klooien dan. Producten als Zend Guard bestaan met een reden.

woensdag 16 februari 2011 22:09

Acties:

0 Henk 'm!

Aloys

Ik denk dat dit verschrikkelijk moeilijk gaat worden, omdat de persoon het script kan inkijken. Bij normale programma's is de broncode niet (of moeilijker) te bekijken. PHP is echter niet precompiled, dus gooi de checks eruit en klaar.

woensdag 16 februari 2011 22:11

Acties:

0 Henk 'm!

mrc4nl

Procrastinatie expert

tja, je kan het misschien compilen, maar dan dat is geen 100% veilige oplossing(decompiles kan namelijk ook)
maar de source is dan in ieder geval niet 123 aanpasbaar/leesbaar

ora et labora

woensdag 16 februari 2011 22:14

Acties:

0 Henk 'm!

t1mmy

Topicstarter

CodeCaster schreef op woensdag 16 februari 2011 @ 22:05:
Je PHP obfuscaten en een challenge-responsesysteem implementeren natuurlijk.

Ik zal omdat ik in een goede bui ben mijn twee opmerkingen toelichten. Obfuscaten zul je moeten doen omdat ze anders de verificatie simpelweg uit je code kunnen slopen en challenge-response omdat ze anders jouw server kunnen naspelen die simpelweg een "ja hoor, de key is ok, laat de beheerder maar inloggen!" terugstuurt.

Dus, wat had je zelf zoal bedacht en gevonden?

Dat is inderdaad ook een goede oplossing maar uiteraard moet er daarnaast een goed licentie systeem komen. Daarvoor had ik jullie input nodig.

Verwijderd schreef op woensdag 16 februari 2011 @ 22:08:
[...]

Je zei niet dat het geen geld mocht kosten. Veel succes met klooien dan. Producten als Zend Guard bestaan met een reden.

Als ik licenties voor 5 euro of less wil gaan verkopen is het toch niet rendabel om een programma van 600 dollar aan te schaffen? Daarnaast heeft dit ook nog eens aanpassingen aan de client side nodig wat totaal niet handig is.

Aloys schreef op woensdag 16 februari 2011 @ 22:09:
Ik denk dat dit verschrikkelijk moeilijk gaat worden, omdat de persoon het script kan inkijken. Bij normale programma's is de broncode niet (of moeilijker) te bekijken. PHP is echter niet precompiled, dus gooi de checks eruit en klaar.

Sowieso was ik van plan de check niet in 1 bepaald bestand te doen maar op verschillende plekken en met verschillende namen. Daarnaast zou ik de code nog extra onleesbaar kunnen maken, alles helpt.

mrc4nl schreef op woensdag 16 februari 2011 @ 22:11:
tja, je kan het misschien compilen, maar dan dat is geen 100% veilige oplossing(decompiles kan namelijk ook)
maar de source is dan in ieder geval niet 123 aanpasbaar/leesbaar

Dat is inderdaad ook een oplossing.

Maar nu wijken we eigenlijk af van mijn vraag, hoe ik de code ga 'compilen' ga ik bedenken in een later stadium.
Mijn vraag was eigenlijk, in hoe verre is het stukje systeem wat ik nu bedacht heb reëel en, zou het werken op deze manier? Hebben jullie nog nuttige toevoegingen op mijn idee?
Hoe zouden scripts zoals VBulletin dit doen?

[ Voor 6% gewijzigd door t1mmy op 16-02-2011 22:16 ]

woensdag 16 februari 2011 22:22

Acties:

0 Henk 'm!

hell4you

Wellicht is dit niet eens mogelijk, maar de enige realistische oplossing die ik hiervoor kan bedenken is om toch zelf zo veel mogelijk code te hosten. Daarnaast laat je de klant kleine scripts draaien op hun eigen server om de files te plaatsen.
Dit vereist natuurlijk een goede samenwerking tussen beide webservers. Wellicht iets met javascript?

Hiermee bereik je dat de scripts bij de klant op zich waardeloos zijn en dat je de code in eigen hand nog steeds voor een bepaalde klant uit kan schakelen. Als je het dan heel mooi wil maken zorg je ervoor dat de code in eigen beheer compleet generiek is voor alle klanten.

Nogmaals, ik kan niet goed inschatten of dit voor jouw applicatie ook toepasbaar is, maar zonder obfuscating is dit een van de weinige reële oplossingen

woensdag 16 februari 2011 22:26

Acties:

0 Henk 'm!

GlowMouse

Op wat voor webserver moet het draaien? Je kunt je php-code compilen tot webserver.

woensdag 16 februari 2011 22:27

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Php

hell4you schreef op woensdag 16 februari 2011 @ 22:22:
Wellicht iets met javascript?

Ja joh, dat werkt zo lekker cross domain en dan ook nog eens in alle browsers want JS is altijd beschikbaar!

hell4you schreef op woensdag 16 februari 2011 @ 22:22:
een van de weinige reële oplossingen

Nog minder reël dan 'met de hand obfuscaten'

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 16 februari 2011 22:30

Acties:

0 Henk 'm!

Smashmint

Veel van dat soort scripts maken gebruik van Ioncube, dan is de php code niet meer beschikbaar voor de eindgebruiker

woensdag 16 februari 2011 22:30

Acties:

0 Henk 'm!

CodeCaster

Can I get uhm...

Wat je natuurlijk ook kan doen is de mensen de code geven maar aanbieden de data betaald te hosten. Dan laat je bestanden uploaden naar jouw server en op te slaan met het klant-ID. Betalen ze niet meer dan haal je de bestanden van die klant offline.

Willen ze dan zelf of elders goedkoper hosten dan zullen ze het server-gedeelte moeten reverse engineeren (moeite doen) of bij jou kopen.
Laat maar, je host geen downloadserverapplicatie maar een beheertool daarvan.

[ Voor 32% gewijzigd door CodeCaster op 16-02-2011 22:32 ]

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...

woensdag 16 februari 2011 22:32

Acties:

0 Henk 'm!

t1mmy

Topicstarter

hell4you schreef op woensdag 16 februari 2011 @ 22:22:
Wellicht is dit niet eens mogelijk, maar de enige realistische oplossing die ik hiervoor kan bedenken is om toch zelf zo veel mogelijk code te hosten. Daarnaast laat je de klant kleine scripts draaien op hun eigen server om de files te plaatsen.
Dit vereist natuurlijk een goede samenwerking tussen beide webservers. Wellicht iets met javascript?

Hiermee bereik je dat de scripts bij de klant op zich waardeloos zijn en dat je de code in eigen hand nog steeds voor een bepaalde klant uit kan schakelen. Als je het dan heel mooi wil maken zorg je ervoor dat de code in eigen beheer compleet generiek is voor alle klanten.

Nogmaals, ik kan niet goed inschatten of dit voor jouw applicatie ook toepasbaar is, maar zonder obfuscating is dit een van de weinige reële oplossingen

Erg bedankt voor je toevoeging maar ik denk niet dat dit reëel zal zijn. Dan zullen er namelijk alsnog gegevens over mijn server lopen en dat is juist het dingen wat ik probeer te omzeilen hier mee.

GlowMouse schreef op woensdag 16 februari 2011 @ 22:26:
Op wat voor webserver moet het draaien? Je kunt je php-code compilen tot webserver.

Ik denk niet dat dit reëel is omdat het bij-wijze-van op usbwebserver zou moeten kunnen draaien, erg basic dus.
Met de hand obfuscaten wordt denk ik wel de oplossing om code te 'beveiligen', veel HTML vervangen voor unicode (Of hoe heet dat ook al weer?

) en alles achter elkaar plakken.

Inktpotje schreef op woensdag 16 februari 2011 @ 22:30:
Veel van dat soort scripts maken gebruikt van Ioncube, dat is de php code niet meer beschikbaar voor de eindgebruiker

Ik zal er naar kijken!

@CodeMaster, juist!

Omdat ik niet gemarkeerd als spam wilde worden heb ik in eerste instantie niet genoemd waarom het ging maar, het gaat over WebSAB Met deze webapplicatie voor iOs kun je je SABnzbd+ server bedienen.

[ Voor 8% gewijzigd door t1mmy op 16-02-2011 22:33 ]

woensdag 16 februari 2011 22:36

Acties:

0 Henk 'm!

Verwijderd

Met ioncube kan je dacht ik een aantal bestanden voor enkele dollars online laten encoden. Maar dan moet de ontvangende partij wel de ioncube bestanden kunnen laden.

woensdag 16 februari 2011 22:38

Acties:

0 Henk 'm!

t1mmy

Topicstarter

Verwijderd schreef op woensdag 16 februari 2011 @ 22:36:
Met ioncube kan je dacht ik een aantal bestanden voor enkele dollars online laten encoden. Maar dan moet de ontvangende partij wel de ioncube bestanden kunnen laden.

Hmm, dat zag ik inderdaad en dat is niet écht een optie denk ik.

woensdag 16 februari 2011 22:40

Acties:

0 Henk 'm!

Verwijderd

t1mmy schreef op woensdag 16 februari 2011 @ 22:32:
[...]
Omdat ik niet gemarkeerd als spam wilde worden heb ik in eerste instantie niet genoemd waarom het ging maar, het gaat over WebSAB Met deze webapplicatie voor iOs kun je je SABnzbd+ server bedienen.

Heb ik toch liever de mobile interface van sab zelf http://sabadres/m

woensdag 16 februari 2011 22:46

Acties:

0 Henk 'm!

t1mmy

Topicstarter

Verwijderd schreef op woensdag 16 februari 2011 @ 22:40:
[...]

Heb ik toch liever de mobile interface van sab zelf http://sabadres/m

Alleen kan je daarmee niet direct via de zoek functie NZB's toevoegen. (En trouwens, merk het net, hij werkt niet bij mij

)

[ Voor 9% gewijzigd door t1mmy op 16-02-2011 22:51 ]

woensdag 16 februari 2011 22:57

Acties:

0 Henk 'm!

Verwijderd

t1mmy schreef op woensdag 16 februari 2011 @ 22:46:
[...]

Alleen kan je daarmee niet direct via de zoek functie NZB's toevoegen. (En trouwens, merk het net, hij werkt niet bij mij )

Secondary interface instellen

Verder heb je gelijk

woensdag 16 februari 2011 23:02

Acties:

0 Henk 'm!

fds

De gouden tip: kijk eens naar php-screw op SourceForge.

Dit gaat een stuk verder dan obfuscaten.
Je kan een licentie systeem dan gewoon in PHP maken of integreren in php-screw.

Het laatste heb ik gedaan.
Alleen ben ik hierin een beetje doorgeschoten, want ik heb het idee nu ook gebruikt voor shell scripts. Hierdoor kan ik alle scripttalen (bash, perl, python, php, ...) beveiligen. Echt super.

woensdag 16 februari 2011 23:42

Acties:

0 Henk 'm!

Brummetje

Ginkeltjes

Aangezien het gewoon een script is om je Sab server aan te sturen is het dan niet een idee om gewoon een App te maken voor iOS ? Op deze manier staat het programma gewoon bij hun op de telefoon en kun je misschien op jou server de rest afhandelen + dat je dan een check kan doen op jou server i.v.m. de licentie.

woensdag 16 februari 2011 23:51

Acties:

0 Henk 'm!

RaZ

Funky Cold Medina

Je kan toch een webservice maken, en met API calls gaan werken. Als ik Google Maps wil op m'n website moet ik ook een key ophalen (die wordt gegenereerd door de domeinnaam in te voeren), en die kan ik zelf gewoon uitlezen. Maar de servers van Google doen de rest.

Dan bepaal jij serverside aan jouw kant of die key klopt, en of ie wel of niet verlopen is. Die keys zijn dan ook niet uitwisselbaar. Lijkt me toch veilig genoeg?

Ey!! Macarena \o/

donderdag 17 februari 2011 00:00

Acties:

0 Henk 'm!

WouZz

Elvis is alive!

Samengevat heb je volgens mij (onder meer) de volgende opties:

Gebruik en distributie juridisch dicht timmeren met een op maat gemaakte commerciële licentie
Proberen de code te obfuscaten, maar dan kan het alsnog (illegaal) geherdistribueerd worden als je geen extra dependencies introduceert.
Je script ombouwen naar een SaaS oplossing
Je script onder een open source licentie vrijgeven en geld vragen voor support.
Je IP protected code in een gecontroleerde omgeving (App store?) distribueren

Ik zou kiezen voor de SaaS oplossing, dan hoef je je code niet vrij te geven en heb je direct controle op het gebruik. Dit vereist natuurlijk wel enig extra werk.

On track

donderdag 17 februari 2011 00:07

Acties:

0 Henk 'm!

krvabo

MATERIALISE!

Verwijderd schreef op woensdag 16 februari 2011 @ 22:36:
Met ioncube kan je dacht ik een aantal bestanden voor enkele dollars online laten encoden. Maar dan moet de ontvangende partij wel de ioncube bestanden kunnen laden.

Klopt, Ioncube wordt ook vrij veel gebruikt (en ondersteund), maar net als Zend-encoded files zijn ze ook online vrij makkelijk te (laten) decoden

Als je een webservice kunt maken die een essentieel stuk code uitvoert (voor zoverre toepasbaar) is het mogelijk het zonder encoden te beveiligen. Zolang de code leesbaar is, is het te 'hacken'.
Ik zie echter niet snel een mogelijkheid een essentiële functie op een webservice te zetten voor iets wat zo zwaar afhankelijk is van de server zelf. Wellicht kun je het uitlezen van nzb-info uit de nzb op een webservice doen, maar dat gebruikt wel veel bandbreedte lijkt me.

Pong is probably the best designed shooter in the world.
It's the only one that is made so that if you camp, you die.

donderdag 17 februari 2011 09:25

Acties:

0 Henk 'm!

YopY

t1mmy schreef op woensdag 16 februari 2011 @ 22:14:
Hoe zouden scripts zoals VBulletin dit doen?

vzviw doet vB dat op een aantal manieren:

* Hij vraagt om je klantnummer bij de installatie. Waarschijnlijk neemt het script contact op met de vB servers om je licentie na te kijken.
* Semi-regelmatig 'phone home' doen, licentie nakijken.

Maar vBulletin doet verder niet aan obfuscation, je bent vrij om die validatie eruit te slopen (en de pirated versies van vB hebben dat ook gedaan). Wat vB echter doet (denk ik) is een crawler inzetten die vB websites herkent en de gehoste locatie vergelijkt met zijn eigen database van bekende vB installaties (dat wordt ook bij hun geregistreerd - een vB licentie is gekoppeld aan een domein). Een crawler, dus.

Maar nu moet je natuurlijk jezelf wel even een paar dingen afvragen. Is het voor die 5 euro per licentie wel waard om vele uren te besteden aan beveiliging? Ik bedoel, zelfs een beginnende ontwikkelaar kan zo 50 euro per uur vragen, en als dit echt om geld te verdienen is zul je dat ook in je achterhoofd moeten houden. 5 euro per licentie zal geen vetpot zijn (geloof niet dat je applicatie een enorme verkoophit zal zijn), dus dat lijkt me verder niet.

Wat ik zou doen: Hou het eenvoudig. Bouw gewoon een eenvoudig licentiesysteem in (key, phone home, challenge/response oid) en obfuscate je code met een open source obfuscator. Spendeer er vooral niet al teveel tijd aan - hou gewoon in het achterhoofd dat, áls ze het willen kraken, het ze wel lukt (en waarschijnlijk in minder tijd dan het jou kost om een licentiesysteem in elkaar te flansen)

donderdag 17 februari 2011 10:40

Acties:

0 Henk 'm!

soczol

Doet iets met energie

Je hebt nu wel het voordeel dat de mensen die jouw software aanschaffen dit doen met het doel iets van internet te downloaden en de machine waarop jouw software draait dus toegang zal hebben tot internet. Anders wordt activeren, etc. al een stuk moeilijker omdat je dan ook rekening moet gaan houden met off-line activatie etc.

Houd je echter ook even in het achterhoofd wat er gebeurd als jouw server niet te bereiken is? Kunnen mensen dan geen gebruik maken van jouw software totdat jouw server weer bereikbaar is? Het lijkt mij dat je wel iets van een "grace period" moet willen hebben waarbij jouw software iets van 7, 14, 30 dagen gewoon door kan draaien zonder dat er enig contact is geweest met jouw licenseserver.

Tevens wil je over het algemeen dat eventuele "phone home" checks in de achtergrond draaien en dat de gebruiker daar dus niet op hoeft te wachten. Als je server plat ligt kan het makkelijk 30 seconden (misschien is dat configurable, maar de default connection timeout ligt meestal rond die waarde) duren voordat een HTTP client het opgeeft.

Verder is de vraag in hoeverre je de gebruiker wilt beperken. Mogen zij het op elk systeem installeren, of mogen ze het enkel op 1, 2, .. 50 server(s) installeren?

Veel activatiesystemen die ik ken bouwen een SSL sessie op met de licentieserver waarbij de public key van het servercertificaat vergeleken wordt, als iemand er dus een ander certificaat inknalt dan zal het niet meer werken. Vervolgens stuurt de de client wat informatie over het huidige systeem doorgeeft, bijvoorbeeld:

XML:

<request>
  <key>license-key</key>
  <mac>00:11:22:33:44:55</mac>
  <private_ip>192.168.0.0</private_ip>
  .. meer info..
</request>

De server leest deze informatie, kijkt of 't keytje nog geldig is, of er niet teveel MAC addressen onder een key hangen, etc. Vervolgens antwoord de server met een simpele "ok" of "failed":

XML:

1
2
3

<response>
  <result>ok</result>
</response>

Zegt de server "failed" dan verwijdert de client de license key uit z'n configuratie en is de software weer in z'n standaard "activeren alstublieft"-modus.

Natuurlijk zul je dit soort code wel moeten obfuscaten omdat iemand anders gewoon jouw public key kan vervangen door die van hun en dan zelf licenseserver kan spelen, of natuurlijk gewoon heel je license check eruit sloopt. Ook kost je dit een certificaat, al kun je er natuurlijk voor kiezen om een self signed iets te doen.

Maargoed, waarschijnlijk ga ik hierin iets te ver

en kun je met een simpel challenge-response systeem ook al ver komen.

Trouwens: Een aantal producten die ik ken kiezen er voor om alle licentiechecks etc. in een belangrijke centrale PHP file te hangen (bijvoorbeeld "index.php"), samen met de rest van de belangrijke code, en alleen die file te obfuscaten met ionCube. Dat is een stuk betaalbaarder en nogsteeds erg veilig. Afgezien van wat mensen zeggen is de laatste ionCube release nogsteeds niet gekraakt.

[ Voor 11% gewijzigd door soczol op 17-02-2011 11:22 . Reden: xml tags ]

donderdag 17 februari 2011 11:47

Acties:

0 Henk 'm!

Janoz

Moderator Devschuur®

!litemod

Php

Als het gaat om het makkelijk aansturen van een sabnzbd vanaf een iPhone of iPad, waarom maak je er dan geen ios applicatie van? Dat is een stuk makkelijker 'dicht te zetten' en ook de betalingen zijn een stuk simpeler te regelen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

donderdag 17 februari 2011 12:28

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Php

soczol schreef op donderdag 17 februari 2011 @ 10:40:
Je hebt nu wel het voordeel dat de mensen die jouw software aanschaffen dit doen met het doel iets van internet te downloaden

offtopic:
Laten we wel wezen, in veel gevallen is dat spul (ongeacht de legale definitie en het hele welles/nietes over legaal downloaden) natuurlijk niet helemaal 'legaal'. Diezelfde mensen zullen er ook niet mee zitten een crack/serial/"aangepaste_versie" te gebruiken

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 17 februari 2011 20:37

Acties:

0 Henk 'm!

Jory

RobIII schreef op donderdag 17 februari 2011 @ 12:28:
[...]

offtopic:
Laten we wel wezen, in veel gevallen is dat spul (ongeacht de legale definitie en het hele welles/nietes over legaal downloaden) natuurlijk niet helemaal 'legaal'. Diezelfde mensen zullen er ook niet mee zitten een crack/serial/"aangepaste_versie" te gebruiken

Aan de andere kant, als ik voor €5 iets heb gekocht en iemand anders wil dat ook, zeg ik niet "oke, ik zal eens kijken of ik de beveiliging eruit kan slopen", dan zeg ik "kost €5, kun je op website kopen".

En ook de andere kant op, als ik via-via aan een versie kan komen die gratis is als ik de beveiliging eruit sloop, of voor €5 aan een "officiele" versie, dan is het me die tijd niet eens waard.

Onderwerpen