[PHP] Update functie, client toegang controle

[m33p]

Titel was een beetje een probleem, maar ik zit met het volgende:

Ik heb een panel. Bij dat panel zit een script welke de client files moet updaten. Deze worden gewoonweg gesynchorniseerd met de bestanden op de server. Nou is het systeem uit modules opgebouwd, en nou probeer ik het volgende te realiseren:

- De gebruikers hebben een aantal modules, bijvoorbeeld 3 van de 5 modules. Nou mogen zij alleen deze modules updaten (en downloaden, want het synchronisatie script werkt ook met een 'clean install'. Er moet eerst geverifieerd worden of de key geldig is. Aan deze key is ook de gebruiker gekoppeld en welke modules deze toegang tot heeft.

Wat ik wil is dat de klant alleen deze modules kan draaien, en niet een module van iemand anders kan kopieren en kan laden. Is er op de één of andere manier zoiets te realiseren in PHP? Het maken van een socket verbinding om de key te controleren en info op te halen is geen probleem. Het synchroniseren ook niet, dit heb ik al klaar.

Het moet een soort één-wegs controle zijn waarbij dus niet zomaar andere modules gedraaid kunnen worden. Nou zal ik waarschijnlijk code moeten gaan beveiligen op de één of andere manier, maar ik heb geen flauw idee hoe.

Ik heb wel een idee, maar deze is nogal omslachtig: 1. Ik maak FTP gebruikers aan met als naam de key. Aan deze key hangt een standaard wachtwoord. Hiermee komt de gebruiker op een soort image van zijn pakket en kan hij / zij alleen bij de bestanden welke deze toegang tot heeft.

Nadeel is dat het pakket modulair is. Dan moet ik dus een aantal (iets rond de 40) images gaan maken wat mij eigenlijk te omslachtig is, vandaar mijn vraag.

Is er iemand welke mij tips kan geven en verder opweg kan helpen? Alvast bedankt!

[GlowMouse]

Je zult je code in ieder geval moeten encoden, anders is elke vorm van kopieerbeveiliging te omzeilen. Daar is gelukkig genoeg over te vinden.

Het maken van een socket verbinding om de key te controleren en info op te halen is geen probleem. Het synchroniseren ook niet, dit heb ik al klaar.

Kun je bij het key controleren gelijk de licensie-informatie checken, en aan de hand daarvan checken of bepaalde modules wel of niet gedraaid mogen worden. Kopieren an sich is namelijk niet te voorkomen, dus je moet zorgen dat de (encoded) core van je script alleen met de modules werkt waarvoor een licentie beschikbaar is.
Eventueel maak je voor elke module een andere code, encode je modules ook, en check je in de modules zelf. Dat is denk ik makkelijker te realiseren, maar wel minder mooi.

[NMe]

Je kan toch gewoon een hele login met bijbehorende rechtenstructuur maken? Of begrijp ik je probleem verkeerd?

[Gwaihir]

Hoe groot zijn die modules? Veelal wordt in dit soort situaties de klant een download van het geheel aangeboden, en wordt een deel van de modules op z'n pc simpelweg niet beschikbaar gesteld (aan de hand van de key).

Voordelen:
- eenvoudig management van de images (er is er nl. maar één)
- makkelijk upgraden (modules toevoegen) voor de klant: een nieuwe key is alles wat hij nodig heeft
Nadeel:
- overbodig grote omvang van de download voor wie slechts een paar modules gebruikt

[m33p]

Het is een systeem om een server (fysiek systeem) te beheren. De gebruiker krijgt zijn modules waar hij recht op heeft. So far so good. Bij het updaten moet alleen gekeken worden welke modules er geupdate moeten worden. Dit doe ik nu via FTP, maar als iemand in de code kijkt kan hij ook handmatig inloggen op de FTP en de boel downloaden. Dit is het eerste punt wat ik wil voorkomen. Het 2e punt is dat de gebruiker het niet kopieerd en alsnog gaat draaien. Ik ben druk aan het zoeken om de source te beveiligen, dit ga ik denk ik wel nodig hebben want steeds code downloaden voordat het je het kunt draaien is ook niet wat.

Een module kan aardig groot worden, aangezien er ook per module afbeeldingen en mogelijke CGI scripts / executable in kunnen zitten. Het is dus de bedoeling dat puur en alleen aan de hand van de key (welke opgeslagen is op de server) de rechten op de client te kunnen bepalen. Een soort challenge-authenticatie, welke client-side beveiligd is.

[Alex)]

Punt 1: schakel in ieder geval listing uit op je FTP-server, of stap over op een HTTP-server (die kan je met een wachtwoord beveiligen, en in je .htaccess Options -Indexes zetten. Simpel.)

Hoe zitten de module-images in elkaar. Wachtwoord beveiligde archieven (.rar, .zip, .tgz?)? Dat kan natuurlijk nog, dan heb je weinig aan het downloaden van een image, als je het wachtwoord niet weet. Verder: laat iedere module checken of het volgens de key is toegestaan om die module te gebruiken. Of werk met een cronjob o.i.d., laat iedere X uur (24/48/...) de key valideren met je server. Onbekende key? Dan script uitschakelen, o.i.d.

[m33p]

