Solução de chave de licença em aplicativo da web, qual é a melhor abordagem?

14

Estou perplexo com uma solicitação do meu gerente. Eu trabalho para uma pequena startup e desenvolvemos um aplicativo da Web por uma taxa fixa com um contrato de manutenção para uma empresa MUITO maior. Conhecendo histórias de horror sobre como as grandes empresas pagam suas contas apenas no último segundo, decidimos que gostaríamos de nos proteger, licenciando esse aplicativo da Web de uma maneira que, se não recebermos o pagamento, o software não funcionará mais.

Já vi isso antes em aplicativos de desktop, mas será um aplicativo da Web que eles hospedarão internamente e não poderão ser acessados pela Internet.

Qual é a melhor abordagem para fazer isso, gostaríamos que ela tivesse uma pequena área ocupada e gostaríamos da capacidade de renovar a chave de licença que eles distribuíram.

Alguém fez algo semelhante? Estamos completamente fora de nossas mentes? Alguém tem alguma sugestão melhor?

web-development licensing web-applications

— maple_shaft
fonte

Para fazer isso corretamente, você precisará de muito tempo (ou eles simplesmente o quebrarão). É muito mais barato comprar um produto projetado para proteger programas java. Caso contrário, basta transformar a licença em um trecho de código de byte java que o programa lê e, em seguida, age de forma incorreta.

Era disso que eu tinha medo. Analisarei soluções de terceiros, mas já estamos com um orçamento excessivamente doloroso.

— Maple_shaft

Depois, faça-o ir devagar 2 semanas após o vencimento do pagamento.

@ Thorbjørn, LOL !! Por mais tentador que isso seja, este projeto é um líder em perdas para tentar reunir negócios adicionais com esta empresa. A MAIS ALTA QUALIDADE é da MAIOR importância. Ao mesmo tempo, não queremos nos ferrar completamente enquanto procuramos o pote de mel.

— maple_shaft

@ maple, parece um plano de negócios ruim. Em seguida, deixe o dinheiro coletando para os contadores e não considere entregar malware.

9

Existem várias maneiras de implementar algo assim, mas aqui está uma que não deve ser muito difícil de fazer:

Você precisa de um site disponível ao público em algum lugar que hospede um arquivo contendo os hashes das chaves de licença que foram incluídas na lista negra. A decisão de como você gerencia esse arquivo é sua, mas o arquivo em si só precisa ter um hash por linha.

Então, de forma recorrente, seu software inicia o download desse arquivo (a maioria dos idiomas do servidor fornece isso) e, em seguida, procura o hash da chave de licença instalada. Se for encontrado, o aplicativo sabe que deve morrer até que a lista negra seja removida.

MD5 ou similar mais um segredo deve ser suficiente para isso. Você pode ficar mais sofisticado e pedir ao aplicativo que envie a solicitação para o seu site e procure-a em um banco de dados em tempo real, mas o arquivo (pelo que eu suponho que seja uma lista curta) permanecerá pequeno e pode ser o jeito mais fácil.

A parte mais difícil é manter o aplicativo morto. Afinal, você precisa armazená-lo em algum lugar internamente, o que significa que, se for óbvio demais, pode ser facilmente subvertido e, mesmo que não seja óbvio demais, pode ser revertido facilmente restaurando a (s) tabela (s) apropriada (s) / arquivos). Portanto, sugiro um segundo método de proteção também.

Esse método armazenaria "LIVE" ou "MORTO" (ou algo suficientemente semelhante) em uma tabela ou arquivo, mas novamente HASHed. Isso precisa ser feito com seu sal E com um carimbo de data e hora. Sempre que uma página em seu aplicativo for executada, verifique esse valor com uma versão em hash de "LIVE" + salt + timestamp e permita um intervalo válido de timestamps (por exemplo, um dia, dois dias, uma semana, um mês etc.) Lembre-se de que quanto maior o alcance, mais difícil será o desempenho.). Desde que as coisas correspondam (ou uma correspondência seja encontrada), o aplicativo estará ativo; caso contrário, mesmo que o valor no arquivo ou tabela especial seja "LIVE", ele ainda estará inativo se houver uma tentativa de restauração do backup, pois o registro de data e hora ficará fora do seu limite.

