Soluzione chiave di licenza nell'applicazione Web, qual è l'approccio migliore?

14

Sono sconcertato da una richiesta del mio manager. Lavoro per una piccola startup e abbiamo sviluppato un'applicazione web a tariffa fissa con un accordo di manutenzione per un'azienda MOLTO più grande. Conoscendo le storie dell'orrore su come le grandi aziende pagheranno le loro bollette solo all'ultimo secondo, abbiamo deciso che vorremmo proteggerci potendo autorizzare questa applicazione Web in modo tale che se non veniamo pagati il software non funziona più.

L'ho già visto prima per le applicazioni desktop, tuttavia questa sarà un'applicazione Web che ospiterà internamente e non sarà accessibile da Internet.

Qual è l'approccio migliore per farlo, vorremmo che avesse un ingombro ridotto e vorremmo la possibilità di rinnovare la chiave di licenza che hanno distribuito.

Qualcuno ha fatto qualcosa di simile? Siamo completamente fuori di testa? Qualcuno ha qualche suggerimento migliore?

web-development licensing web-applications

— albero_acero
fonte

Per farlo correttamente avrai bisogno di MOLTO tempo (o semplicemente lo romperanno). È molto più economico acquistare un prodotto progettato per proteggere i programmi Java. Altrimenti, trasforma la licenza in uno snippet di codice byte java che il programma legge e quindi agisce.

Questo è ciò di cui avevo paura, esaminerò le soluzioni di terze parti, ma siamo già dolorosamente esagerati.

— maple_shaft

Quindi fallo andare dolorosamente lento 2 settimane dopo il pagamento.

@ Thorbjørn, LOL !! ^ _ ^ Per quanto allettante sia questo progetto, è un leader in perdita nel tentativo di creare ulteriori affari con questa società. LA MASSIMA QUALITÀ è della MASSIMA importanza. Allo stesso tempo, non vogliamo essere completamente fregati mentre stiamo cercando il vaso del miele.

— maple_shaft

@maple, sembra un brutto piano aziendale. Quindi lasciare la raccolta di denaro ai ragionieri e non prendere in considerazione la consegna di malware.

9

Esistono molti modi per implementare qualcosa del genere, ma eccone uno che non dovrebbe essere troppo difficile da fare:

È necessario un sito Web accessibile pubblicamente da qualche parte che ospita un file contenente gli hash delle chiavi di licenza che sono state inserite nella lista nera. La gestione di questo file dipende da te, ma il file stesso deve avere solo un hash per riga.

Quindi, su base ricorrente, il software avvia un download di questo file (la maggior parte delle lingue sul lato server lo prevede) e quindi cerca l'hash della chiave di licenza installata. Se viene trovato, l'applicazione sa che dovrebbe morire fino alla rimozione della lista nera.

MD5 o simili più un segreto dovrebbero essere sufficienti per questo. Potresti diventare più fantasioso e fare in modo che l'applicazione invii la richiesta al tuo sito e la cerchi in un database al volo, ma il file (per quello che presumo sarebbe, si spera, un breve elenco), si spera rimanga piccolo e potrebbe essere la via più facile.

La parte più difficile sarà mantenere l'applicazione morta. Dopotutto, devi memorizzarlo da qualche parte internamente, il che significa che se è eccessivamente ovvio potrebbe essere facilmente sovvertito e anche se non è eccessivamente ovvio, può essere facilmente ripristinato ripristinando le tabelle appropriate / File). Pertanto suggerisco anche un secondo metodo di protezione.

Questo metodo memorizzava "LIVE" o "DEAD" (o qualcosa di sufficientemente simile) in una tabella o in un file, ma di nuovo HASHed. Questo deve essere cancellato con il tuo sale E un timestamp. Ogni volta che viene eseguita una pagina dell'applicazione, controlla questo valore con una versione con hash di "LIVE" + salt + timestamp e quindi consenti un intervallo valido di timestamp (ad esempio, un giorno, due giorni, una settimana, un mese, ecc. Tieni presente che maggiore è la gamma, maggiore sarà la prestazione delle prestazioni.). Finché le cose corrispondono (o viene trovata una corrispondenza), l'app è viva; in caso contrario, anche se il valore nel file o nella tabella speciali è "LIVE", sarà comunque morto se si tenta di ripristinare dal backup perché il timestamp non rientra nella soglia.

