Solución de clave de licencia en la aplicación web, ¿cuál es el mejor enfoque?

14

Estoy perplejo por una solicitud de mi gerente. Trabajo para una pequeña startup y desarrollamos una aplicación web por una tarifa fija con un acuerdo de mantenimiento para una empresa MUCHO más grande. Al conocer historias de horror sobre cómo las grandes empresas solo pagarán sus facturas hasta el último segundo, decidimos que nos gustaría protegernos al poder licenciar esta aplicación web de una manera que, si no nos pagan, el software ya no funciona.

He visto esto antes para las aplicaciones de escritorio, sin embargo, esta será una aplicación web que alojarán internamente y no será accesible desde Internet.

¿Cuál es el mejor enfoque para hacer esto? Nos gustaría que tuviera una huella pequeña y que quisiéramos renovar la clave de licencia que han distribuido.

¿Alguien ha hecho algo similar? ¿Estamos completamente fuera de nuestras mentes? ¿Alguien tiene alguna sugerencia mejor?

web-development licensing web-applications

— árbol de arce
fuente

Para hacer esto correctamente, necesitará MUCHO tiempo (o simplemente lo romperán). Es mucho más barato comprar un producto diseñado para proteger los programas de Java. De lo contrario, simplemente convierta la licencia en un fragmento de código de bytes de Java que el programa lee y luego actúa.

Eso es lo que temía, buscaré soluciones de terceros, sin embargo, ya estamos sobre presupuestados.

— maple_shaft

Luego, hazlo ir lentamente 2 semanas después del vencimiento del pago.

@ Thorbjørn, LOL !! ^ _ ^ Tan tentador como sería este proyecto es un líder en pérdidas para tratar de conseguir negocios adicionales con esta compañía. La más alta calidad es de la mayor importancia. Al mismo tiempo, no queremos atornillarnos por completo mientras buscamos el tarro de miel.

— maple_shaft

@maple, parece un mal plan de negocios. Luego, deje el dinero recaudando a los contadores y no considere entregar malware.

9

Hay muchas formas de implementar algo como esto, pero aquí hay una que no debería ser demasiado difícil de hacer:

Necesita un sitio web disponible públicamente en algún lugar que aloje un archivo que contenga los hash de las claves de licencia que se han incluido en la lista negra. La forma en que administre este archivo depende de usted, pero el archivo en sí solo necesita tener un hash por línea.

Luego, de manera recurrente, su software inicia una descarga de este archivo (la mayoría de los idiomas del lado del servidor lo proporcionan) y luego busca el hash de la clave de licencia instalada. Si se encuentra, la aplicación sabe que debe morir hasta que se elimine la lista negra.

MD5 o similar más un secreto debería ser suficiente para esto. Podrías ponerte más elegante y hacer que la aplicación envíe la solicitud a tu sitio y lo busques en una base de datos sobre la marcha, pero el archivo (por lo que supongo sería una lista corta) con suerte seguirá siendo pequeño y puede ser la forma más fácil.

La parte más difícil será mantener la aplicación muerta. Después de todo, debe almacenar esto en algún lugar interno, lo que significa que si es demasiado obvio, podría subvertirse fácilmente, e incluso si no es demasiado obvio, puede revertirse fácilmente restaurando la (s) tabla (s) adecuada (s) / archivo (s) Por lo tanto, sugiero un segundo método de protección también.

Este método almacenaría "LIVE" o "DEAD" (o algo suficientemente similar) en una tabla o un archivo, pero nuevamente HASHed. Esto debe ser mezclado con su sal Y una marca de tiempo. Cada vez que se ejecuta una página en su aplicación, verifique este valor con una versión hash de "LIVE" + salt + marca de tiempo y luego permita un rango válido de marcas de tiempo (por ejemplo, un día, dos días, una semana, un mes, etc. Tenga en cuenta que cuanto mayor sea el rango, más difícil será el rendimiento). Mientras las cosas coincidan (o se encuentre una coincidencia), la aplicación estará activa; de lo contrario, incluso si el valor en el archivo o tabla especial es "EN VIVO", seguirá estando muerto si se intenta restaurar desde la copia de seguridad porque la marca de tiempo estará fuera de su umbral.