Em resumo (isso pressupõe que você tenha algum método programático de verificar a validade de uma chave de licença, como algum tipo de soma de verificação ou outro método):

Lista negra
- Converter chave de licença em hash com salt
- Solicitar arquivo da lista negra do servidor
- Meu hash está no arquivo?
- Se SIM, armazene o hash de "MORTO" + sal + carimbo de data / hora (truncado para o dia; não há necessidade de armazenar horas + dias + minutos)
- Se NÃO, armazene o hash de "LIVE" + salt + timestamp (truncado)
IsKeyAlive
- Criar hash a partir de "LIVE" + salt + carimbo de data / hora truncado
- Carregar hash DeadAlive
- Eles concordam?
- Se SIM, então estamos vivos; retornar VERDADEIRO.
- Se NÃO, estamos possivelmente mortos, mas ainda podemos estar dentro da nossa janela de carimbo de data / hora:
  - Subtraia um dia do registro de data e hora e repita o hash.
  - Nós concordamos agora?
  - SIM? Return TRUE
  - Adicione um dia ao registro de data e hora e repita o hash
  - Nós concordamos agora?
  - SIM? Return TRUE
- Neste ponto, estamos fora do intervalo de data e hora sem correspondência. Retorna falso. (Matar app)

Agora, Deus sabe que há um milhão e uma das maneiras pelas quais isso pode falhar. Considere todas as formas possíveis e crie um sistema confiável (incluindo um que pressupõe que o cliente esteja certo se o arquivo da lista negra não puder ser baixado). Teste, teste, teste e, em seguida, teste um pouco mais antes da implantação, porque se der errado, você perderá a confiança do seu cliente.

— Kerri Shotts
fonte

+1 Para uma resposta epicamente complicada O_o. Posso estar errado, mas não acho que isso seja tão complicado. Não estou distribuindo o Microsoft Office, esse é um aplicativo personalizado para um único cliente. Os mesmos problemas ainda permanecem aqui, pois o servidor que hospeda esse aplicativo pode não conseguir se comunicar com um serviço externo. Não entendo por que criptografia, hashes e sais são realmente necessários aqui. O que realmente queremos é efetivamente uma opção de matar.

— Maple_shaft

Obrigado ;-) A razão pela qual sugiro usar um hash é para que ninguém que cheire o tráfego e / ou veja códigos / tabelas / arquivos no seu cliente possa dizer o que está acontecendo no mundo. Hashes não significam nada sem que ambos os lados estejam envolvidos, e é improvável que o cliente entenda que o hash é realmente uma representação de sua chave de licença. (Se fosse transmitido de forma clara, eles saberiam imediatamente.) Da mesma forma, reduz a necessidade de fazer qualquer criptografia ou SSL no seu arquivo da lista negra - os hashes por si só significam zip.

— precisa

Nota lateral: se você acredita que o cliente perceberá que uma restauração de determinadas tabelas / arquivos é muito difícil, poderá reduzir um pouco a complexidade removendo a verificação sempre que o aplicativo for executado. Dito isto, não demoraria muito tempo para alguém descobrir o que estava acontecendo e descobrir uma maneira de contornar isso.

— precisa

1

CheckBlacklist: E license-server.example.com: no route to hostagora? O servidor de licenças não pode mesmo existir em algum momento no futuro - e não me diga que a sua empresa vai ainda estar vivo em vinte anos, ou seja, em vez estatisticamente improvável.

— Piskvor saiu do prédio

1

Há muitas maneiras de contornar isso, incluindo a não utilização de seus próprios servidores. Use Amazon ou Google ou algo assim. Como alternativa, crie "confiança" na verificação para que, se o host estiver morto, os usuários possam continuar usando o aplicativo. Como mencionei no post, existem milhões de maneiras pelas quais isso pode falhar, e é por isso que sou contra esse tipo de verificação. Prefiro confiar nos meus clientes a inventar esse tipo de cheque. (A chave de licença por conta própria, eu vou para Mas na lista negra não vale o esforço, IMO.?.)