Ik bedenk me net wat voor het update probleem. Als ik nou bijv. tar bestanden (of tgz, of zip, or rar, dat maakt niet zo heel veel uit) maak met een password. Ik laat de client deze downloaden. Dan maak ik een socket verbinding naar mijn server en controleer ik of die key rechten heeft op die module. Is dat zo, dan laat ik hem de code voor die module terug sturen, en nog in de runtime extract ik dat archive bestand. Als ik zoiets via een soort simpel ge-encrypt protocolletje ................... shit ik bedenk me net dat je dan weer met het probleem zit dat je de code aan kunt passen, en dan gewoon die code kunt onderscheppen. Daarvoor zou ik weer in de runtime een include kunnen doen vanaf mijn server welke weer controles uitvoerd, want als je kunt updaten is één van de update servers ook up, dus dat includen moet ook werken.

Snapt iemand wat ik bedoel en kan zoiets gaan werken? Dus:

- Je download de beveiligde .tar
- Require een extern bestand van één van de update servers en execute
- Dit script checked de filesize van het update script, of deze niet is aangepast
- Stuur de serial en een hash van de .tar op naar de server en check of dit overeenkomt.
- Als de serial toegang heeft tot die module, stuur een pass terug en extract deze

Vergeet ik iets of moet dit kunnen? Het probleem met het code hacken is dan nog niet opgelost dus daar moet ik dan sowieso nog naar kijken.

Edit:
Een cronjob gaat niet werken. Alles draait in princiepe op een externe server van de gebruiker. De updates komen van de update servers (onder mijn beheer).

[ Voor 6% gewijzigd door m33p op 06-08-2005 00:55 ]

[Alex)]

Dan moet er op jouw server een cronjob draaien die je clients gaat pollen naar de licensekeystatus?

[Verwijderd]

Ik denk dat je iets te moeilijk aan het doen bent, gezien de "get-put-get-put-get-put-get-put".

Ik denk dat je het beter kan oplossen door het volgende te doen: Je stuurt een HTTP get vanaf je applicatie / update programma met een paar parameters:

code:

http://update.jouserver.com/check.php?auth_key=md5string&module_key=md5product

Iedere module heeft een eigen MD5 string, zo kan iedere module zelf een update uitvoeren. Er is ook een auth_key, zeg de seriecode voor het bedrijf.

Je moet lokaal op de pc/server een bestand hebben staan waar per module een MD5 staat opgeslagen, of in de module zelf (als het een php/tekst bestand is). Dan heeft dus iedere klant per module een eigen MD5 key. Zo kan je dus een controle uitvoeren binnen een database/script wat bekijkt of de auth_key de zelfde eigenaar is als de module_key (dat heb je bij de vorige release nl opgeslagen in een database).

De module_key kan je op de volgende manier in elkaar zetten

PHP:

//pseudo
if (isset($_GET) AND isset($_GET['auth_key']) AND strlen($_GET['auth_key'])==32 AND isset($_GET['module_key']) AND strlen($_GET['module_key'])==32) {

  $get_downloaded_information = from_database($_GET['module_key']);
  if ($get_downloaded_information['klant_key']==$_GET['auth_key']) {

    $salt = 'B3rgbu77sh1t' . time();
    $md5_module_download = md5( $salt . $auth_key );

    sla_op_in_database( $md5_module_download, $_GET['auth_key'], time() ); //paar dingen opslaan in database, mischien IP ook nog.
    open_bestand_in_temp_dir('module.key');
    write_md5_naar_open_bestand($md5_module_download);

    $zip = new ziplib();
    $zip->addfiles(.......); //alle bestanden zippen voor de klant, incl module.key

    headers('type: ocset/steam'); //zoiets was het, erg lang geleden
    fpasstrue(zipfile); //of een andere functie, bv via fread icm een echo.

  }
  
}

offtopic:
Hoop dat het een beetje te volgen is (ben stoned)

Ik ga ongeveer het zelfde systeem toepassen binnen PHPMyServer (project van mij), alleen dan zonder auth_key functie. Maar ieder core script krijgt iig een eigen ID per versie.

[ Voor 14% gewijzigd door Verwijderd op 06-08-2005 01:37 ]

[m33p]

Ok ik heb bovenstaand net even uitgewerkt (in grote lijnen en op basis van jouw idee) en dat lost het rechten probleem iig grotendeels op. Ik zit alleen nog met het beveiligen van m'n source, maar dat kan denk ik beter in een ander topic als dat nodig mocht zijn, maar daar kom ik zelf wel uit. Verdere tips zijn uiteraard welkom.

[Alex)]

Zend Encoder? Of Optimizer?

[m33p]

Ik ben er naar wezen kijken. Het mooie van Zend is dat het er standaard al bij zit, het nadeel is de prijs. Het panel waar dit topic over gaat is toch meer op de budget markt gericht, en om nou even $960 per jaar op te hoesten gaat de prijs van het pakket niet ten goede doen. Turcks mmCache is een goed alternatief, het moet geen probleem zijn om een extra module te instaleren.

[Verwijderd]

Waarom zo ingewikkeld? Gooi die FTP server eruit, en laat je clients hun bestanden ophalen via www. Daar wordt de normale login gebruikt en kan men alleen de modules halen waar men rechten op heeft.

Verder distileer je uit de volgende gegevens een unieke key (bv. md5-hash):

- klantnummer
- modules waar klant recht op heeft
- server die beheert moet worden
- een geheime code van jouw bedrijf

Die key hoort bij het hoofdprogramma, zeg maar de applicatie die de modules laadt.

Nu kan een klant nog wel die key overnemen van een andere klant, maar dan beheert hij/zij ook gelijk de server van die andere klant.