En resumen (esto supone que tiene algún método programático para verificar la validez de una clave de licencia, como algún tipo de suma de verificación u otro método):

CheckBlacklist
- Convertir clave de licencia a hash con sal
- Solicitar archivo de lista negra del servidor
- ¿Está mi hash en el archivo?
- En caso afirmativo, almacene el hash de "MUERTO" + sal + marca de tiempo (truncado al día; no es necesario almacenar horas + días + minutos)
- En caso negativo, almacene el hash de "LIVE" + salt + timestamp (trunc'd)
IsKeyAlive
- Crea hash desde "LIVE" + salt + marca de tiempo truncada
- Cargar hash de DeadAlive
- ¿Están de acuerdo?
- Si es así, entonces estamos vivos; volver VERDADERO.
- Si NO, entonces posiblemente estamos muertos, pero aún podemos estar dentro de nuestra ventana de marca de tiempo:
  - Resta un día de la marca de tiempo y repite el hash.
  - ¿Estamos de acuerdo ahora?
  - ¿SI? Devolver VERDADERO
  - Agregue un día a la marca de tiempo y repita el hash
  - ¿Estamos de acuerdo ahora?
  - ¿SI? Devolver VERDADERO
- En este punto, estamos fuera del rango de marca de tiempo sin coincidencia. Falso retorno. (Matar aplicación)

Ahora, Dios sabe que hay un millón de maneras en que esto puede fallar. Considere todas las formas posibles y cree un sistema confiable (incluido uno que suponga que el cliente tiene razón si el archivo de la lista negra no se puede descargar). Pruebe, pruebe, pruebe y luego pruebe un poco más antes de implementar, porque si sale mal, habrá perdido la confianza de su cliente.

— Kerri Shotts
fuente

+1 Para una respuesta épicamente complicada O_o. Puedo estar equivocado, pero no creo que esto deba ser tan complicado. No estoy distribuyendo Microsoft Office, esta es una aplicación personalizada para un solo cliente. Todavía persisten los mismos problemas que el servidor que aloja esta aplicación no puede comunicarse con un servicio externo. No entiendo por qué el cifrado, los hashes y las sales son realmente necesarios aquí. Lo que realmente queremos es efectivamente un interruptor de matar.

— maple_shaft

Gracias ;-) La razón por la que sugiero usar un hash es para que nadie que esté olfateando el tráfico y / o mirando códigos / tablas / archivos a su cliente pueda decir qué está pasando en el mundo. Los hash no significan nada sin que ambas partes estén involucrados, y es poco probable que el cliente comprenda que el hash es en realidad una representación de su clave de licencia. (Si se transmitiera de forma clara, lo sabrían de inmediato). Del mismo modo, reduce la necesidad de realizar cualquier cifrado o SSL en su archivo de lista negra: los hash en sí mismos significan zip.

— Kerri Shotts

Nota al margen: si confía en que el cliente percibirá que una restauración de ciertas tablas / archivos es demasiado difícil, puede reducir bastante la complejidad eliminando la comprobación cada vez que se ejecuta la aplicación. Dicho esto, a alguien no le tomaría mucho tiempo darse cuenta de lo que está sucediendo y resolverlo.

— Kerri Shotts

1

CheckBlacklist: license-server.example.com: no route to host¿y ahora qué? Es posible que el servidor de licencias ni siquiera exista en algún momento en el futuro, y no me diga que su empresa seguirá viva en veinte años, eso es estadísticamente improbable.

— Piskvor salió del edificio el

1

Hay muchas maneras de evitar esto, incluso no usar sus propios servidores. Usa Amazon o Google o algo así. Alternativamente, cree "confianza" en la comprobación para que, si el host está muerto, los usuarios puedan continuar utilizando la aplicación. Como mencioné en la publicación, hay un millón de formas en que puede fallar, y es realmente por eso que estoy en contra de este tipo de verificación. Prefiero confiar en mis clientes que presentar este tipo de cheque. (Una clave de licencia por sí sola, la buscaré. ¿Pero ponerla en la lista negra? No vale la pena, IMO.)

