[ALG / DISC] Klanten binden aan licentie

[Reveller]

Eindelijk is het zover: mijn eigen CMS'je is bijna klaar. Binnenkort wil ik deze gaan verkopen, en ik heb hier een aantal vragen over. Sommige klanten zullen het cms kopen en op hun eigen (bestaande) hosting account of server willen installeren. Andere zullen graag ook de hosting door mij willen laten regelen. Hiervoor kan ik een reseller account of VPS account nemen.

Ik heb gezocht naar een betalingsmodel waarbij ik een constante cashflow genereer, in plaats van pieken en dalen in de inkomsten te hebben. Ik ben van plan mijn systeempje voor 1699 ex BTW te verkopen. Daar komt nog wat bovenop als een klant bijvoorbeeld de site in een eigen layout wil en ik dat voor hem moet doen. Vanaf het tweede jaar betaalt de klant 30% van de aanschafprijs als jaarlijkse licentie. Deze licentie moet een maand voor het verstrijken van het jaar vernieuwd worden.

Zolang ik voor mijn klanten op een eigen reseller account host, is er geen probleem. Zou een klant niet willen / kunnen betalen, dan kan ik zijn site afsluiten. Moeilijker is het als ik het systeem uit handen gegeven heb en een klant het op een eigen server draait. Als hij / zij dan de licentie niet wil betalen, hoe zorg ik er dan voor dat de code stopt met werken?

Ik heb aan een aantal oplossingen gedacht:

• als ik de code encrypt met de Zend Safeguard Suite, kan ik een datum instellen waarop de code moet stoppen met werken. Dit is volgens mij makkelijk te omzeilen door de systeemklok terug te zetten, dus is niet bullet-proof
• een tweede mogelijkheid is om elke cms-installatie verbinding te laten leggen met mijn eigen website, welke wel altijd de goede tijd zal teruggeven, en aan de hand daarvan de code wel / niet laten uitvoeren. Nadeel: heel veel queries naar mijn site, dus een behoorlijke belasting, en een vertraging op de uitvoering van de code bij de klant. Deze moet immers wachten op een reaktie van mijn site. Eventuele oplossing: niet bij elke klik, maar bv. elke dag 1 keer laten checken. Aandachtspunt: wat als mijn eigen site uit de lucht zou liggen en er geen verbinding kan worden gelegd. Misschien beter om te pingen naar een soort van "worldtimeclock.com" site?
• je kunt het voor de klant aantrekkelijk maken om die licentie te willen kopen. Bijvoorbeeld, licentie is inclusief 5 gratis programmeer uren als klant een uitbreiding op / aanpassing van het systeem zou willen. Wanneer de klant de licentie niet betaalt, en een jaar later weer wel wil betalen, kost de eerste licentie na een onderbroken periode weer het volle pond (dus: 1699 ex. btw)

Een tweede vraag: ik wil de klant niet beperken door te stellen dat hij bij mij moet hosten. Als hij / zij een eigen server of hostingpakket heeft en daarop wil hosten, mag dat geen reden zijn om een potentiele klant te verliezen. Maar ik ben wat angstig dat iemand, op het moment dat je de code (al dan niet encrypt) op een CD'tje uit handen geeft, deze misschien doorverkocht gaat worden. Om te zien hoeveel installaties er van mijn cms zijn, dacht ik eraan om elke installatie automatisch eens per week ofzo te laten pingen naar mijn site. Dan kan ik zien op welk IP mijn cms geinstalleerd is en contact opnemen met mensen die een illegale versie hebben draaien.

Wat vinden jullie van dit alles? Ik hoor graag jullie ideeen / commentaar / aanvullingen op dit verhaal!

[NMe]

Ik zou zelf niet eens overwegen om er een beveiliging in te zetten. Het is simpel: je klant betaalt licentiekosten -> hij krijgt het recht om je CMS te gebruiken. Betaalt hij niet, maar laat hij de site wel online staan, dan kun je dat aanvechten, en je zal het nog winnen ook, mits je je contracten vantevoren goed opgesteld hebt.

Je kan wel allerlei soorten beveiligingen bedenken, maar allemaal hebben ze wel een nadeel en geen van allen is waterdicht.

[Mithrandir]

Verwacht je werkelijk dat een bedrijf de systeemklok van een server achteruit gaat zetten om de licentie van kracht te laten houden? Ik denk dat zoiets doen uiteindelijk duurder is dan de licentiekosten betalen voor je systeem. Ze zullen bijvoorbeeld geen newsposts meer kunnen doen vanaf die datum (en anders lijkt het 'oud' nieuws). Wat je ook kunt doen is zodra je merkt dat de datum voorbij is een key uit de database verwijderen, waardoor als ze daarna de datum weer terugzetten het nog steeds niet werkt.

Als je zoiets hebt gedaan is het denk ik voor 99,99% van de bedrijven meer dan afdoende beveiliging gecreëerd.

[dingstje]

-NMe- schreef op zondag 13 november 2005 @ 14:32:
Ik zou zelf niet eens overwegen om er een beveiliging in te zetten. Het is simpel: je klant betaalt licentiekosten -> hij krijgt het recht om je CMS te gebruiken. Betaalt hij niet, maar laat hij de site wel online staan, dan kun je dat aanvechten, en je zal het nog winnen ook, mits je je contracten vantevoren goed opgesteld hebt.

Je kan wel allerlei soorten beveiligingen bedenken, maar allemaal hebben ze wel een nadeel en geen van allen is waterdicht.

