[ALG] Serie nummer op basis van persoonlijke gegevens

[c00kie]

Hallo, ik heb een kleine vraag, want veel googlen maakt mij alleen maar een beetje waziger .

Probleem
Ik heb een programmaatje geschreven voor klantenbeheer & facturatie enzo van die dingen voor de kleine zelfstandige. Aangezien ik niet wil dat dit gekopieerd wordt, zonder dat er voor betaald wordt, wil ik aan iedere gebruiker een serienummer geven. Dit serienummer zal ik zelf per klant moeten aanmaken op basis van zijn naam en ondernemingsnummer (uniek nummer voor een onderneming in belgië).

Doel
Dit serienummer zal de gebruiker moeten invoeren bij installatie, en het zal dan opgeslagen worden in de registry. Bij het openen van de toepassing zal dit serienummer opgehaald worden, terug gedecrypteerd worden, en de naam en het ondernemingsnummer zullen dan op alle documenten die afgeprint worden vermeld worden. (als de buurman die mijn prog gekopieerd heeft iets afdrukt komt er dan een verkeerde naam op en ook een verkeerd ondernemingsnummer op al zijn documenten)

Mijn zoekpath
Ik ben dus al een goeie dag op zoek, maar alles wordt maar waziger en waziger. Eerst dacht ik door de naam & nr te hashen via MD5 ofzoiets, maar dat is niet praktisch om langere keys te genereren en dan zeker niet om te terug te decrypteren... (one-way hashing maar dat heeft dus wel al eventjes geduurd alvorens ik dit doorhad , tja beveiligingsmaterie is volledig nieuw voor mij)

Uiteindelijk kwam ik dan op encryptie & decryptie, maar welk algorithme moet je dan gebruiken, om het toch niet te ingewikkeld te maken, want uiteindelijk zijn het gewone dagdagelijkse gebruikers, die het programmaatje gebruiken omdat het eenvoudig is, en zeker geen hackers zijn...
Er werden mij termen rond het hoofd geslagen van blowfish toestanden en Rijndael enzo van die dingen, maar ik heb precies het gevoel dat die nogal ingewikkeld zijn.

Vraag
Het programma is geschreven in powerbuilder. Dus misschien moet ik daarin dan ook maar deze encryptie- en decryptiefuncties schrijven. Eventueel is c++ ook een optie, maar dat zit redelijk diep in mijn geheugen, maar dit is dan misschien weer het juiste moment om daar terug een beetje mee te leren werken. (als ik een dll heb, kan ik vanuit powerbuilder deze dll ook wel aanspreken)
Wat is volgens jullie de beste manier om zo een serienummer op te bouwen, en vooral, hoe begin je hieraan. (het is wel degelijk mijn bedoeling om dit zelf te schrijven, maar kleine tipjes hier en daar zijn altijd welkom natuurlijk )

Ik dank jullie al in voorbaat,

[Gé Brander]

1) Je doel is het niet kunnen kopieren van je applicatie of het niet aantrekkelijk maken daarvan.
2) Je uitwerking om het doel te bereiken beschijf jij bij Doel.

Anyway...

Ik heb een schurfthekel aan ontwikkelaars die dit soort oplossingen willen doen, idem voor dat soort oplossingen met usb-keys of andere pluggen die het runnen van de applicatie onmogelijk maken en applicaties die gekoppeld zijn aan 1 machine.

Ik begrijp echter je probleem wel, maar ga niet dit soort gedrochten uitwerken. Daar maak je je klanten niet blij mee, op het moment dat hun pc kapot gaat en ze de applicatie opnieuw moeten installeren op een andere pc, dan kunnen ze er niet mee werken. Jouw applicatie is een tool voor je klant om hun werk mee te doen. Dan moet je ze niet dwarszitten met jouw angsten.