— Kerri Shotts

4

Las otras respuestas ya han hecho un buen trabajo al cubrir el aspecto técnico. Pero también tenga en cuenta el lado legal.

¿Tienes derecho a bloquear su aplicación si no pagan? Si no mencionó esto por adelantado en el contrato, es posible que no tenga derecho a hacerlo, incluso si los pagos caducan (como si no necesariamente tuviera derecho a recuperar algo que vendió). Además, muchos países tienen leyes especiales que prohíben la "manipulación de programas informáticos": lo que usted hace podría considerarse como tal e incluso podría exponerlo a responsabilidad penal.

Por lo tanto, le aconsejaría discutir esto con un abogado primero, para evitar meterse en el agua caliente.

Al final, podría ser mejor simplemente confiar en el sistema legal. Si no pagan, negocie, y si eso no ayuda, simplemente demande. En muchos países, la demanda es relativamente indolora y barata si la situación del contrato es clara (en Alemania, por ejemplo, puede obtener un Mahnbescheid por menos de 20 €).

— sleske
fuente

Este tipo de vínculos con la respuesta a mi pregunta sobre si estamos locos. Sin embargo, tuve la clara impresión de que no tengo otra opción y esto es algo en lo que mis superiores insisten aunque no esté en el contrato. Desafortunadamente, vivo y trabajo en los EE. UU., Donde no puedes enfrentarte a una gran corporación, incluso si tienes razón. Tienen ejércitos de abogados que enterrarán todo en el papeleo el tiempo suficiente para sacarnos del negocio si realmente quisieran.

— maple_shaft

Estoy de acuerdo con @sleske en el uso de canales legales. Asegúrese de que el contrato sea sólido, y luego demandelos si violan los términos. O al menos amenazar con demandar. En lo que he visto de las grandes empresas, están muy dispuestas a pagar a los proveedores para evitar ser demandados o violar un contrato.

— RationalGeek

@maple_shaft: No tengo idea de la situación legal en los EE. UU., pero espero que la situación legal no sea tan desesperada como la pintas. De todos modos, si le dijeran que implementara esto, solo señalaría los posibles problemas. Si todavía obtiene el visto bueno (por escrito, por supuesto), ha hecho todo lo posible.

— sleske

No habría ningún problema en tener un sistema de licencias por tiempo limitado en el que una vez que la licencia caduque, la aplicación será inútil. Muchas empresas lo hacen, grandes y pequeñas, por ejemplo, Adobe.

— James Snell

2

Si están alojando internamente, ¿en qué se diferencia esto de cualquier otro software que pueda enviarles? Averigua qué harías si estuvieras enviando, por ejemplo, una aplicación de visualización de inventario de escritorio, y hazlo.

— David Thornley
fuente

Supongo que estoy confundido acerca de qué hacer en general. Me imagino que la aplicación debería hacer una verificación nocturna contra su clave de licencia enviando una solicitud a un servidor web externo con el número de licencia. La respuesta será un éxito o un fracaso y se almacenará en una variable de nivel de contexto de la aplicación. La aplicación esencialmente se "apagará" si la clave de licencia no es válida. De esta manera, simplemente podemos "invalidar" este número de licencia si es necesario.

— maple_shaft

¿Crees que esta página de autenticación de licencia simple debería estar encriptada SSL? Incluso si alguien implementara un sniffer de paquetes y pudiera derivar un número de licencia válido, necesitaría tener una copia distribuida de la aplicación para que sea útil, e incluso entonces es muy útil. No puedo imaginar que sea útil para nadie más que mi cliente directo.

— maple_shaft

1

Depende del sistema. ¿Extendió un marco existente como Magneto o escribió una aplicación completa desde cero? Si es más tarde, incorporar un requisito de licencia no es demasiado difícil. Simplemente entrega la solicitud con una licencia a corto plazo, una que vence 45 días después de la facturación y luego otorga una permanente.

Esto supone que no está entregando la fuente también. :)

— Christopher Bibbs
fuente