In breve (ciò presuppone che tu abbia un metodo programmatico per verificare la validità di una chiave di licenza, come una sorta di checksum o un altro metodo):

CheckBlacklist
- Converti chiave di licenza in hash con salt
- Richiedi il file della lista nera dal server
- Il mio hash è nel file?
- Se SÌ, memorizza l'hash "DEAD" + salt + timestamp (troncato al giorno; non è necessario memorizzare ore + giorni + minuti)
- Se NO, quindi memorizza l'hash di "LIVE" + salt + timestamp (troncato)
IsKeyAlive
- Crea l'hash da "LIVE" + salt + timestamp troncato
- Carica l'hash DeadAlive
- Sono d'accordo?
- Se SÌ, allora siamo vivi; restituisce VERO.
- Se NO, allora forse siamo morti, ma potremmo essere ancora nella nostra finestra del timestamp:
  - Sottrai un giorno dal timestamp e ripeti l'hash.
  - Siamo d'accordo ora?
  - SÌ? Restituisce VERO
  - Aggiungi un giorno al timestamp e ripeti l'hash
  - Siamo d'accordo ora?
  - SÌ? Restituisce VERO
- A questo punto, siamo fuori dall'intervallo di data e ora senza corrispondenza. Restituisci FALSO. (Uccidi app)

Ora, la bontà sa che ci sono un milione e un modo in cui questo può fallire. Prendi in considerazione tutti i modi possibili e costruisci un sistema affidabile (incluso uno che presume che il client sia giusto se il file della lista nera non può essere scaricato). Provalo, testalo, testalo e poi testalo ancora prima di implementarlo, perché se va storto perderai la fiducia del tuo cliente.

— Kerri Shotts
fonte

+1 Per una risposta epicamente complicata O_o. Potrei sbagliarmi, ma non credo che debba essere così complicato. Non sto distribuendo Microsoft Office, questa è un'applicazione personalizzata per un singolo client. Gli stessi problemi rimangono ancora qui che il server che ospita questa applicazione potrebbe non essere in grado di comunicare con un servizio esterno. Non capisco perché crittografia, hash e sali siano davvero necessari qui. Ciò che vogliamo veramente è effettivamente un kill switch.

— maple_shaft

Grazie ;-) Il motivo per cui suggerisco di usare un hash è che nessuno che sta annusando il traffico e / o guardando codice / tabelle / file sul tuo client può dire cosa sta succedendo nel mondo. Gli hash non significano nulla senza che entrambe le parti siano coinvolte, ed è improbabile che il client comprenda che l'hash sia in realtà una rappresentazione della loro chiave di licenza. (Se fosse trasmesso in chiaro, lo saprebbero subito.) Allo stesso modo riduce la necessità di fare qualsiasi crittografia o SSL sul file della tua lista nera - gli hash da soli significano zip.

— Kerri Shotts,

Nota a margine: se ritieni che il client possa percepire che un ripristino di determinate tabelle / file è troppo difficile, puoi ridurre un po 'la complessità rimuovendo il segno di spunta ogni volta che l'app viene eseguita. Detto questo, a qualcuno non ci vorrebbe troppo tempo per capire cosa sta succedendo e aggirarlo.

— Kerri Shotts,

1

CheckBlacklist: e license-server.example.com: no route to hostadesso? Il server delle licenze potrebbe anche non esistere in futuro - e non dirmi che la tua azienda sarà ancora in vita tra vent'anni, il che è piuttosto statisticamente improbabile.

— Piskvor lasciò l'edificio l'

1

Esistono molti modi per aggirare questo problema, incluso il non utilizzo dei propri server. Usa Amazon o Google o qualcosa del genere. In alternativa, crea "trust" per il controllo in modo che se l'host è morto gli utenti possano continuare a utilizzare l'app. Come ho detto nel post, ci sono milioni di modi in cui può fallire ed è davvero il motivo per cui sono contrario a questo tipo di controllo. Preferirei fidarmi dei miei clienti piuttosto che inventare questo tipo di controllo. (Una chiave di licenza da sola, proverò. Ma inserirla nella blacklist? Non vale la pena, IMO.)