Wat voor oplossing kan je gebruiken:
Kijk naar Windows XP, daar werkt het wel voor 30 dagen, maar moet je je applicatie activeren via het internet of telefoon. Als je zoiets doet, zie jij welke key voor welke klant gebruikt wordt, en hoeveel keer de applicatie geactiveerd wordt. Als het meer is dan het aantal licenties, kan je contact opnemen met de klant met de vraag of het klopt of ze de applicatie nogmaals geinstalleerd hebben, en zo ja, dan kan je ze melden dat de factuur onderweg is...

[Daos]

Je kan beter een asymmetrische encryptie gebruiken zoals RSA. Jij pakt het dan in met een prive steutel en iedereen kan het uitlezen.

Voor de implementatie van RSA moet je kunnen rekenen met hele grote getallen (tot paar duizend bits).

[edit]
Mensen kunnen altijd de publieke sleutel en de gecodeerde tekst wijzigen. Symmetrisch zoals AES is net zo onveilig en nog veel sneller ook.

[ Voor 26% gewijzigd door Daos op 21-10-2005 10:26 ]

[sopsop]

@c70070540: ik zie werkelijk niet wat het probleem met deze methode is. Een sleutel die er voor zorgt dat username+overeenkomstnummer gevalideerd worden is echt geen ranzige methode. En ook niet aan 1 machine gebonden.

Ik zie niet in waarom je geen MD5 Hash zou gebruiken. One-way is geen probleem.
Je slaat maakt de hash op basis van de naam van het bedrijf en diens kvk-nummer, daarnaast gebruik je je eigen sleutel. Die gegevens stuur je op naar dat bedrijf, voert ze in in de applicatie en je slaat ze alle drie op (de hash, de bedrijfsnaam en het kvk-nummer). Bij het aanloggen/opstarten controlleer je of de hash i.c.m. de gegevens en je eigen sleutel matchen. Zo ja: prima: op de rapportage gebruik je de naam en het kvk-nummer die gewoon in je database of registry staan.
Gewoon one-way hasing en zolang ze de sleutel niet kunnen achterhalen is er niets aan het handje.

[Verwijderd]

c70070540 schreef op vrijdag 21 oktober 2005 @ 10:15:
Veel tekst...

In tegenstelling tot jouw reactie, vindt ik het idee dat in de TS geopperd wordt zo slecht nog niet! Wat hij wil is een uniek - niet te kopieren - serienummer koppelen aan bepaalde NAW-gegevens. Zodra de gebruiker het pakket installeert wordt met behulp van het unieke serienummer bij gebruik van het softwarepakket alleen gebruik gemaakt van de NAW-gegevens die gekoppeld zijn aan dat nummer. Leuk bedacht!

Maar.

Ik kan alleen in eerste instantie al twee problemen bedenken, laat staan als ik er even de tijd voor neem (wees niet getreurd, die tijd heb ik niet )

1. De gebruiker zijn pc- of softwarepakket crasht en er moet een nieuwe installatie plaatsvinden. Daarbij dus de vraag, mag een licentie op meerdere pc's gebruikt worden? Mijn mening is dat dit moet kunnen, omdat er toch alleen maar documenten gegenereerd kunnen worden met één en hetzelfde adres.

2. De gebruiker gaat verhuizen. Hij of zij moet de NAW-gegevens dus aan kunnen passen, met alle fraudemogelijkheden van dien.. Iets creatiefs voor bedenken dus! Wellicht kun je de serienummers + NAW-data koppelingen centraal opslaan op bijvoorbeeld een eigen server. Op die manier heb je altijd onder controle welke NAW-gegevens er gebruikt kunnen worden, en kun je dit vergelijken met de boekhouding van je licentieverkoop.

Succes, leuk plan maar je moet met een hoop zaken rekening houden.

[Gé Brander]

boppert schreef op vrijdag 21 oktober 2005 @ 10:25:
@c70070540: ik zie werkelijk niet wat het probleem met deze methode is. Een sleutel die er voor zorgt dat username+overeenkomstnummer gevalideerd worden is echt geen ranzige methode. En ook niet aan 1 machine gebonden.