No estamos entregando la fuente. Controlaremos el código fuente y distribuiremos versiones regulares y correcciones de errores cuando sea necesario.

— maple_shaft

1

@maple_shaft: Bueno, siempre existe la posibilidad de negarse a emitir correcciones o actualizaciones hasta que se haya pagado la factura, ya que sospecho que el mantenimiento está integrado en la compra inicial o se vende como algo continuo, con fechas de pago regulares ( generalmente, pero no siempre, anual).

— Vatine

Para hacer un seguimiento de @Vatine, para proyectos anteriores que carecían de una licencia sólida, hemos utilizado los defectos como un punto de apalancamiento para extraer el pago. Algunos de los defectos pueden no haber sido accidentes completos.

— Christopher Bibbs

@maple_shaft: si solo tiene un único cliente. La solución es simple. No proporcione actualizaciones a dicho programa a menos que su saldo sea de $ 0.

— Ramhound

1

Dado que el sistema está alojado internamente, muchas de las soluciones mencionadas anteriormente que implican comunicarse con un servidor remoto pueden no funcionar.

¿Por qué no incluir un archivo de licencia dentro del proyecto que incluya una fecha de vencimiento? Una vez que el reloj del sistema supera la fecha de caducidad, el sistema deja de funcionar. Para asegurar el archivo, cifre el contenido para evitar alteraciones. Cuando el usuario paga o renueva por un año adicional, le envía un nuevo archivo de licencia.

Tenga en cuenta que si está utilizando PHP, el código está fácilmente disponible para que el usuario lo edite, por lo que no importa qué tipo de seguridad establezca, el usuario puede entrar y eliminarlo fácilmente. Si está utilizando ASP.NET u otro lenguaje compilado, esto no es una preocupación ya que el código no puede modificarse.

— Gavin Coates
fuente

Esta es una buena sugerencia, pero es una aplicación Java empaquetada e implementada. Darles un nuevo archivo de licencia significa confiar en ellos para insertarlos correctamente en el archivo WAR o darles un archivo WAR completamente nuevo que sería molesto para todos. Tienen montañas de papeleo y múltiples personas de TI que necesitan justificar su existencia dentro de su organización al involucrarse cada vez que hay una nueva versión de una aplicación de terceros. No estoy minimizando su sugerencia solo porque podría ser la sugerencia menos ofensiva.

— maple_shaft

Supongo que incluso con la mayoría de los lenguajes compilados, como Java, un jar puede ser fácilmente compilado, actualizado, recompilado y luego incluido en la guerra, entonces, ¿cómo se maneja eso?

— Sudarshan

1

(Divulgación: trabajo para Agilis Software, un proveedor de sistemas de administración de licencias ).

La solución más efectiva es utilizar la activación automática del producto con un contrato de arrendamiento de licencia. Fuera de la caja, esto le permite:

Active automáticamente la (s) licencia (s) del cliente. En el momento de la activación, cada instancia se bloquea automáticamente en los parámetros elegidos del sistema de destino, y los límites de licencia que establezca para ellos se aplicarán en su aplicación (por ejemplo, configurar funciones, establecer un límite de tiempo de prueba o suscripción general).
Establezca un 'intervalo de arrendamiento', que es el período de validez máximo de cualquier evento de activación. Para los clientes con crédito sospechoso, puede configurar esto en, por ejemplo, dos semanas, lo que significa que cada dos semanas su aplicación automáticamente "llamará a casa" en segundo plano para revalidar la licencia. Si están atrasados en el pago, puede deshabilitar su licencia en el servidor alojado y dejará de ejecutarse en el próximo teléfono de casa.
Si no hay una conexión de red desde el sistema de destino, hay un proceso de activación de autoservicio del usuario a través del intercambio de archivos cifrados en cualquier terminal web. Si su usuario está en esta posición, es posible que desee alargar el intervalo de arrendamiento para equilibrar las molestias con su necesidad de recibir un pago. Una vez que pagan, puede realizar el intervalo de arrendamiento todo el tiempo que desee, hasta perpetuo.

— Dominic
fuente