— Kerri Shotts,

4

Le altre risposte hanno già fatto un buon lavoro nel coprire il lato tecnico. Ma ti preghiamo di considerare anche il lato legale.

Hai persino il diritto di bloccare la loro app se non pagano? Se non lo hai menzionato in anticipo nel contratto, potresti non avere il diritto di farlo, anche se i pagamenti scadono (come se non avessi necessariamente il diritto di rientrare in possesso di qualcosa che hai venduto). Inoltre, molti paesi hanno leggi speciali che vietano la "manipolazione di programmi per computer" - ciò che fai potrebbe essere considerato come tale e potrebbe persino esporti a responsabilità penale.

Quindi consiglierei di discuterne prima con un avvocato, per evitare di immergerti nell'acqua calda.

Alla fine, potrebbe essere meglio fare affidamento solo sul sistema legale. Se non pagano, negoziano e se ciò non aiuta, fai causa. In molti paesi, fare causa è relativamente indolore ed economico se la situazione del contratto è chiara (in Germania, ad esempio, è possibile ottenere un Mahnbescheid per meno di 20 €).

— sleske
fonte

Questo tipo di legami nel rispondere alla mia domanda se siamo pazzi. Ho avuto la netta impressione però di non avere scelta e questo è qualcosa su cui i miei superiori insistono anche se non è nel contratto. Sfortunatamente vivo e lavoro negli Stati Uniti, dove non puoi assumere una grande azienda anche se hai ragione. Hanno eserciti di avvocati che seppelliranno tutto nelle scartoffie abbastanza a lungo da farci fallire se volessero davvero.

— maple_shaft

Sono d'accordo con @sleske sull'uso dei canali legali. Assicurati che il contratto sia valido, quindi fai causa in caso di violazione dei termini. O almeno minacciare di fare causa. In quello che ho visto delle grandi aziende, sono molto disposti a pagare i venditori per evitare di essere citati in giudizio o di violare un contratto.

— RationalGeek,

@maple_shaft: nessuna idea della situazione legale negli Stati Uniti, ma spero che la situazione legale non sia così disperata come la dipingi. Ad ogni modo, se ti venisse detto di implementare questo, vorrei solo sottolineare i potenziali problemi. Se ottieni ancora il via libera (per iscritto, ovviamente) hai fatto tutto il possibile.

— sleske,

Non ci sarebbero problemi ad avere un sistema di licenze limitato nel tempo in cui una volta scaduta la licenza l'app è inutile. Molte aziende lo fanno, grandi e piccole - Adobe per un esempio.

— James Snell,

2

Se ospitano internamente, in cosa differisce da qualsiasi altro software che potresti spedire? Scopri cosa faresti se spedissi, per esempio, un'applicazione di visualizzazione dell'inventario desktop e farlo.

— David Thornley
fonte

Immagino di essere solo confuso su cosa fare in generale. Immagino che l'applicazione dovrebbe effettuare un controllo notturno rispetto alla sua chiave di licenza inviando una richiesta a un server Web esterno con il numero di licenza. La risposta avrà esito positivo o negativo e verrà archiviata in una variabile a livello di contesto dell'applicazione. L'applicazione si "spegne" essenzialmente se la chiave di licenza non è valida. In questo modo possiamo semplicemente "invalidare" questo numero di licenza, se necessario.

— maple_shaft

Ritieni che questa semplice pagina di autenticazione delle licenze debba essere crittografata con SSL? Anche se qualcuno dovesse implementare uno sniffer di pacchetti e potesse ricavare un numero di licenza valido, avrebbe bisogno di avere una copia distribuita dell'applicazione perché sia utile, e anche in questo caso è stata costruita appositamente. Non riesco a immaginare che sia utile a nessuno diverso dal mio cliente diretto.

— maple_shaft

1

Dipende dal sistema. Hai ampliato un framework esistente come Magneto o hai scritto un'intera applicazione da zero? In caso affermativo, la creazione di un requisito di licenza non è troppo difficile. Devi semplicemente consegnare la domanda con una licenza a breve termine, che scade 45 giorni dopo la fatturazione e poi ne consegni una permanente in seguito.

Questo presuppone che anche tu non stia girando la fonte. :)