Heb jij wel eens als beheerder gewerkt voor werkplekken? Nee zeker?
Als dat zo zou zijn, zou er ook een schurfthekel aan hebben.
De gebruikers (= de klant) verwacht dat de applicatie werkt. Als zijn pc kapot is, zou het vervangen van de pc en opnieuw installeren voldoende moeten zijn voor minimaal een aantal dagen. Als je wel eens zo een ranzige applicatie hebt moeten inbouwen in een automatische omgeving voor distributie van software, snap je waar ik het over heb.

[c00kie]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:26:
[...]

Zodra de gebruiker het pakket installeert wordt met behulp van het unieke serienummer bij gebruik van het softwarepakket alleen gebruik gemaakt van de NAW-gegevens die gekoppeld zijn aan dat nummer. Leuk bedacht!

eventjes op inpikken... Dit idee komt hier ergens vanop got, dus niet mijn eigen idee. Maar was topic van enkele jaren geleden, en daar is dit vernoemd, maar niet verder op ingegaan... daarom begin ik dus maar opnieuw .

c70070540 schreef op vrijdag 21 oktober 2005 @ 10:28:
[...]

Heb jij wel eens als beheerder gewerkt voor werkplekken? Nee zeker?
Als dat zo zou zijn, zou er ook een schurfthekel aan hebben.
De gebruikers (= de klant) verwacht dat de applicatie werkt. Als zijn pc kapot is, zou het vervangen van de pc en opnieuw installeren voldoende moeten zijn voor minimaal een aantal dagen. Als je wel eens zo een ranzige applicatie hebt moeten inbouwen in een automatische omgeving voor distributie van software, snap je waar ik het over heb.

Maar het doel van die serienummer is dat de applicatie opnieuw kan geïnstalleerd worden, zonder dat er problemen mogen zijn op verschillende computers.
Als jij een windows installeert, moet toch ook keer op keer de productkey ingevuld worden? (los van het feit dat je een unattended install gebruikt, maar die productkey moet je ook altijd meegeven...)

Plus het is een simpel programmaatje, niet zo'n mastodont om een volledige boekhouding mee te voeren. Simpel en eenvoudig, wat factuurtjes, offertes, beetje reporting. Niks meer.

[ Voor 51% gewijzigd door c00kie op 21-10-2005 10:34 ]

[Nick_S]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:26:
[...]
2. De gebruiker gaat verhuizen. Hij of zij moet de NAW-gegevens dus aan kunnen passen, met alle fraudemogelijkheden van dien.. Iets creatiefs voor bedenken dus! Wellicht kun je de serienummers + NAW-data koppelingen centraal opslaan op bijvoorbeeld een eigen server. Op die manier heb je altijd onder controle welke NAW-gegevens er gebruikt kunnen worden, en kun je dit vergelijken met de boekhouding van je licentieverkoop.

De TS beschrijft toch een oplossing aan de hand van een uniek nummer en naam. Zelfs bij een verhuizing zal een bedrijf niet van naam veranderen. Mochten ze dit wel willen, is een telefoontje naar het bedrijf, waar je je applicatie van gekocht hebt natuurlijk snel gemaakt. (Sneller als je naam aanpassen bij de (Belgische) KVK)

[Gé Brander]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:26:
[...]
In tegenstelling tot jouw reactie, vindt ik het idee dat in de TS geopperd wordt zo slecht nog niet!

Naar mijn idee, wil de TS alleen maar dat illegaal gebruik van zijn applicatie vermeden wordt...

Wat hij wil is een uniek - niet te kopieren - serienummer koppelen aan bepaalde NAW-gegevens. Zodra de gebruiker het pakket installeert wordt met behulp van het unieke serienummer bij gebruik van het softwarepakket alleen gebruik gemaakt van de NAW-gegevens die gekoppeld zijn aan dat nummer. Leuk bedacht!