Je kan inderdaad je directe klanten aanspreken en eventueel aanklagen bij misbruik, maar als zij het zelf doorgeven aan een ander bedrijf (bij grote bedrijven zal dit waarschijnlijk niet veel gebeuren, maar eenmaal je gaat verkopen aan KMO's zal dit wel vaker voorkomen denk ik) heb je hier geen controle meer op. Dat zou je eventueel nog kunnen omzeilen door je CMS vast te haken aan één IP of één host. Aangezien het op een server draait zal dit weinig/nooit veranderen. Op die manier kunnen ze het niet doorgeven aan elkaar en heb jij controle over op welke systemen je applicatie draait. Dan kun je na het verlopen van de licentie gaan controleren of het bedrijf nog gebruik maakt van je systeem (dit zou je kunnen controleren door op elke pagina ergens een HTML-comment onderaan weer te geven als een bepaalde GET variabele in de request zit) en het bedrijf herinneren aan de licentiehernieuwing.

[Soultaker]

Ik ben het eens met Mithrandir. Het is zeer ongebruikelijk om servers op een verkeerde tijd in te stellen, ook omdat allerlei andere applicaties (denk aan back-ups, systeem upgrades en dergelijke) dan niet meer goed functioneren.

Uiteindelijk is alles te hacken natuurlijk, maar daar is niets aan te doen. Een simpele beveiliging volstaat voor de bonafide bedrijven wel en het extra werk dat je anders aan een strengere beveiliging zou besteden, kun je waarschijnlijk beter besteden om meerwaarde in je product te creeëren. Sowieso levert een al te strenge beveiliging waarschijnlijk ook allerlei praktische problemen op, wat je product weer minder aantrekkelijk maakt voor legitieme gebruikers, en dat moet je natuurlijk voorkomen.

[Verwijderd]

Misschien iets van een hardware dongle met licentiesleutel en dan die licentiesleutel naar jouw server laten sturen om te controleren op geldigheid.

[downtime]

een tweede mogelijkheid is om elke cms-installatie verbinding te laten leggen met mijn eigen website, welke wel altijd de goede tijd zal teruggeven, en aan de hand daarvan de code wel / niet laten uitvoeren. Nadeel: heel veel queries naar mijn site, dus een behoorlijke belasting, en een vertraging op de uitvoering van de code bij de klant. Deze moet immers wachten op een reaktie van mijn site. Eventuele oplossing: niet bij elke klik, maar bv. elke dag 1 keer laten checken. Aandachtspunt: wat als mijn eigen site uit de lucht zou liggen en er geen verbinding kan worden gelegd. Misschien beter om te pingen naar een soort van "worldtimeclock.com" site?

Als je bang bent dat een controle op de lokale systeemtijd te omzeilen is, dan is deze beveiliging ook niet geschikt. Door "worldtimeclock.com" op te nemen in de HOSTS file en naar een eigen NTP servertje te laten wijzen is ook deze beveiliging voor een beetje slimme jongen te omzeilen.
Bovendien kost een dergelijke beveiliging je klanten. Veel grote bedrijven hebben firewalls draaien en zullen het gewoon niet toestaan dat jouw software connecties over niet-standaard poorten met externe servers maakt. Bij mijn eigen werkgever zou je een dergelijk pakket domweg niet kunnen verkopen om die reden.

Ik ben het met de bovenstaande commentaren eens. Als je een zakelijk pakket aan een zakelijke markt wil verkopen moet je je niet te druk maken om illegaal kopieren. Verreweg de meeste bedrijven zullen alles legaal willen houden en de paar die het illegaal willen gebruiken zouden het sowieso nooit legaal kopen, en zijn dus geen verloren klanten.

[begintmeta]

Soultaker schreef op zondag 13 november 2005 @ 16:56:
...Een simpele beveiliging volstaat voor de bonafide bedrijven wel...

Hmm, ik denk dat een beveiliging voor bonafide klanten eigenlijk niet nodig is...

[Soultaker]

Ik denk dat ook bonafide klanten wel een schop onder hun hol (of in vriendelijker termen: een stok achter de deur) kunnen gebruiken. Veel klanten zullen anders gewoon het product blijven gebruiken 'zolang het blijft werken'.

Het gaat me er om dat je de gebruikers in kunt delen in twee categoriën: de eerste bestaat uit klanten die je in principe een licentie kunt verkopen en de tweede uit illegale gebruikers die wel willen profiteren maar nooit zullen betalen. Het werk dat je in beveiliging steekt moet er op gericht zijn klanten in de eerste categorie over te halen te betalen, zonder dat je ze het leven zuur maakt met lastige dingen. De zwaardere beveiliging zorgt ervoor dat de tweede categorie gebruikers meer werk zal maken van het hacken van je software óf overschakelt op een ander, minder goed beveiligd product; in beide gevallen levert het je niets op en is je werk dus verspilde moeite geweest.

[flashin]

Bij ons werkt het gewoon heel simpel. Je bent klant van ons, je host bij ons.
Ons CMS is helemaal ingesteld op onze dedi server en is niet bruikbaar voor 1 externe site, als iemand per se zelf wil hosten (is echt nooit zo) is het vaak toch al zo'n grote opdracht of een opdracht waarbij geld niet echt een rol speelt dat het allemaal maatwerk wordt.
Dan betalen ze wat meer en krijgen ze de source er gewoon bij.

[Verwijderd]

Reveller schreef op zondag 13 november 2005 @ 14:24:
Ik heb gezocht naar een betalingsmodel waarbij ik een constante cashflow genereer, in plaats van pieken en dalen in de inkomsten te hebben. Ik ben van plan mijn systeempje voor 1699 ex BTW te verkopen. Daar komt nog wat bovenop als een klant bijvoorbeeld de site in een eigen layout wil en ik dat voor hem moet doen. Vanaf het tweede jaar betaalt de klant 30% van de aanschafprijs als jaarlijkse licentie. Deze licentie moet een maand voor het verstrijken van het jaar vernieuwd worden.

....

Als hij / zij dan de licentie niet wil betalen, hoe zorg ik er dan voor dat de code stopt met werken?

Ik heb aan een aantal oplossingen gedacht:[list]• als ik de code encrypt met de Zend Safeguard Suite, kan ik een datum instellen waarop de code moet stoppen met werken. Dit is volgens mij makkelijk te omzeilen door de systeemklok terug te zetten, dus is niet bullet-proof

PHP? sowieso de code 'encrypten' met Zend Encoder.
Verder is het gemakkelijkste, om een licentiescherm in je cms in te bouwen.
Elk jaar moet men een nieuwe licentie invullen/importeren, zodat ze er nog een jaar mee vooruit kunnen. Licentiecode/bestandje laat je dan samenstellen door de naam van de koper en verloopdatum en nog wat gegevens. Als men niet betaalt zal op een gegeven moment vanzelf de applicatie niet meer werken, omdat de datum verloopt.
De kans is klein dat men de datum van de server terugzet, omdat je daarmee andere problemen creeert.

[Reveller]

Bedankt voor alle reakties tot nu toe. Ik ben er inmiddels van overtuigd dat:

• slechts weinig bedrijven ergens anders of op hun eigen server zullen willen hosten
• de nadelen van het terugzetten van de systeemklok teveel nadelen met zich meebrengt
• elke beveiliging omzeild kan worden en dat je eerlijke gebruikers niet moet benadelen met ingewikkelde systemen / systeem vertragingen vanwege vele checks omdat je die ene eventuele oneerlijke gebruiker wil pakken

Ik denk dat de oplossing van sinaasappelsap het beste is: een licentiescherm bouwen waar jaarlijks een licentiecode ingevuld moet worden. Zo'n code kan natuurlijk van eenvoudig naar ingewikkeld. Heeft iemand al ervaringen hiermee en tips waar ik op moet letten / artikelen die hierover gaan? Ik zoek intussen natuurlijk ook op Google en vond onder andere een code voorbeeld, maar dat is wel enige overkill vind ik

[Skaah]

D'r was hier laast ook al een topic over dat onderwerp. Ik geloof dat de conclusie was dat je een hash maakt (md5, sha1, doet er niet toe). Die hash bestaat uit een geheime string en de naam van het bedrijf.

Zet er dan nog wat streepjes tussen, en je hebt iets moois. Dat licentiescherm krijg je natuurlijk alleen als je probeert in te loggen.

[Verwijderd]

Skaah schreef op maandag 14 november 2005 @ 18:06:
D'r was hier laast ook al een topic over dat onderwerp. Ik geloof dat de conclusie was dat je een hash maakt (md5, sha1, doet er niet toe). Die hash bestaat uit een geheime string en de naam van het bedrijf.

Zet er dan nog wat streepjes tussen, en je hebt iets moois. Dat licentiescherm krijg je natuurlijk alleen als je probeert in te loggen.

Probleem is dat je uit een hash niet kunt afleiden wat de verloopdatum is, en dat is hierbij wel noodzakelijk. Ook moet het licentiescherm natuurlijk alleen en altijd via de adminpagina te bereiken zijn; je wil geen downtime veroorzaken omdat de nieuwe licentie precies op het moment dat de vorige verlopen is ingevoerd moet worden oid.

[Reveller]

Toevallig wist ik dat Userland Manila ook met een licentiescherm werkt. Dus meteen maar even gedownload om te kijken hoe zij dat doen. Zie hier een screenshot van een pagina waarbij ik opzettelijk een verkeerde licentiecode invoerde:



Blijkbaar checken zij of de server die je op hun website gekocht hebt, ook in hun database op superhonker.userland.com staat. Zo weet je zeker dat de code ooit uitgegeven is, en er dus voor betaald is, in plaats van dat je de geldigheid van een ingevulde code lokaal checked mbv een aantal grammaticale regels waar de code aan moet voldoen.

Ik vraag me alleen af of de geldigheid van de ingevulde code na activatie lokaal of remote wordt gechecked. Het voordeel van remote is natuurlijk dat je problemen met bv. interne klok omzeilt: je stuurt bv. 1 keer per dag de licentiecode naar een centrale server. Die server weet tot wanneer de code geldig is, en zal een true of een false terugsturen.

Nadeel is wat /downtime/ al aangaf: wat nou als "superhonker.userland.com" door de systeembeheerder geblokkeerd wordt of als een request naar die server wordt doorverwezen naar een eigen servertje dat altijd true terug geeft. In dat geval zou je beter lokaal kunnen checken. Om nog maar niet te spreken van de problemen als de centrale server uit de lucht zou gaan.

[Sendy]

Dan zet je de verloopdatum als plaintext neer, maar neemt hem ook op in de hash, zodat je kan controlleren of het nog wel de verloopdatum is die ooit is afgesproken (v.g.l. met digitaal signeren).

[Rukapul]

Om uit te vinden hoe 'populair' je CMS is zou je een hidden pagina kunnen maken met wat unieke keywords zodat het zeer eenvoudig in Google terug is te vinden. Vervolgens gebruik je juridische middelen om misbruik aan te pakken.

Overigens kan ik me niet voorstellen dat een bedrijf een CMS zonder onderhoudsvoorziening wil draaien.

[Reveller]

Kan iemand mij wat aanwijzingen geven over hoe je een algoritme bouwt om een licentiecode te maken en deze ook weer terug uit te lezen?

Ik dacht dat in ieder geval de volgende informatie in de licentie-key zou moeten zitten:

• een timestamp tot wanneer de licentie geldig is, bijvoorbeeld 1131999326
• de naam waarop de licentie is aangeschaft, bijvoorbeeld "Ben en Jerries ijs BV"

Mijn vraag is: hoe vorm is deze twee gegevens om tot een string van bijvoorbeeld de vorm "DASKJ5353263KJK2J53J325H3-2J5HJ65-H7K5J47HKL43H7K2L4J6L-2JK7KL", en hoe haal ik die string op de server weer uit elkaar zodat ik de timestamp en de licentie-houder apart in de database op kan slaan?

Op deze manier kan ik thuis een nieuwe licentie sleutel voor een klant maken. De klant voert hem dan op een admin pagina in, en het cms filtert de benodigde gegevens eruit.

[ Voor 17% gewijzigd door Reveller op 14-11-2005 22:33 ]

[dip]

In principe volstaat iedere encryptie methodiek. Je zou bijvoorbeeld iets met blowfish kunnen doen. Het nadeel is wel dat je de sleutel die je gebruikt om te decrypten moet opslaan in je source code. En ik weet ook niet in hoeverre Zend met haar encrypte het decrypten van deze data tegen kan gaan, kheb er nog nooit mee gewerkt namelijk.

[Skaah]

Je kan controleren of je met de goede server praat met behulp van SSL certificaten. Nadat de code is ingevoerd, maak je contact met je servert (SSL). Die geeft dan aan of en tot wanneer het product gebruikt mag worden.

[Tp21]

dat is niet helemaal waar, SSL certeficaten zijn ook te faken!
(er zijn progjes voor... C&A voor de kenners).
maar dan ga je wel heel ver, een manier die onfeilbaar is, moet nog uitgevonden worden.

[TheRebell]

Als je toch de source code met Zend gaat encrypten, doe dan gelijk de licentie in het Zend tooltje erbij... dat is zelfs een optie als je de iets uitgebreidere versie neemt
Alles qua licentie is in te stellen en ik denk dat je er, zeker in het begin, ruim voldoende mee uit de voeten kunt.

[alienfruit]

Ik gebruik een 512bit key als licensiesleutel in combinatie met een phone-home methode naar een "licensing server" op mijn eigen server. Bestaat de key niet of is ongeldig doordat het verlopen is bijv. Dan wordt het systeem beperkt tot een basisfunctionaliteit zoals geen automatisch backups, plugins/model e.d. Werkt nog best aardig.

Overigens zou ik niet kiezen voor een HASP dongle, de beveiliging van die dingen is zo slecht dat je ze nog beter licentie cadeau kan geven. Echt trieste dingen

[ Voor 4% gewijzigd door alienfruit op 15-11-2005 04:53 ]

[Sendy]

Reveller schreef op maandag 14 november 2005 @ 22:30:
Kan iemand mij wat aanwijzingen geven over hoe je een algoritme bouwt om een licentiecode te maken en deze ook weer terug uit te lezen?

Ik dacht dat in ieder geval de volgende informatie in de licentie-key zou moeten zitten:

• een timestamp tot wanneer de licentie geldig is, bijvoorbeeld 1131999326
• de naam waarop de licentie is aangeschaft, bijvoorbeeld "Ben en Jerries ijs BV"

Mijn vraag is: hoe vorm is deze twee gegevens om tot een string van bijvoorbeeld de vorm "DASKJ5353263KJK2J53J325H3-2J5HJ65-H7K5J47HKL43H7K2L4J6L-2JK7KL", en hoe haal ik die string op de server weer uit elkaar zodat ik de timestamp en de licentie-houder apart in de database op kan slaan?

Op deze manier kan ik thuis een nieuwe licentie sleutel voor een klant maken. De klant voert hem dan op een admin pagina in, en het cms filtert de benodigde gegevens eruit.

Volgens mij is de truk dat je alle gegevens als plain-text opneemt, en deze ook zo gebruikt. De licentiecode is alleen een digitale handtekening hiervan (met een geheime één-weg berekening.) Je hebt alle velden om mee te rekenen en nieuwe licentie te maken, en je kan controlleren of ze nog juist zijn: de digitale handtekening moet nog kloppen.

[Reveller]

Ik heb er vannacht nog eens over nagedacht, en vraag me af waarom het eigenlijk nodig zou zijn om bijvoorbeeld de naam van de licentiehouder in de key op te nemen. Is het niet voldoende om de timestamp tot wanneer het systeem weer moet werken, te verstoppen in een veel grotere key?

Stel dat een klant een nieuwe licentie aanvraagt. De timestamp tot wanneer deze licentie moet werken is 1131999326. Ik genereer dan een key die de timestamp opsplitst en op vaste plaatsen in de licentie code zet, bijvoorbeeld:

4A21G5343-F13DA53252989FDSF-F32-9324325JKK-DSF663

Deze key sla ik op in de database op de "licentieserver". Ik mail hem naar de klant. Die voert hem in op een licentie-pagina in de adminsectie van zijn website. Via een http-request leg ik vanuit de site verbinding met licentieserver.com/check_license.php?licence=4A21G5343-F13DA53252989FDSF-F32-9324325JKK-DSF663. check_license.php kijkt of deze sleutel voorkomt in de database en stuurt een true of false terug naar de website.

Als er een true wordt teruggegeven, wordt de key door een functie gehaald die de timestamp eruit filtert. Vervolgens wordt in de database van de website opgeslagen dat de site moet werken tot aan die timestamp (hier: 1131999326). Bij elke request van de website check ik of de huidige timestamp kleiner is dan die opgeslagen is in de database:

PHP:

if (time() > get_setting_from_database('licentie_datum')) {
  // website werkt niet; nieuwe licentie nodig
}
else {
  // licentie ok; verwerk request
}

Vraag1: Nu ik erover nadenkt: kan ik niet net zo goed een bogus licentie afgeven die gechecked wordt, en dat de licentieserver een timestamp terug geeft?

Vraag 2: Is het niet extreem makkelijk om die http request af te vangen en zelf een true naar de website terug te sturen?

TheRebell schreef op maandag 14 november 2005 @ 23:06:
Als je toch de source code met Zend gaat encrypten, doe dan gelijk de licentie in het Zend tooltje...

Daar heb ik ook aan gedacht, maar dan wordt een nieuwe licentie invoeren een stuk ingewikkelder. Op de manier waarop ik het wil doen, moet de klant een nieuwe licentie invoeren in het admin gedeelte van de site, waar hij toch al vertrouwd mee is. Bovendien kun je eigen error berichten geven aan de klant: "de door u ingevulde licentie is niet geldig", "uw systeem is nu gelicenceerd tot 12-12-2006", etc.

[ Voor 17% gewijzigd door Reveller op 15-11-2005 12:21 ]

[Gerco]

Reveller schreef op dinsdag 15 november 2005 @ 12:12:
Vraag1: Nu ik erover nadenkt: kan ik niet net zo goed een bogus licentie afgeven die gechecked wordt, en dat de licentieserver een timestamp terug geeft?

Ja, waarom niet?

Vraag 2: Is het niet extreem makkelijk om die http request af te vangen en zelf een true naar de website terug te sturen?

Ja.

In ben een fel tegenstander van call-home methodes en bedacht me net het volgende. Gebruikers hebben een hekel aan licentiecodes overtikken en daar geef ik ze gelijk in. Zo'n licentiekey is eigenlijk maar een onhandig ding, je kan er weinig in kwijt omdat hij kort moet zijn.

Als je toegang hebt tot goede crypto-libraries (en dat heb je vast wel), gebruik dan een licentiefile en een public-key encryptie algoritme. Maak een simpel licentiefiletje aan en encrypt die met je private key. Je public-key bak je in de software en gebruik je om de licentiefile te decrypten. Als dat lukt, weet je gelijk zeker dat de licentie van jou afkomstig is, alleen jij hebt immers de private key. Jatten van de public key is geen probleem, daar is 'ie voor bedoeld

Extra voordeel is dat de gebruiker alleen jaarlijks een filetje moet uploaden naar je licentiepagina en dus geen gezeik heeft met het inkloppen van die key.

[ Voor 3% gewijzigd door Gerco op 15-11-2005 12:25 ]

[Reveller]

Ik ben wat aan het prutsen geweest. Hier de overdenkingen:

• ik vind een file naar een klant moeten sturen, die dat dan weer moet uploaden eigenlijk net zoveel "gedoe" als het overtikken van een license key
• public-private key encryption is mooi, maar op dit moment overkill voor mij
• ik wil een eenvoudig systeem dat voor 999 van de 1000 mensen niet 1-2-3 te omzeilen is
• ik moet de licentieserver natuurlijk geen timestamp laten retourneren, want dan is het wel heel makkelijk om een server response te faken. Ik laat de server een true of false terug geven en dan laat ik een stukje code in het cms zelf checken of de licentiesleutel klopt met een bepaald (simpel) algoritme

Ik heb na een uurtje prutsen dit gefabriceerd. Het is nog voor veel verbetering vatbaar (bv. klantnummer erin verwerken dat moet matchen met het hardcoded in de config file staande klantnummer), maar ik zou graag wat reakties ontvangen:

PHP:

function encrypt_license($timestamp) {
  $chars  = array('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j');
  $ints   = array(1, 2, 3, 4, 5, 6, 7, 8, 9, 0);
  $places = array(3, 7, 8, 15, 20, 22, 25, 27, 29, 30);
  $bogus  = 'abcdefghijklmnopqrstuvwxyz1234567890';
  
  // vervang de cijfers van de timestamp door letters uit $chars
  $code = str_replace($ints, $chars, $timestamp);
  $code = preg_split('//', $code, -1, PREG_SPLIT_NO_EMPTY);
  
  $place = 0;
  for ($i = 0; $i < 32; $i++) {
    if (in_array($i, $places)) {
      // zet de cijfers van de timestamp op de plaatsen in de licentiecode,
      // gedefinieerd in $places
      $license[$i] = $code[$place];
      $place++;
    }
    else {
      // vul de rest van de licentiecode met random karakters uit $bogus
      $license[$i] = substr($bogus, mt_rand(0, strlen($bogus) - 1), 1);
    }
  }
  
  // scheid de licentiecode in stukken van 4 karakters voor makkelijker lezen
  $license = array_chunk($license, 4);
  foreach ($license as $codebit) {
    $output[] = implode('', $codebit);
  }

  return implode('-', $output);
}

function decrypt_license($license) {
  $chars   = array('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j');
  $ints    = array(1, 2, 3, 4, 5, 6, 7, 8, 9, 0);
  $places  = array(3, 7, 8, 15, 20, 22, 25, 27, 29, 30);

  $license = str_replace('-', '', $license);
  $license = preg_split('//', $license, -1, PREG_SPLIT_NO_EMPTY);
  
  $place = 0;
  for ($i = 0; $i < 32; $i++) {
    if (in_array($i, $places)) {
      $timestamp[] = $license[$i];
      $place++;
    }
  }

  $timestamp = implode('', $timestamp);  
  return str_replace($chars, $ints, $timestamp);
}

$time    = time();
$license = encrypt_license($time);
$timestamp = decrypt_license($license);

echo 'De timestamp tot wanneer de licentie geldig is, is ' . $time . '<br>';
echo 'Voorbeeld van een licentiecode: ' . $license . '<br>';
echo 'Hieruit halen we weer de timestamp: ' . $timestamp;

Een voorbeeld output hiervan is:

code:

De timestamp tot wanneer de licentie geldig is, is 1132073314
Voorbeeld van een licentiecode: rera-ppfa-c1vx-n6hb-31wj-j2g5-9cpc-pado
Hieruit halen we weer de timestamp: 1132073314

Ik ben benieuwd

[ Voor 60% gewijzigd door Reveller op 15-11-2005 18:09 ]

[Verwijderd]

Reveller schreef op dinsdag 15 november 2005 @ 12:12:
Ik heb er vannacht nog eens over nagedacht, en vraag me af waarom het eigenlijk nodig zou zijn om bijvoorbeeld de naam van de licentiehouder in de key op te nemen.

Die naam kun je dan weer op verschillende schermen tonen. Stel dat de licentie gekopieerd wordt, dan krijgt men de naam van de originele licentiehouder op het scherm te zien. Op die manier is het minder lucratief om een gekopieerde licentie te gebruiken.

[T-MOB]

Reveller schreef op dinsdag 15 november 2005 @ 17:58:
Ik ben wat aan het prutsen geweest. Hier de overdenkingen:
[...]
Ik ben benieuwd

Ja, grappig, het ziet er uit als een MS license code. Als licentie is imho echter niet bijster geschikt. Je mist namelijk compleet de mogelijkheid om te checken of het om een geldige licentie gaat. Oftewel als ik op een van jouw magische punten een - al dan niet bewuste - tikfout maak kan ik in een keer de applicatie voor de aankomende tig jaar activeren. Of, erger voor de klant, de applicatie onbruikbaar maken omdat de timestamp nu ver in het verleden staat.

In de karakters die nu bogus zijn zou je iets simpels kunnen doen als nog twee getallen obfuscaten die bij elkaar opgeteld gelijk moeten zijn aan de timestamp. Op die manier voorkom je al een deel van de problemen

offtopic:
Verder denk ik dat je te moeilijk doet. Mensen die illegaal je CMS willen gebruiken lukt dat toch wel. Je betalende klanten hebben alleen maar last van dit soort geneuzel. Met het huidge aanbod aan (gratis en betaalde) CMS-en denk ik dat je al heel blij mag zijn als je de applicatie 500x weet te verkopen. Dat is nog prima semi-geautomatiseerd bij te houden. Bovendien heb je dan al bijna een miljoen ex btw bijelkaar gesprokkeld alleen al aan initiele verkopen. In hoeverre je dan nog bezig bent met dit CMS en in hoeverre je je dan nog druk maakt om die paar die misbruik van je maken moet je zelf maar beoordelen...

[Reveller]

T-MOB schreef op dinsdag 15 november 2005 @ 19:05:
[...] Je mist namelijk compleet de mogelijkheid om te checken of het om een geldige licentie gaat. Oftewel als ik op een van jouw magische punten een - al dan niet bewuste - tikfout maak kan ik in een keer de applicatie voor de aankomende tig jaar activeren. Of, erger voor de klant, de applicatie onbruikbaar maken omdat de timestamp nu ver in het verleden staat.

Ik denk niet dat de code zomaar aan te passen is. Ten eerste moet je weten dat er ueberhaupt een timestamp in de code zelf verstopt zit. Vervolgens moet je weten dat elk cijfer uit de code door een letter vervangen wordt. Je moet weten welke letter wel cijfer vervangt en je moet weten op welke plaatsen in de code de letters staan die de timestamp representeren. Dat is nu nog fixed, maar dat zou je variabel kunnen maken. Bijvoorbeeld: je begint elke code met de letter a, g of k. Alhankelijk van met welke letter de code begint, staan de timestamp cijfers op andere plaatsen in de code. En je zegt het zelf al -- een systeem als dit zal als je het heel goed doet 500 keer af te zetten zijn (ik mag hopen dat ik dat haal! ). Er zullen dus niet genoeg licentiecodes gepubliceerd worden om te vergelijken en er een patroon in te ontdekken lijkt me?

In de karakters die nu bogus zijn zou je iets simpels kunnen doen als nog twee getallen obfuscaten die bij elkaar opgeteld gelijk moeten zijn aan de timestamp. Op die manier voorkom je al een deel van de problemen

Een aantal van dit soort checks zat ik ook aan te denken ja.

offtopic:
Verder denk ik dat je te moeilijk doet. Mensen die illegaal je CMS willen gebruiken lukt dat toch wel. Je betalende klanten hebben alleen maar last van dit soort geneuzel. Met het huidge aanbod aan (gratis en betaalde) CMS-en denk ik dat je al heel blij mag zijn als je de applicatie 500x weet te verkopen. Dat is nog prima semi-geautomatiseerd bij te houden. Bovendien heb je dan al bijna een miljoen ex btw bijelkaar gesprokkeld alleen al aan initiele verkopen. In hoeverre je dan nog bezig bent met dit CMS en in hoeverre je je dan nog druk maakt om die paar die misbruik van je maken moet je zelf maar beoordelen...

Je hebt hier echt een goed punt, en ik kan het er alleen maar mee eens zijn. Toch spelen er nog andere zaken: vooral als mensen niet bij mij hosten, wil ik er redelijk zeker van zijn dat het systeem na een jaar onbruikbaar wordt, zou de klant het licentiebedrag niet voldoen. Belangrijke reden daarvoor is dat een continue inkomstenstroom wil creeeren. De afgelopen jaren heb ik veel lossen projecten aangepakt. Het nadeel daarvan is dat je de ene maand 7.000 euro kunt harken, en dan weer drie maanden (nagenoeg) niets hebt. Daarom heb ik besloten geen maatwerk meer te willen leveren, maar een eigen cms te maken, dat ik als product verkoop. Het licentiebedrag (samen met de inkomsten van hosting) moet ervoor zorgen dat ik een gegarandeerd minimaal inkomen heb. Een laatste, niet onbelangrijke reden: ik wil dit alleen maar blijven doen als ik er plezier in heb. En ik vind het momenteel leuk om wat te prutsen met zo'n sleutel. Om iets relatief betrouwbaars te maken, maar wat toch niet te moeilijk is voor klanten

[Verwijderd]

^--- Ik ben met Gerco:

Public key encryption is de oplossing voor al je licentie problemen.


Hoe geef ik licentieinformatie (zoals verlooptijd, klantnummer) door aan m'n script?
Encrypt of sign het met je private key. Je kunt de informatie vertrouwen want je weet zeker dat de informatie van jou afkomt.

Hoe zorg ik dat de beveiliging niet uit mijn scripts gesloopt wordt?
Bereken een checksum van de files en encrypt of sign deze met je private key. Als er met de file gerotzooid wordt kun je daar makkelijk achter komen.

[T-MOB]

Reveller schreef op woensdag 16 november 2005 @ 12:00:
Ik denk niet dat de code zomaar aan te passen is. Ten eerste moet je weten dat er ueberhaupt een timestamp in de code zelf verstopt zit. Vervolgens moet je weten dat elk cijfer uit de code door een letter vervangen wordt. Je moet weten welke letter wel cijfer vervangt en je moet weten op welke plaatsen in de code de letters staan die de timestamp representeren. Dat is nu nog fixed, maar dat zou je variabel kunnen maken. Bijvoorbeeld: je begint elke code met de letter a, g of k. Alhankelijk van met welke letter de code begint, staan de timestamp cijfers op andere plaatsen in de code. En je zegt het zelf al -- een systeem als dit zal als je het heel goed doet 500 keer af te zetten zijn (ik mag hopen dat ik dat haal! ). Er zullen dus niet genoeg licentiecodes gepubliceerd worden om te vergelijken en er een patroon in te ontdekken lijkt me?

Het gaat niet om kraken, de kans dat je random een licentie genereert met een timestamp is in dit algorithme 10/26¹⁰ (0.007%). Je kunt echter ook gewoon een tikfout maken. Een gebruiker met een geldige code die 1 karakter verkeer overneemt heeft een kans van 10/32 * 10/26 (~12%) dat dit alsnog een geldige timestamp oplevert. In dit systeem kun je op geen enkele wijze controleren of een code met een valide timestamp als resultaat wel de timestamp genereert die de bedoeling was.
In mijn opinie kun je - zoals vaker gesuggereerd in dit topic - beter werken met een geijkte methode a la public - private encryption. Zelfs met een simpele XOR operatie en een hardcode "sleutel" (of set sleutels) kun je deugdelijkere resultaten halen dan met het goochelen met karakters om een timestamp te verstoppen.

Je hebt hier echt een goed punt, en ik kan het er alleen maar mee eens zijn. Toch spelen er nog andere zaken: vooral als mensen niet bij mij hosten, wil ik er redelijk zeker van zijn dat het systeem na een jaar onbruikbaar wordt, zou de klant het licentiebedrag niet voldoen.

Je weet toch precies wanneer bij welke klant de licentie verlengd moet worden. Dan kun je ze gewoon een rekening sturen. Als ze weigeren te betalen en het product niet buiten gebruik stellen dan kun je gewoon naar een deurwaarder/rechtbank stappen. Zo werkt dat bij alle bedrijven (in een lease-auto zit ook geen mechanisme dat de auto onbruikbaar maakt als je niet betaalt).
Het geneuzel met sleutels is imho alleen te verdedigen wanneer je 1. als maker geen direct contact hebt met de klant omdat je software door derden wordt verkocht (Microsoft, Adobe, etc.) of 2. De software publiekelijk aanbied ter demo en daardoor de klanten niet van de probeerders kunt onderscheiden. Oftewel, zolang je weet wie je klanten zijn is het inbouwen van een sleutelsysteem imho een compleet overbodige toevoeging. Het doet af aan de gebruiksvriendelijkheid en het straalt wantrouwen jegens je klanten uit. Oh, en jou levert het alleen maar extra werk op...

[Soultaker]

Verwijderd schreef op woensdag 16 november 2005 @ 12:18:
Hoe geef ik licentieinformatie (zoals verlooptijd, klantnummer) door aan m'n script?
Encrypt of sign het met je private key. Je kunt de informatie vertrouwen want je weet zeker dat de informatie van jou afkomt.

Hoe zorg ik dat de beveiliging niet uit mijn scripts gesloopt wordt?
Bereken een checksum van de files en encrypt of sign deze met je private key. Als er met de file gerotzooid wordt kun je daar makkelijk achter komen.

Dat werkt dus alleen als er niet met je checksum-check-filetje geknoeid is. Als je gewoon een functie check_license() hebt in een ongecodeerde license.php dan is het een kleine moeite om daar 'return TRUE;' of iets dergelijks in te zetten.

Vandaar dat het nuttig is om de boel te coderen met Zend Encoder of iets dergelijks, maar uiteindelijk ontkom je niet aan het principe dat alles wat client side moet draaien te hacken is.

[TheBlasphemer]

Ik vind je huidige methode er al erg goed uitzien. Ik zou de bytes van de key nog even optellen met iets als:

code:

function createcrc($licentie) {
$crc=0xAB;
for ($i=0; $i<strlen($licentie); $i++) {
  $crc=(($crc*3)+ord($licentie{$i}))&0xFF;
}
return chr($crc);
}

Bij het maken van de licentie doe je simpelweg:
$licentie.=createcrc($licentie);
En bij het checken splits je de $licentie op in twee stukken, substr($licentie,0,strlen($licentie)-1) en $licentie{substr($licentie)-1} (alles - laatste karakter en alleen laatste karakter), gooi je dat eerste stuk door createcrc, en check je of dat overeenkomt met dat tweede stuk
Als iemand dan een typfoutje maakt is de kans al erg groot dat dit dan een foute CRC genereerd

Verder kun je ook nog veel leukere dingen doen met RSA of een andere private-public-key encryptie.
Denk bijvoorbeeld aan dit scenario:
Licentie is verlopen, de klant logt dan in, en geeft aan dat hij de licentie wil verlengen. Geeft hierbij aan hoe lang etc etc. De CMS maakt vervolgens een klein bestandje waar eventueel een klein beetje encrypted instaat wat voor licentie de gebruiker wil.
Vervolgens upload de gebruiker dit bestand naar jouw server, en jouw server maakt een mooie rekening.Na betaling van Paypal pakt jouw server dat bestandje, en encrypt het met zijn private key, en stuurt het terug naar de gebruiker.
De gebruiker upload dit naar zn CMS, de CMS encrypt (of decrypt ) het zootje weer met zijn public key, en kijkt of dit overeenkomt met het originele bestandje dat hij had gemaakt...
Zo heb je als het ware een call-home service zonder dat er iets door de firewall doet, dit doet de sysadmin gewoon een maandje voor de licentie is verstreken

Nouja, klinkt ingewikkeld, maar heb die methode al wel eens gebruikt met registratie van programmas
Gebruiker krijgt code (gewoon random code), geeft die code op bij mijn website, en krijgt na betaling een nieuwe code terug die als unlock-code op die random code werkt

[Verwijderd]

Soultaker schreef op woensdag 16 november 2005 @ 14:37:
[...]

Dat werkt dus alleen als er niet met je checksum-check-filetje geknoeid is. Als je gewoon een functie check_license() hebt in een ongecodeerde license.php dan is het een kleine moeite om daar 'return TRUE;' of iets dergelijks in te zetten.

Niet als daar de checksum ook van gecontroleerd wordt natuurlijk.

[Hydra]

Onze software werkt simpelweg met een licentie-file waarin een hoop info staat (o.a. aan wie de license verstrekt is, tot hoe lang deze duurt, etc.) met daaronder een geencrypte key. Dit is een one-way encryptie. het enige wat ze hoeven te doen is deze file kopieren, het systeem start niet als er iets in die file is aangepast (het is een soort MD5 hash, maar dan niet zelf aan te maken).

[RagaBaSH]

Als je voor een relatief klein percentage gebruikers de software op een eigen server gaan hosten is het wel erg veel moeite om er allemaal complicated spul in te doen.

ik bedenk me zo het volgende:

• Elke niet door jou gehoste CMS bevat een "backdoor" waar jij mee in kan loggen (evt. met een eigen public/private key). ziet niemand als je je code door de Zend Encrypter haalt.
• Je host een deel van de admin pagina´s altijd zelf -> je wil toch een eigen host oid. je zorgt dat een deel van de website wat de afnemer nodig heeft bij jou blijft terwijl voor gebruikers alles transparant blijft.
• Bij die licentiekosten zit support. na een jaar houdt support op. Zeker in deze tijden waarin het nog wel eens voor komt dat er lekken ondekt worden in software zijn er weinig bedrijven die het risico willen lopen hier het slachtoffer van de lopen. oftewel die 30% licentiekosten in jaar 2+ = servicekosten, you dont pay, you`re on your own.

Zoals al vaker gezegd, mensen die niet willen betalen, betalen toch niet. je moet zorgen dat ze jou WILLEN betalen, door ze een "dienst" te leveren voor het geld dat je ze geeft.