— Christopher Bibbs
fonte

Non stiamo girando la fonte. Controlleremo il codice sorgente e distribuiremo rilasci regolari e correzioni di bug quando necessario.

— maple_shaft

1

@maple_shaft: beh, c'è sempre la possibilità di rifiutare di emettere qualsiasi correzione o aggiornamento fino a quando la fattura non è stata pagata, poiché sospetto che la manutenzione sia integrata nell'acquisto iniziale o venduta come una cosa in corso, con date di pagamento regolari ( di solito, ma non sempre, annuale).

— Vatine,

Per dare seguito a @Vatine, Per i progetti precedenti che non disponevano di licenze forti, abbiamo utilizzato i difetti come punto di leva per estrarre i pagamenti. Alcuni dei difetti potrebbero non essere stati incidenti completi.

— Christopher Bibbs,

@maple_shaft - Se hai un solo client. La soluzione è semplice Non fornire aggiornamenti a detto programma a meno che il loro saldo non sia $ 0.

— Ramhound,

1

Dato che il sistema è ospitato internamente, molte delle soluzioni sopra menzionate che prevedono la comunicazione con un server remoto potrebbero non funzionare.

Perché non includere invece un file di licenza all'interno del progetto che includa una data di scadenza. Quando l'orologio di sistema supera la data di scadenza, il sistema smette di funzionare. Per proteggere il file, crittografare il contenuto per evitare manomissioni. Quando l'utente paga o rinnova per un anno in più, gli invii un nuovo file di licenza.

Nota che se stai usando PHP, il codice è prontamente disponibile per la modifica da parte dell'utente, quindi indipendentemente dal tipo di sicurezza messo in atto, l'utente può facilmente accedere e rimuoverlo. Se si utilizza ASP.NET o un altro linguaggio compilato, ciò non costituisce un problema in quanto il codice non può essere modificato.

— Gavin Coates
fonte

Questo è un buon suggerimento, ma è un'applicazione Java impacchettata e distribuita. Dare loro un nuovo file di licenza significa fidarsi di loro per inserirlo correttamente nel file WAR o dare loro un file WAR completamente nuovo che sarebbe fastidioso per tutti. Hanno montagne di scartoffie e diverse persone IT che devono giustificare la propria esistenza all'interno della propria organizzazione partecipando ogni volta che è disponibile una nuova versione di un'applicazione di terze parti. Non sto minimizzando il tuo suggerimento solo che potrebbe essere il suggerimento meno offensivo.

— maple_shaft

Suppongo che anche con la maggior parte dei linguaggi compilati come java un vaso possa essere facilmente compilato, aggiornato, ricompilato e quindi incluso nella guerra, quindi come si fa a gestirlo?

— Sudarshan,

1

(Informativa - Lavoro per Agilis Software, un fornitore di sistemi di gestione delle licenze ).

La soluzione più efficace è utilizzare l' attivazione automatica del prodotto con un contratto di licenza. Questo ti consente di:

Attiva automaticamente le licenze del cliente. Al momento dell'attivazione, ogni istanza viene automaticamente bloccata sui parametri scelti del sistema di destinazione e i limiti di licenza impostati per essi verranno applicati all'applicazione (ad es. Configurazione delle funzionalità, impostazione di un periodo di prova generale o limite di abbonamento).
Impostare un 'intervallo di leasing', che è il periodo di validità massima di ogni evento di attivazione. Per i clienti con credito sospetto è possibile impostare questo valore, ad esempio due settimane, il che significa che ogni due settimane l'app verrà automaticamente "telefonata a casa" in background per riconvalidare la licenza. Se sono in ritardo con il pagamento, puoi disabilitare la loro licenza nel server ospitato e smetterà di funzionare sul telefono di casa successivo.
Se non esiste una connessione di rete dal sistema di destinazione, esiste un processo di attivazione self-service dell'utente tramite lo scambio di file crittografati in qualsiasi terminale Web. Se il tuo utente si trova in questa posizione, potresti voler prolungare l'intervallo di leasing per compensare l'inconveniente con la tua necessità di essere pagato. Una volta pagato, puoi prolungare l'intervallo di leasing fino a quando lo desideri.

— Dominic
fonte