Inderdaad, leuk bedacht, maar er kleven in de beheer omgeving van de werkplekken grote bezwaren aan. Er zijn makkelijkere methoden voor beheer, en die ook te implementeren zijn.
EDIT: Ik lees verkeerd, vergeet deze reactie maar....

Maar.

Ik kan alleen in eerste instantie al twee problemen bedenken, laat staan als ik er even de tijd voor neem (wees niet getreurd, die tijd heb ik niet )

1. De gebruiker zijn pc- of softwarepakket crasht en er moet een nieuwe installatie plaatsvinden. Daarbij dus de vraag, mag een licentie op meerdere pc's gebruikt worden? Mijn mening is dat dit moet kunnen, omdat er toch alleen maar documenten gegenereerd kunnen worden met één en hetzelfde adres.

Als je dus je applicatie standaard 15 of 30 dagen laat werken voor het niet meer werkt, en in die tussentijd via internet dan wel telefonisch kan activeren, is er geen probleem.

2. De gebruiker gaat verhuizen. Hij of zij moet de NAW-gegevens dus aan kunnen passen, met alle fraudemogelijkheden van dien.. Iets creatiefs voor bedenken dus! Wellicht kun je de serienummers + NAW-data koppelingen centraal opslaan op bijvoorbeeld een eigen server. Op die manier heb je altijd onder controle welke NAW-gegevens er gebruikt kunnen worden, en kun je dit vergelijken met de boekhouding van je licentieverkoop.

Succes, leuk plan maar je moet met een hoop zaken rekening houden.

Met die activatie heb je dit ook ondervangen, want je houdt zelf bij op een eigen server welk serienummer op welke pc (hash van hardware en computernaam) gebruikt worden bij welke klant. Beter inzichtelijk dus...

[c00kie]

IVY :
1. pc crash, nieuwe installatie...

Geen probleem, pakket kopen, is onbeperkt aantal licenties. Het gaat hier over de kleine zelfstandige, de kleine familiezaakjes waar 1 persoon, misschien 2 in samenwerken...

[qoute] IVY :
2. De gebruiker gaat verhuizen. ...
[/quote]
Hij mag gaan en staan waar hij wil, enkel zijn naam en ondernemingsnummer mogen niet veranderen. Rest van adresgegevens is aan te passen via instellingenschermpje

c70070540 :
Als je dus je applicatie standaard 15 of 30 dagen laat werken voor het niet meer werkt, en in die tussentijd via internet dan wel telefonisch kan activeren, is er geen probleem.

Het gaat om een simpel client toepassingske, met een lokale databank achter. Activeren via internet ofzo is niet een van mijn doelstellingen omdat ik dat dan ook nog allemaal moet voorzien, en dat is gewoon buiten de scope van het project.

c70070540 :
Met die activatie heb je dit ook ondervangen, want je houdt zelf bij op een eigen server welk serienummer op welke pc (hash van hardware en computernaam) gebruikt worden bij welke klant. Beter inzichtelijk dus...

Onmogelijk om een server op te zetten om dit allemaal te controleren. Laat staan dat ik weet hoe ik hier aan zou moeten beginnen.

[ Voor 90% gewijzigd door c00kie op 21-10-2005 10:44 ]

[elTigro]

hmm. het lijkt wel alsof iedereen iedereen wil overtuigen van zijn eigen gelijk.
maar even naar c00kie:
kun je niet gewoon een hash maken met o.a. een uniek hardware nummer (processor id misschien/ mac adres)? Wanneer je dit opslaat in het register of waar dan ook, en idere keer op checkt bij het starten van je programma (dus iedere keer even opnieuw de hash berekent) en vergelijkt met wat er in het register staat en aan de hand van die vergelijking afbreekt of doorgaat?
lijkt mij het makkelijkste. en in C kun je dan heel gemakkelijk crypt() gebruiken (weet ik toevallig). in C++ ben ik niet zo thuis, maar het lijkt met dat je nog steeds crypt () kunt gebruiken dan.

[c00kie]

