Difetti nel mio sistema di verifica della licenza proposto?

Question

Difetti nel mio sistema di verifica della licenza proposto?

#1 da (3 voti)
#2 da (2 voti)

2

nella mia azienda, la maggior parte del software è garantita da un paio di diversi sistemi di licenza antiquati. Ad esempio, dopo l'installazione, l'utente deve avviare un altro programma che indichi il suo ID macchina calcolato. Ha bisogno di inviarci questo id, che è incorporato in un file, crittografato e spedito con un'altra configurazione, che copia semplicemente il file nella cartella pertinente. Non solo questo genera molto carico di lavoro e un ostacolo per l'utente, la chiave di decrittografia deve essere incorporata nel nostro software e può essere facilmente estratta, consentendo all'utente di eludere questa misura di "sicurezza".

Dopo aver sviluppato la mia prima applicazione per questa azienda, mi piacerebbe sviluppare un prototipo per un sistema di licenze più avanzato con il mio servizio. Sto cercando di eseguire il mio piano generale da parte tua, sono sicuro di aver trascurato alcune cose e mi piacerebbe averle indicate prima di portarlo alla gestione ..

Piano:

Il client riceve automaticamente una chiave di licenza dopo la registrazione
Il client inserisce questa chiave di licenza nella mia applicazione
L'applicazione invia questa chiave con le informazioni sulla macchina e invia una richiesta GET_LICENSE al nostro server
Il server controlla se la chiave di licenza è nel nostro sistema e restituisce un messaggio crittografato con pgp al client
Il client usa la sua chiave pubblica incorporata per controllare il file di licenza e la data del segno (che dovrebbe essere sicuro, (finché è stato firmato dalla nostra parte) ( link ))
Se non è disponibile alcuna connessione Internet, avviare l'applicazione se il file di licenza è disponibile e la data di firma non è precedente a n giorni
Aggiorna il file di licenza ogni volta che viene effettuata una connessione a Internet

Ora mi rendo conto che non esiste una sicurezza completa, ma questo dovrebbe darci molta più sicurezza e avvantaggiare i nostri clienti onesti con un'esperienza più constrongvole di prima. Una connessione Internet sarebbe richiesta solo al primo avvio e poi a giorni alterni, ma la nostra applicazione ha già bisogno di una connessione per la maggior parte delle attività. Risparmieremmo le ore di lavoro per la creazione di licenze manuali e la comunicazione con il cliente permettendogli di registrarsi e utilizzare la nostra applicazione, indipendentemente dalle ore di ufficio e dalla disponibilità. Nessuna informazione sulle credenziali potrebbe essere estratta dalla nostra applicazione.

Contro?

license-enforcement

posta Sven 19.01.2016 - 09:36

fonte

2 risposte

2

Data la risposta al commento, direi che è un buon miglioramento della tua architettura esistente. Nello specifico, è possibile attivare gli allarmi se gli ID macchina diversi di esempio vengono visualizzati per la stessa chiave in un intervallo di tempo ravvicinato, diciamo 1 settimana o anche 1 mese (la reinstallazione di un hardware danneggiato subito dopo la prima installazione può essere improbabile). In questo caso, tuttavia, puoi contattare il cliente e chiedere.

Come cliente, se mi è stato detto che la licenza verrà controllata online ogni pochi giorni circa, non cercherò di ingannare il sistema. Potrei forse provare solo a far funzionare la virtualizzazione, ma puoi contrastarlo se per esempio hai cancellato gli indirizzi MAC. Anche in un ambiente virtuale gli addi MAC devono essere in qualche modo unici;)

Forse vuoi prendere in considerazione un dongle USB, anche se è "vecchio stile", è il sistema più complicato da imbrogliare.

risposta data 19.01.2016 - 11:51

fonte

Leggi altre domande sui tag license-enforcement

Dati della carta di credito inviati come formato immagine normale [chiuso] Il rapporto Nessus mostra una vulnerabilità iSCSI

score 3 · Accepted Answer

Il tuo design è praticamente lo stesso della maggior parte dei sistemi di licenza. Un passaggio in più è offuscare la tua applicazione, quindi è più difficile decompilare.

Quanto è sicuro questo? Certamente ostacolerà un utente tipico. In effetti, anche il vecchio sistema con una chiave integrata fermerà la maggior parte degli utenti. Mentre tu dici che è facile estrarre la chiave, cioè dal punto di vista di un programmatore esperto, non un utente tipico.

Non fermerà un abile cracker. Anche se non possono creare un file di licenza falso, ciò che possono fare è modificare il file binario dell'applicazione e rimuovere il codice che controlla la licenza. L'offuscamento rende questo più difficile, ma nessuna offuscazione è infallibile.

La vera preoccupazione è che ci vuole solo un cracker esperto per rompere la tua applicazione, e possono quindi mettere la versione crackata su BitTorrent. Questo potrebbe non essere la fine del mondo. Molte persone compreranno ancora la versione ufficiale. Forse sono solo onesti, o non sanno come trovare software crackizzati, e molte persone sono giustamente preoccupate per i virus che arrivano con software crackizzati.

In definitiva, mentre il tuo cambiamento è un miglioramento della sicurezza, non penso che faccia una differenza sostanziale se il tuo software può essere incrinato. Sembra comunque un eccellente miglioramento dell'usabilità.