— Kerri Shotts

4

As outras respostas já fizeram um bom trabalho ao cobrir o lado técnico. Mas, por favor, considere também o lado legal.

Você tem o direito de bloquear o aplicativo deles se eles não pagarem? Se você não mencionou isso de antemão no contrato, pode não ter o direito de fazê-lo, mesmo se os pagamentos expirarem (como se você não tivesse necessariamente o direito de retomar algo que vendeu). Além disso, muitos países têm leis especiais que proíbem a "manipulação de programas de computador" - o que você faz pode ser considerado como tal e pode até expô-lo à responsabilidade criminal.

Então, eu aconselho a discutir isso com um advogado primeiro, para evitar entrar na água quente.

No final, pode ser melhor confiar apenas no sistema legal. Se eles não pagarem, negociam e, se isso não ajudar, basta processar. Em muitos países, processar é relativamente fácil e barato se a situação do contrato for clara (na Alemanha, por exemplo, você pode obter um Mahnbescheid por menos de 20 €).

— sleske
fonte

Esse tipo de ligação leva a responder à minha pergunta sobre se somos loucos. Tive a nítida impressão de que não tenho escolha e isso é algo em que meus superiores insistem, mesmo que não esteja no contrato. Infelizmente, moro e trabalho nos EUA, onde você não pode assumir uma grande corporação, mesmo que esteja certo. Eles têm exércitos de advogados que enterram tudo na papelada por tempo suficiente para nos colocar fora dos negócios, se eles realmente quisessem.

— maple_shaft

Concordo com a @sleske no uso de canais legais. Verifique se o contrato está correto e processe-os se violarem os termos. Ou pelo menos ameaçam processar. No que vi de grandes empresas, elas estão muito dispostas a pagar aos fornecedores para evitar serem processados ou violarem um contrato.

— RationalGeek

@ maple_shaft: Não faço ideia da situação legal nos EUA, mas espero que a situação legal não seja tão desesperadora quanto você a pinta. De qualquer forma, se você fosse instruído a implementar isso, eu apenas apontaria os possíveis problemas. Se você ainda obtém a aprovação (por escrito, é claro), já fez tudo o que pode.

— sleske

Não haveria nenhum problema em ter um sistema de licenciamento por tempo limitado, quando a licença expirar, o aplicativo será inútil. Muitas empresas fazem isso, grandes e pequenas - a Adobe, por exemplo.

— James Snell

2

Se eles estão hospedando internamente, como isso é diferente de qualquer outro software que você possa enviá-los? Descubra o que você faria se estivesse enviando, por exemplo, um aplicativo de exibição de inventário de desktop, e faça isso.

— David Thornley
fonte

Acho que estou confuso sobre o que fazer em geral. Eu imagino que o aplicativo faça uma verificação noturna em relação à sua chave de licença enviando uma solicitação para um servidor da web externo com o número da licença. A resposta será um sucesso ou falha e será armazenada em uma variável no nível de contexto do aplicativo. O aplicativo "desativará" essencialmente se a chave de licença não for válida. Dessa forma, podemos simplesmente "invalidar" esse número de licença, se necessário.

— Maple_shaft

Você acha que esta página simples de autenticação de licenças deve ser criptografada em SSL? Mesmo que alguém implementasse um farejador de pacotes e pudesse obter um número de licença válido, eles precisariam ter uma cópia distribuída do aplicativo para que ele fosse útil e, mesmo assim, ele foi criado com uma finalidade específica. Não consigo imaginar que isso seja útil para alguém que não seja meu cliente direto.

— maple_shaft

1

Depende do sistema. Você estendeu uma estrutura existente como o Magneto ou escreveu um aplicativo inteiro do zero? Se for mais tarde, a construção de um requisito de licenciamento não é muito difícil. Você acabou de entregar o aplicativo com uma licença de curto prazo, uma que expira 45 dias após a cobrança e depois concede uma permanente mais tarde.

Isso pressupõe que você não está entregando a fonte também. :)