BK1 schreef op vrijdag 21 oktober 2005 @ 10:47:
....
kun je niet gewoon een hash maken met o.a. een uniek hardware nummer (processor id misschien/ mac adres)? ...

Neen, want ik wil dus vermijden dat de klanten mij moeten bellen indien ze nieuwe hardware gekocht hebben, of dit op een andere computer willen uitproberen. Eens het programma gekocht, moet het voor hen altijd werken...

[Update]
Ben momenteel RSA aan het bekijken. (thx to DAOS)
[/Update]

[wizzkizz]

c70070540 schreef op vrijdag 21 oktober 2005 @ 10:33:
[...]
Naar mijn idee, wil de TS alleen maar dat illegaal gebruik van zijn applicatie vermeden wordt...

[...]
Inderdaad, leuk bedacht, maar er kleven in de beheer omgeving van de werkplekken grote bezwaren aan. Er zijn makkelijkere methoden voor beheer, en die ook te implementeren zijn.
EDIT: Ik lees verkeerd, vergeet deze reactie maar....

[...]
Als je dus je applicatie standaard 15 of 30 dagen laat werken voor het niet meer werkt, en in die tussentijd via internet dan wel telefonisch kan activeren, is er geen probleem.

[...]
Met die activatie heb je dit ook ondervangen, want je houdt zelf bij op een eigen server welk serienummer op welke pc (hash van hardware en computernaam) gebruikt worden bij welke klant. Beter inzichtelijk dus...

Volgens mij denk jij te moeilijk: het is geen enkel probleem om op elke pc dezelfde serial in te geven, aangezien er niet wordt bijhouden welke hardware in de pc's zit. Volgens mij kunt je het vergelijken met een unattended install van windows waarbij je je corporate key in je unattended-file hebt staan. Met dat verschil dat je deze app dan direct kunt gebruiken (ongelimiteerd) en windows nog moet gaan activeren.

Het enige doel van die serial is dus het bijhouden van de naam van de onderneming + het ondernemingsnummer, zodat een ander bedrijf dat dezelfde serial gebruikt, op alle prints de naam en het nummer van degene krijgt aan wie de serial oorspronkelijk is uitgegeven ipv zijn eigen gegevens.

[ Voor 11% gewijzigd door wizzkizz op 21-10-2005 10:58 ]

[Nvidiot]

Het kan aan mij liggen maar volgens mij leest niemand wat de TS wil...

De TS wil een manier om een registratie code te koppelen aan een nummer en naam. Als de gebruiker een andere registratiecode invult verandert het nummer en het naam, en is dus de applicatie onbruikbaar. Er wordt totaal niet gesproken over activatie, unieke codes voor elke pc waarop het geinstalleerd wordt etc.

De oplossing lijkt mij RSA. Versleutel het nummer en de naam met je private key en stuur dit naar de klant. De klant zet dit in het programma. Het programma start op, gebruikt de public key (die vast gecodeerd staat in het programma) om het versleutelde blok te decoderen en op de prints te zetten.

De public key moet in het programma vast zitten omdat het anders eenvoudig is om een nieuw private/public key paar aan te maken en daarmee een nieuwe licentie te maken met een ander nummer & naam. Dat kan alsnog als de public key in het programma verstopt is, maar is al wat lastiger dan wanneer het los meegeleverd wordt.

[c00kie]

Nvidiot schreef op vrijdag 21 oktober 2005 @ 10:57:

De TS wil een manier om een registratie code te koppelen aan een nummer en naam. Als de gebruiker een andere registratiecode invult verandert het nummer en het naam, en is dus de applicatie onbruikbaar. Er wordt totaal niet gesproken over activatie, unieke codes voor elke pc waarop het geinstalleerd wordt etc.

De oplossing lijkt mij RSA. Versleutel het nummer en de naam met je private key en stuur dit naar de klant. De klant zet dit in het programma. Het programma start op, gebruikt de public key (die vast gecodeerd staat in het programma) om het versleutelde blok te decoderen en op de prints te zetten.

