Sziasztok Nálam Okosabbak! :D
Az a helyzet, hogy írtam egy elég speciális, mérnöki szoftvert, amit szeretnék valamilyen formában terjeszteni. Azt gondoltam ki, hogy lesz egy kissé korlátozott funkcionalitású, ingyenes és egy némi aprópénzért licencelhető teljes változata.
Azt a megoldást találtam ki, hogy a gép egy "egyedi" (pl mac address, lemez sorozatszám) azonosítóját megsózóm és generálok hozzá egy MD5 vagy SHA1 ellenőrzőösszeget. A program egy netes apival elküldi ezt az azonosítót és visszakap egy karaktersort (pl json) és egy ellenőrzőösszeget. Ha a visszakapott adatok stimmelnek, fut a program, ha nem, akkor nyafog.
Ez így elegendő? Mik lehetnek a gyengeségei? Mekkora esély van rá, hogy a felhasználó rájön, hogyan kerülhetné meg ezt a dolgot? Van erre jobb megoldás? Fizikai (hardver kulcsos) védelmet nem szeretnék.
Azzal nincs baj, hogy ha nincs net, akkor a program sem tudja ellenőrizni a jogosultságot, és nem indul el. Így olyan mint pl. egy online számlázó. A felhasználó ennek tudatában van/lesz.
Hozzászólások
"A program egy netes apival elküldi ezt az azonosítót"
Nem foglalkoztam még a témával, szóval csak ötletelés: Nincs erre valami kész felhős megoldás (a licensz kezelésre), ha már úgyis netes api-n gondolkozol? Meg lennék lepve, ha nem lenne több kész, kiforrott megoldás is erre. Egyébként nem hiszem, hogy a mac address vagy a lemez sorozatszám a jó megoldás (és az is hardver kulcsnak tűnik nekem. :) ), szerintem inkább login-os felhős megoldás kellene, ahol felületet is kapsz esetleg a monitorozásra, és a licenszek kezelésére. Mármint a programod felhasználói loginolnak be, és a programot folyamatosan ellenőrizheti futás közben, hogy van-e jogosultságuk. Esetleg kaphatnak egy adott ideig érvényes (aláírt) tokent, még csak net sem kell hozzá utána, csak egyszer, és az aláírás pedig lejár egy idő után. - tényleg csak ötletelés
"generálok hozzá egy MD5 vagy SHA1 ellenőrzőösszeget" - Ócskább nincs? :-) A neten küldözgetett adatok esetén ha nem készíted fel az alkalmazást és a szerver oldalt a kölcsönös azonosításra, akkor "simaliba" lejátszani egy fake szerverrel a "jó, rendben" választ. (Lehet fokozni azzal, hogy csak saját, alkalmazásba beforgatott CA-val aláírt szerverkulcsot fogadsz el, és annak a binárisnak, amibe a kulcs bele van forgatva, a sértetlenségét is vizsgálod...
A dolog messzire vezet - a kérdés az, hogy mennyi erőforrást szánsz rá, illetve hogy a nem fizetős verziónak milyen korlátai lesznek a fizetőshöz képest?
Erre a közbeiktatott szerveres dologra gondoltam, ezért dob még vissza szerver egy valamilyen algoritmus alapján gyártott ellenőrző összeget is, amit kliens oldalon vizsgálok. Nyilván megfejthető ez is.
A projekt első körben saját, belső használatra készült, de megemlítettem pár külsős embernek, elég komoly érdeklődést mutattak rá. Sok pénzt/időt nem szeretnék beletolni a védelembe. Talán majd ha felhasználószám átlép egy bizonyos határt.
I hate those Smurfs!
"A projekt első körben saját, belső használatra készült" - ha munkakörödhöz kapcsolódó fejlesztés, akkor a jogi részének is nézz alaposan utána, nehogy meglepetés érjen...
"... alkalmazásba beforgatott CA-val aláírt szerverkulcsot fogadsz el ..."
Ekkor már a CA és egy publikus kulcsot bele lehet tenni a binárisba. Induláskor beolvas egy config szerű file-t, amiben az, hogy milyen funkciókat, milyen gépen, mikor lehet használni. A config file-t meg alá tudja írni a privát kulcsával, amit akkor küld el, amikor kifizették a programot. Másik gépen a valamilyen módszerrel generált gép azonosító nem fog jó lenni, módosított config file esetén meg az aláírás lesz invalid.
A gyenge pont, hogy mennyire egyszerű lecserélni a binárisban a CA és publikus kulcsot és mennyire lehet módosítani a funkció ellenőrzést. Például itt ott be lehet tenni ellenőrzést, hogy a CA vagy az egész bináris valamilyen ellenőrző összege jó-e, ha nem akkor elkezdhet hibázni a program, mondjuk méretezésnél a biztonsági tényezőhöz hozzá ad egy véletlen számot. Egy meghekkelt méretező programmal így pl. nem 20cm minimális vasbeton födém vastagság jön ki, hanem 5m. Lefele eltéríteni a méretezést még hekkelt program esetén sem lenne etikus. Esetleg lehetne az üzeneteket randomizálni, így egyre értelmetlenebb szövegek jelennének meg módosított binárissal. stb. stb.
Én ezt akartam használni: https://cryptlex.com, aztán nem lett semmi a projektből :-)
Kösd hardver kulcsos kétfaktoros azonosításhoz, pl yubikey és tarts szerver oldalon kritikus komponenst. Akkor tuti annyi darabot használnak amennyiért fizettek.
Ha kliens oldalon van minden szükséges kód, ha megéri a melót, el fogják lopni, ezen ne is görcsölj. Ezért vedd ki a lelkét és védd meg a távoli hozzáférését, erre már vannak jó akár dobozos megoldások.
+1, kb mindenben egyetértek, hasonló cipőben jártam én is.
A vevőkör azért nem mindegy. Nekem pl állami intézmények a vevőim, ahol nem divat feltörni a programot, és kiszedni belőle a hardverkulcsos védelmet, ezért az még megy.
Demo verzióra ez persze szóba sem jöhet, ott tényleg a fő funkciót távoli szerveren futtatni az egyetlen épkézláb ötlet.
Ha gyengus a licenc kezelés, akkor inkább már egy Donate gomb :)
Szerintem is, így a funkcionalitásra tudsz koncentrálni.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Az ilyen alkalmazásoktól azért félnék, mert megveszem a cuccot, de aztán 2-3 év múlva a cég meszűnik vagy valami és utána lelövi a szervert. Én meg ott állok egy bejáratott programmal, amiért fizettem, de kell keresnem helyette mást és betanítani a népet.
Üdv a (szép új) klaud világban, ahol már semmilyen szoftver használati joga nem kerül véglegesen a tulajdonodba, csak amíg aktívan előfizetsz rá.
Például lehetne, hogy minden vevő egyedi programpéldányt kap, amiben minden képernyőn (listán stb) látszik a vevő neve.
Erre azért vannak már megoldások, ne akard kitalálni a meleg vizet. Milyen programozási platformot használsz?
Eleve, szoftverpéldányt gépre adsz el? És ha közben kihal a gép alólam, akkor mi van? Nem érvényes a megvett szoftverem? Stb.
Erre látam gyakorlatban jó megoldást:
Szóval működik, DE ez egy <20 eFt árú, nem milliók által használt szoftver. Ennyi pánzért nem érdemes feltörni!
Tehát nem az a kategória, amire az életedet is rábízod.
A másik kategória a 4-6 nagysegrenddel drágább szoftver, ahol a kulcs a szerződés. ;)
Igen, van ilyen licencmegoldás is. De épp ezért írtam, hogy ne akarja feltalálni OP a melegvizet, hanem nézze meg, mások ezt hogy csinálták, keressen megoldást erre, library-t, frameworköt, szolgáltatást stb. Mert mások sok olyan esettel találkozhattak, amire ő nem gondol (a legegyszerűbb példa volt, amit én írtam).
Hát persze.
Először nem a megoldás a lényeg. A termék ára, az eladott példányszám, a forgalmazás és a használat módja után lehet gondolkozni a megoldáson. Aztán, ha szükség van a védelemre, akkor az se baj, ha olyasvalaki csinálja, aki tisztában van a fogalmakkal vagy akár csinált már ilyet.
Egy példa: Hozzánemértők csináltak licenckezelést is, hardver védelmet is. (Az egyik termék hardver volt.) Majd arra lettek figyelmesek, hogy Európában megjelent ugyanaz a hardver - ami az ő szoftverükkel működött ;) - féláron. Természetesen kínai gyártmány. :-D
Pont ennek a cégnek adtunk volna át egy termékünket, amit a kollégák láttak el termékvédelemmel. Ezt a hozzánemértők 10 perc alatt törték fel. :-D Na, akkor mondtam, hogy csináljuk úgy, ahogy lerajzoltam. Azóta csend.
Szoftver védelmet az esetek többségében fel lehet törni, csak idő kérdése. Ismerek olyat, aki egyetemista korában kilóra törte az ilyeneket. Hardverkulcsos védelmet még én is törtem. És meg is írtam a gyártónak, hogy miért tisztességtelen a megoldásuk.
A mi megoldásunk törhetetlen:
hardver - szoftver (licenc kulcs lekérés) - licenc szerver
A szoftver adja az utasítást+aktuális kulcsot a hardvernek a működéshez. A vastagított elemek végzik a következő kulcs kiszámítását, ami aes256 csomagolású. Már csak a szervert es a hardvert kell védeni.
Visual Studio, C#, Windows Forms
Ha a gép elhalálozik, stb, a felhasználó jelzi, a régi kulcsot inaktiválom, újat regisztrálok helyette.
I hate those Smurfs!
És mi van azzal az esettel, hogy én több gépen akarom használni a szoftvert, de egyszerre (egy időben) csak egyen? Például az irodai desktopon meg otthon home office-ban a laptopomon is? Vagy erren me lesz szükséged?
A yubikey-es megoldás olcsó és jó hardverkulcs lehet. Viszont valamerre a kódban, ha ez egy elágazás, hogyha jó a kulcsod akkor fut, ha nem jó akkor pedig nem működik tovább, akkor lényegében egy kis módosítással az elágazás két ága a kedvező irányba vihető. (bináris patch)
Ha beleteszel valami azonosítást külső szerverre, esetleg valami funkcionális részt a külső szerver számol ki, működtet, akkor már érdekesebb lesz a helyzet feltöréskor.
Viszont ilyen esetben legyen több licenc szervered, hiszen ha valaki fizetett a szoftverért akkor joggal várja el annak működését is, mindig, éjjel nappal. Ezt a licencelt időtartam alatt akár 1 licenc miatt is biztosítanod kell majd.
Lehet lesznek olyan helyek ahol nincs internet, pl. nem kapcsolódhat külső irányba semerre a gép, ha ilyen nincs vagy tűzfalon mégis kiengedhető feléd a forgalom akkor nyerő lehet. Vagy kell valami offline lejáró kulcs megoldás is.
Ha kiengednek egy titkosított kapcsolatot a kulcscsere és egyéb információ csere miatt a szervered felé, akkor felvetheti a kérdést, hogy mit forgalmazol a titkosított adatokban. Ha nem titkosítod az adatátvitelt, akkor a pedig törhetőbb a rendszered.
A program logikája, működési elve nagyon meghatározó lehet, hogy csak a kliens pc-n kell-e futnia, vagy akár több kliens pc-n egy hálózaton belül. Egyáltalán valamilyen funkció kihelyezhető-e szerverre. Mi lesz ha nem megy a szerver.
Lehetséges lehet a licencelési megoldásodat külön futtatni, pl. akár hálózaton belül külön gépen, aminek van internet elérése, és a többi kliensnek nincs. Lehet a hardver kulcs továbbra is akár egy yubikey. Tárolhat a yubikey pl. 1 hétre érvényes kulcsot, amit a lejárat felénél akár frissítesz. Ez a külön gép lehet egy SBC (pl. Raspberry Pi) + hardware token ami megbízható (pl. Yubikey).
Hasonló dolgok miatt néztem, kerestem kész megoldásokat. Lényegében akkor alkalmazkodok ahhoz, nem pedig az az én logikámhoz, pl authentikáció és authorizáció területén. Ezenkívül iszonyatos mennyiségű tákolást kellene még hozzátenni, pl. a LOG-olás, tiltó szabályok kezelése, egyedi modulok stb... miatt. Nekem így jelenleg tervezés alatt van saját cuccaimhoz saját rendszer.
Abból kiindulva, hogy egy mindenki által használt hetente frissítendő rendszert mennyien próbálnak feltörni, lehet nem is mennék előre gyártott irányba.
Hogy, hajbazert idézzem, az maradjon meg a babzsák fejlesztőknek. 2-3 hét alatt illesszék meg debuggolják a v2.3.4 működési különbségét a v2.3.3-as verzióval. Maradjon azoknak akik az objektumorientált programozásánál már olyannyira objektumokban gondolkoznak, hogy dobozokat kötnek össze valami színes szagos GUI-ba, ami még árnyékot is rak a dobozok alá. (Persze csak ha egy bitcoin bányás videókártyád van).
Én így állnék neki: keresek egy ügyvédet, és fizetek neki bőven, hogy jól összerakott anyagot írjon, mert az a legfontosabb. Aki nagyon fel akarja törni a cuccod, úgyis feltöri. Tehát a technikai megoldásra alig szánnék időt/pénzt. Legyen pl. egy kulcs fájl akármilyen béna titkosítással, amit a program beolvas és kiírja, hogy regisztrált XY részére vagy nem regisztrált. Vagy ha nagyon parázol, akkor a binárisba legyen belefordítva a licenc kulcs és akár a nem regisztrált modulok bele se forduljanak, és mindenki egyedi bináris kap. Esetleg lehet egy szervert pingelni induláskor, hogy tud, melyik kulcsot mikor és hányan használják. A jó ügyfeleknek ez pont elég, a rossz ügyfelekkel meg ne foglalkozz.
Sw árától függően jó a belefordított egyedi azonosító, célszerűen úgy, hogy _ne_ látszódjon a felületen, _ne_ jelenjen meg sehol(!), az így készült bináris legyen aláírva a fejlesztői certtel - a bináris matatása ellen "pipa", a lemásolja és továbbadja ellen úgy "pipa", hogy adott binárisról lehet tudni, hogy hanyadik build, és az kinek készült, online licenszkéréssel lehet okosítani úgy, hogy a saját adatait (pl. a bináris sha512-es hash-e) küldi fel a licenszszerverre a gép egyéb adataival (jogi háttér rendezendő!)...
De ahogy bucko kolléga írta, meg kell nézni, mennyi az annyi, mennyi erőforrást érdemes a védelembe, illetve a túloldalon annak feltörésébe beletolni, és a vállalható költségből elindulva megoldást keresni.
Általánosságban igaz, hogy mérlegelni kell. De indulj ki abból, hogy a kolléga a HUP-on kér segítséget. Ebből már lehet sejteni, hogy merre fog billenni a dolog. Ezért gondolom, hogy fontosabb ezt jogi oldalról bevédeni, mint technikailag.
Köszönöm szépen a sok és értékes hozzászólást. Eléggé elbizonytalanodtam.
Ez a yubikey tetszik. Bármennyire is nem akartam efféle megoldást, mégis ez látszik a leginkább probléma mentesnek.
I hate those Smurfs!
Ez annyira egyedi, hogy kb. azt állítok be, amit akarok.
Oké, de honnan fogja tudni az egyszeri felhasználó, hogy a mac addresst vagy a lemez sorozatszámot kell átírnia? Vagy, hogy egyáltalán ezek bármelyikéhez köze lenne az azonosítónak?
I hate those Smurfs!
Az egyszeri felhasználót a legkisebb védelem is visszatartja. Aki meg fel akarja törni, az bármit feltör. Ezért érdemes általában az egyszerűségre törekedni.
Így vagyok ezzel én is. Szerintem egy ilyen védelemnek elegendőnek kell lennie. Aki akkora bűvész, az úgy is feltör bármit, vagy ismer valakit, aki ismer valakit, aki tud valakit, aki felnyomja a cuccot.
I hate those Smurfs!
onnan, hogy mindenki ezeket hasznalja. meg a sokmillios szoftvereknel alkalmazott flexlm is a mac addressel megy, vagy a GIRA sokmillios homeservere is hdd serialt nez. meg az a draga DSR hangrogzito doboz is amit sok callcenterben lattam (es javitottam) mar.
20 eve is ezt csinaltak, ma is. es egyiket se nehez atverni... a dsr-nel a linux kernelt patcheltem meg, hogy mindig az elore beegetett serialt adja vissza a hdd lekerdezesnel. mac cimhez eleg egy ifconfig parancs is... de ma mar egyszerubb virtualis gepben futtatni, es ott mindenre azt allitasz be amit akarsz, meg a cpu id-re is.
a binaris egy reszet titkositod, es indulaskor sajat maga csak a megfelelo (yubi)key birtokaban tudja visszafejteni. most igy hirtelen ilyet talaltam: https://www.codeproject.com/Articles/531028/Encrypted-code-compiled-at-…
de akar lehet a lenyegi resz egy dll-ben, aminek a betoltesekor van decryptalas. persze ez se 100%-os :/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Emlékeztem egy ilyen könyvre, sztem nézd meg:
Pavol Cereven: Programvédelem fejlesztőknek - CD melléklettel
For Whites Only meeting room!
(Remélhetőleg a CD is másolásvédett volt.)
édesapám 39. éve egyetemen dolgozik. minden jegyzete nyilvános, pont ahogy a tanszéken mindenkié. én szabadon terjeszteném. a tudás szabad! ne legyünk már középkor!
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
A helyzet az, hogy a bejegyzésed irreleváns, én sem szeretem a zárt szoftvereket, és jó lenne ha minden szoftver nyílt forráskódú lenne.
Ettől még a példa rossz, édesapádat a munkájáért (ha nem is jól) megfizetik, hazaviszi, felnevelt belőle. Az OP pedig egy korlátozott felhasználószámú csapatnak kíván szoftvert eladni, és bármennyi ellenérzésem van is ez ellen hogy ezt lezárással csinálja, mégsem hasonlítható a te példádhoz.
oké, de ez nem tudás, hanem egy termék.
Domain, tárhely és webes megoldások: aWh
Mi okod van azt gondolni, hogy a "mérnökök" nem szívesen fizetnék ki az "aprópénzt" egy olyan "speciális, mérnöki szoftverért", ami hasznos számukra, illetve mekkora bevételkiesést jelentenének a lopások, és milyen költséggel (anyagi, időbeli, ön- és ügyfélszopatási hatások) járna az ellenük való védekezés?
:)
Ismerem a fajtámat :D
A mérnök társadalom egyik leginkább alábecsült rétege lenne a célcsoport. Az egyes projektek költségeinek tervezésénél legtöbbször az ő szakterületükre jut a legkevesebb. Szóval elég költség érzékenynek saccolom a felhasználókat, akik szeretik "okosba" megoldani a dolgokat. Sajnos ez a társadalom jelentős részére is igaz.
Egyelőre nem változtatnék ezen a koncepción. Az ászf-be beleírom, hogy csak azon a gépen használhatja, amire a kulcs szól, másikra csak én tudom átrakni. Ennyi.
I hate those Smurfs!
Fogok egy virtualis gepet (virtualbox, qemu, mindegy, utobbit talan egyszerubb modositani), feltelepitek ra egy olyan OS-t, amit tamogatsz, lesz neki MAC addresse, HDD-nek valami azonositoja, stb. Aztan feltelepitem ra a programodat (kiolvassa az azonositokat, elkuldi, beregisztralja, stb..), szoval lesz egy mukodo VM-em, rajta a mukodo programoddal. Aztan VM-estul az egeszet atmasolom masik 10 gepre. (mondjuk egyszerre csak egy fut kozuluk) Mukodni fog? Szerintem igen. Es elegge realis forgatokonyv.
Masik eset: fogok Win eseten valami terminalservert, (vagy Linux eseten meg egyszerubb), felteszem a programodat, es onnantol aki bejelentkezik ra, tudja hasznalni. Eletszeru? Tippre igen.
A HW azonosito ma mar szerintem semmit nem er. A HW kulcs rettento kenyelmetlenne teszi a hasznalatot (2-es esetben az is korlatozottan ved), nem fogjak megvenni, ha amugy a hardware hasznalatat nem indokolja semmi. Azzal jarsz meg mindig a legjobban, ha valami netes azonositashoz kotod, es valami lenyeges dolgot a server vegez, amit maceras lenne ujraimplementalni, vagy egy return true-val kiutni. Ha nekem kene ilyet csinalni, akkor valoszinuleg utananeznek a Steam masolasvedelmenek, rajtuk keresztul is arusitanam, es az o rendszeruket epitenem be. Ezzel eljut a legtobb potencialis felhasznalohoz (nem csak jatekok vannak naluk), es a specialis igeny miatt valoszinuleg keves embert fog erdekelni annyira, hogy feltorje.
De elegge titkolod mirol van szo, lehet, hogy a te esetedre lenne jobb megoldas is. Ennyi infobol ennyit tudok hozzatenni. A donation gomb, az olyan support, amiert megeri fizetni, a rendszeres update, esszeru ar valoszinuleg praktikusabb megoldas ettol fuggetlenul.
A strange game. The only winning move is not to play. How about a nice game of chess?
Vagy ha már napokat ölsz a másolásvédelembe, akkor ölhetsz napokat egy SaaS létrehozásába is, amit jellegéből fakadóan nehezebben tudnak fizetés nélkül használni. Továbbá nem kell minden egyes ügyfélnek egy hw kulcsot adnod/postáznod (így könnyebb terjeszteni távolabb is - gondolom nem lokalizált a probléma)
De ha már a hupon vagyunk, akkor szerintem érdemes egyéb open source business modelleket is megemlíteni.
Itt van még néhány ötlet:
https://en.wikipedia.org/wiki/Business_models_for_open-source_software
Amire még érdemes lehet gondolni, hogy a torta mérete a lényeg, nem pedig a szelet. - by Petya
Ha jól értem ez egy sima auth login egy szerveren (REST, WS, bármi) JWT visszajön benne, hogy mit lehet és mit nem. JWT privát kulccsal aláírva.
igen, csak én nem tudok ilyen szép szavakat :D
I hate those Smurfs!