— Christopher Bibbs
fonte

Não estamos entregando a fonte. Controlaremos o código fonte e distribuiremos versões regulares e correções de bugs quando necessário.

— Maple_shaft

1

@ maple_shaft: bem, sempre há a possibilidade de se recusar a emitir qualquer correção ou atualização até que a fatura seja paga, pois suspeito que a manutenção seja incorporada à compra inicial ou vendida como uma coisa contínua, com datas de pagamento regulares ( geralmente, mas nem sempre, anual).

— Vatine

Para acompanhar o @Vatine, em projetos anteriores que não possuíam um licenciamento forte, usamos os defeitos como um ponto de alavancagem para extrair o pagamento. Alguns dos defeitos podem não ter sido acidentes completos.

— Christopher Bibbs

@ maple_shaft - se você tiver apenas um cliente. A solução é simples. Não forneça atualizações para o referido programa, a menos que o saldo seja de US $ 0.

— Ramhound 19/07/11

1

Como o sistema é hospedado internamente, muitas das soluções mencionadas acima que envolvem a comunicação com um servidor remoto podem não funcionar.

Por que não incluir um arquivo de licença no projeto que inclua uma data de validade. Quando o relógio do sistema excede o prazo de validade, o sistema deixa de funcionar. Para proteger o arquivo, criptografe o conteúdo para evitar violações. Quando o usuário paga ou renova por um ano extra, você envia um novo arquivo de licença.

Observe que, se você estiver usando PHP, o código estará prontamente disponível para a edição do usuário; portanto, independentemente do tipo de segurança que você colocar, o usuário poderá facilmente removê-lo. Se você estiver usando o ASP.NET ou alguma outra linguagem compilada, isso não é uma preocupação, pois o código não pode ser modificado.

— Gavin Coates
fonte

Essa é uma boa sugestão, mas é um aplicativo Java empacotado e implementado. Dar a eles um novo arquivo de licença significa confiar neles para inseri-lo corretamente no arquivo WAR ou fornecer a eles um arquivo WAR totalmente novo que seria irritante para todos. Eles têm muitos papéis e várias pessoas de TI que precisam justificar sua existência em sua organização, envolvendo-se sempre que houver uma nova versão de um aplicativo de terceiros. Não estou subestimando sua sugestão, apenas para que seja a sugestão menos ofensiva.

— Maple_shaft

Acho que mesmo com a maioria das linguagens compiladas, como java, um jar pode ser facilmente compilado, atualizado, recompilado e incluído na guerra, então como lidar com isso?

— Sudarshan 26/03

1

(Divulgação - trabalho para a Agilis Software, um fornecedor de sistemas gerenciadores de licenças ).

A solução mais eficaz é usar a ativação automatizada do produto com uma concessão de licença. Fora da caixa, isso permite que você:

Ative automaticamente a (s) licença (s) do cliente. No momento da ativação, cada instância é bloqueada automaticamente para os parâmetros escolhidos para o sistema de destino, e os limites de licença que você configurou para eles serão aplicados ao seu aplicativo (por exemplo, configurando recursos, definindo um período geral de avaliação ou assinatura).
Defina um 'intervalo de concessão', que é o período máximo de validade de qualquer evento de ativação. Para clientes com crédito suspeito, você pode definir isso como, digamos, duas semanas, o que significa que, a cada duas semanas, seu aplicativo será automaticamente 'telefonado para casa' em segundo plano para revalidar a licença. Se eles estão atrasados no pagamento, você pode desativar a licença deles no servidor hospedado e ele deixará de ser executado na próxima casa telefônica.
Se não houver uma conexão de rede do sistema de destino, haverá um processo de ativação de autoatendimento do usuário por meio da troca de arquivos criptografados em qualquer terminal da Web. Se o usuário estiver nessa posição, convém aumentar o intervalo de concessão para equilibrar o inconveniente para ele com a sua necessidade de receber o pagamento. Uma vez que eles pagam, você pode fazer o intervalo de concessão pelo tempo que desejar, até o perpétuo.

— Dominic
fonte