De public key moet in het programma vast zitten omdat het anders eenvoudig is om een nieuw private/public key paar aan te maken en daarmee een nieuwe licentie te maken met een ander nummer & naam. Dat kan alsnog als de public key in het programma verstopt is, maar is al wat lastiger dan wanneer het los meegeleverd wordt.

Dit is mooi uitgelegd wat ik wil ja. Ik ben dus RSA aan het bekijken, en het lijkt mij wel wat. Het enige dat ik nog moet doen (het meeste werk wel) is dit in code gieten, maar dat lijkt mij een leuke uitdaging. (ok, google kan me wel helpen, maar ik wil ondertussen mijn programmeerskills ook nog een beetje onderhouden hé .)

[elTigro]

c00kie schreef op vrijdag 21 oktober 2005 @ 10:54:
[...]

Neen, want ik wil dus vermijden dat de klanten mij moeten bellen indien ze nieuwe hardware gekocht hebben, of dit op een andere computer willen uitproberen. Eens het programma gekocht, moet het voor hen altijd werken...

Ik bedoelde die hash laten maken door je installatie programma

[ Voor 1% gewijzigd door elTigro op 21-10-2005 11:01 . Reden: woordje laten ]

[Gé Brander]

Nvidiot schreef op vrijdag 21 oktober 2005 @ 10:57:
Het kan aan mij liggen maar volgens mij leest niemand wat de TS wil...

Volgens mij weet de TS zich zelf niet duidelijk uit te drukken. Hij wil iets. Maar als je bij zijn doel kijkt, geeft hij een oplossing. Op basis van die oplossing die hij bij Doel beschrijft, denk ik dat zijn werkelijke doel, het onaantrekkelijk maken van het kopieren van zijn applicatie is.

Maar ik kan het fout hebben hoor. Maar doel en oplossing zijn twee verschillende dingen die nogal eens verward worden.

[c00kie]

c70070540 schreef op vrijdag 21 oktober 2005 @ 11:01:
[...]

Volgens mij weet de TS zich zelf niet duidelijk uit te drukken. Hij wil iets. Maar als je bij zijn doel kijkt, geeft hij een oplossing. Op basis van die oplossing die hij bij Doel beschrijft, denk ik dat zijn werkelijke doel, het onaantrekkelijk maken van het kopieren van zijn applicatie is.

Maar ik kan het fout hebben hoor. Maar doel en oplossing zijn twee verschillende dingen die nogal eens verward worden.

je hebt het enige zinnetje dat niet van belang was geknipt. De omschrijving van NvIdiot was perfect!!!

[leuk_he]

Nvidiot schreef op vrijdag 21 oktober 2005 @ 10:57:
De oplossing lijkt mij RSA. Versleutel het nummer en de naam met je private key en stuur dit naar de klant. De klant zet dit in het programma. Het programma start op, gebruikt de public key (die vast gecodeerd staat in het programma) om het versleutelde blok te decoderen en op de prints te zetten.

Hoewel je cryptografisch de boel dicht hebt heb je 2 grote problemen:

Je key wordt vrij lang. Als die overgetikt moet worden.....
De key is dan onbreekbaar, de applicatie is uiteraard wel binary te hacken. [if hash=correct ]veranderen in [ if true]. Wil je daaromheen dan kun je beter gaan kopen.

Laat ook wat ruimte over in je uiteindelijke key voor meer features (zoals activatie tot een bepaalde datum)


Mocht je het toch willen: je kunt kant en klaar libraires met alle hash/public key functies gewoon op internet vinden b.v. http://www.openssl.org/ (apache style licence, dus je mag er alles mee),

[Blacksnak]

Ben ik tijdens m'n stage een paar jaar geleden ook eens lange tijd mee bezig geweest, maar nooit echt een fatsoenlijke oplossing gevonden zonder te zitten met ongelooflijk lange karakter-reeksen. Toen maar van idee afgestapt en doorgegaan met creatie van uniek nummer op basis van processor en ahv dit nummer de gebruiker een activatiecode te geven. Vond het een klotesysteem om als gebruiker mee om te gaan (installatie moest altijd bevestigd worden per foon of mail + wijzigingen aan pc zorgden voor het feit dat er een nieuwe code nodig was) maar het werkte wel mooi!

[Gerco]

Decrypten is helemaal niet nodig, ik heb voor mijn werk een tijd geleden zo'n systeem gemaakt en dat werkte als volgt:

Licentie wordt samengesteld uit een aantal pakketten en aantallen daarvan (bijvoorbeeld aantal named users). Dat wordt allemaal in 1 string gestoken, samen met de bedrijfsnaamnaam en eventuele andere gegevens (kvk nummer/ondernemingsnummer). Als laatste voer je aan die string (die inmiddels aardig lang is geworden, maar dat maakt niet uit) een geheim component toe wat alleen jouw applicatie kent, gewoon een paar (10+) willekeurige tekens.

Hierover haal je een one-way hash, zoals md5 of sha-1, het resultaat uppercase je, voeg een paar streepjes toe (bij elke 5 chars ofzo) en presto. De klant voert nu in jouw applicatie zijn licentie, naam en ondernemingsnummer in en de key die je hebt gegenereerd. Je app doet hetzelfde truuckje nogeens en kijkt of er dezelfde key uitkomt, zo ja -> geldig.

Is niet computer gebonden, maar alleen gebonden aan bedrijfsnummer en naam. Kraken is vrij lastig voor de leek, maar als men je geheime string ontdekt ga je nat. Dat is een risico wat meestal prima aanvaardbaar is bij applicaties die je niet in de winkel kan kopen (groot publiek, groot risico). In ons geval kenden we alle klanten, aangezien je de software alleen direct bij ons (en resellers) kon kopen.

Wil je betere beveiliging kun je die string van licentieopties, bedrijfsnummer en naam encrypten met een asymmetrische key en alleen de public key in je app stoppen. Op die manier ben je veel beter beveiligd, maar zul je echt naar een licentiefile achtige oplossing gaan kijken, niemand wil zo'n lange string overtikken

[c00kie]

Gerco schreef op vrijdag 21 oktober 2005 @ 11:31:
...

Interessant. ga dit eens onderzoeken , want met RSA krijg je inderdaad verschrikkelijk lange nummers. wil mijn klanten nu ook geen half uur cijfertjes laten inkloppen hé .

[Verwijderd]

@ Gerco: Dit is idd een goeie oplossing, werkt voor de TS perfect denk ik.

Ik als systeembeheerder:
Ik vind het GRUWELIJK irritant dat bedrijven licenties aan hardware koppelen, of dat ik moet activeren via email/telefoon (neem bijvoorbeeld SPSS 13). Kost me teveel werk om dat op 10 werkstations te installeren. Doe het net als bij Microsoft, gewoon geen activatie (corp install cd's enzo). Kost mij als beheerder van een desbetreffende applicatie geen moeite om hem te installeren, anders ben ik te lang bezig.

Ik als programmeur:
Ik maak normaal gebruik van een MD5 Hash die ik aanmaak op mijn eigen server (tijdens informatie aanvraag via website), die verstuur ik per email/post/whatever naar de klant toe. De MD5 hash wordt gevalideerd op mijn server, zodat ik kan bepalen of klanten het product mogen gebruiken op het moment, of niet (wanbetalers kunnen per DIRECT het product niet meer gebruiken). Ook kan ik adhv dit makkelijk zelf producten toevoegen, of ze de rechten tot een bepaalde module toekennen. Zonder dat de desbetreffende gebruiker zijn key moet aanpassen.
Ik geef de klant ook de mogelijkheid om bij een uitval door te werken, ik eis dat er "minimaal" 1x in de 2 weken een check op internet gedaan wordt (als ze overstappen/uitval/whatever). Zodat ze niet gebonden zijn aan problemen van mijn kant, of het netwerk wat aan hun kant raar doet. Dit moet eigenlijk nog over een HTTPS verbinding, maar dat doe ik niet voor ieder stukje software.

Ik heb ook halve open-source projecten die ook bepaalde services hebben waar je voor moet betalen. Dit draai ik dan altijd op mijn eigen server, zodat ze zelf de source nooit krijgen. Dit gaat adhv een key die bij hun in de configuratie staat. Daarmee kunnen ze aanmelden op mijn systeem. Maargoed dat is een heel ander verhaal.

[Gerco]

Ik bedenk me net dat je asymmetrisch kan encrypten en toch redelijke keys kan houden

Pak je lange string (dat geheime component is niet meer nodig) en haal daar een md5 overheen. Vervolgens encrypt je het resultaat met je private key. Op die manier wordt de string niet zo lang (hoe lang moet je even testen) en ben je toch een stuk veiliger dan met die md5 alleen. Je programma kan dan vervolgens dezelfde string berekenen en de key decrypten met de public key. Als het resultaat van de md5 en de decryptie hetzelfde is, is de key valid.

Mocht de key te lang worden, kun je er ook voor kiezen om een gedeelte van de md5 te nemen (de eerste 16 chars ofzo) of de md5 niet hexadecimaal, maar base-64 encoded te gebruiken. Voegt allemaal complexiteit toe die waarschijnlijk onnodig is, maar ik wilde je toch even van de mogelijkheid op de hoogte brengen

Ga overigens niet die encryptie en hashing algoritmen zelf zitten implementeren, maar gebruik er een library of beschikbare en getestte sourcecode voor. De kans dat je een fout maakt als je dit voor het eerst doet is bijna 100% en het is toch vervelend als je klant met een geldige key niet kan werken.

[ Voor 18% gewijzigd door Gerco op 21-10-2005 12:16 ]

[Gé Brander]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 12:07:
@ Gerco: Dit is idd een goeie oplossing, werkt voor de TS perfect denk ik.

Ik als systeembeheerder:
Ik vind het GRUWELIJK irritant dat bedrijven licenties aan hardware koppelen, of dat ik moet activeren via email/telefoon (neem bijvoorbeeld SPSS 13). Kost me teveel werk om dat op 10 werkstations te installeren. Doe het net als bij Microsoft, gewoon geen activatie (corp install cd's enzo). Kost mij als beheerder van een desbetreffende applicatie geen moeite om hem te installeren, anders ben ik te lang bezig.

Inderdaad, SPSS is ook zo een drama pakket inderdaad. Te gruwelijk voor woorden.

[c00kie]

ok, ga proberen om systeem van gerco in te bouwen.

Momenteel heb ik in c++ mijn progje waar ik mijn tekst mee door MD5 hash kan halen, dus mijn serienummer is aangemaakt... Nu moet ik alleen nog een manier vinden om hier een dll van te maken, want vanuit eclipse lukt mij dit niet . ('k werk nog nie zo lang terug met c++...)
Die dll heb ik nodig omdat mijn facturatie prog in powerbuilder is geschreven, en van daaruit zou ik dan die dll willen aanspreken om de md5 string te gaan controleren. (als die dll lukt, is eigenlijk alles klaar...)

In ieder geval allemaal al bedankt voor de moeite hé

[Gerco]

Met de Microsoft CryptoAPI kan het ook: http://www.rgagnon.com/pbdetails/pb-0170.html

[c00kie]

Gerco schreef op vrijdag 21 oktober 2005 @ 15:50:
Met de Microsoft CryptoAPI kan het ook: http://www.rgagnon.com/pbdetails/pb-0170.html

Ben jij god ofzo? Man, jij bent vandaag mijn held !!!

In ieder geval ga ik toch nog altijd voor mezelf proberen om de dll aan te maken, maar met dit voorbeeld ben ik helemaal waar ik moet zijn.