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

Hay muchas maneras 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 contenga un archivo que contenga los hashes de las claves de licencia que se han incluido en la lista negra. La forma de administrar este archivo depende de usted, pero el archivo en sí solo necesita tener un hash por línea.

Luego, de forma recurrente, su software inicia una descarga de este archivo (la mayoría de los idiomas del lado del servidor lo proporcionan) y luego lo busca para 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ían ser suficientes para esto. Podría ser más sofisticado y hacer que la aplicación envíe la solicitud a su sitio y la busque en una base de datos sobre la marcha, pero el archivo (para lo que supongo que sería una lista corta) se mantendrá pequeño y podría ser La forma más fácil.

La parte más difícil será mantener la aplicación muerta. Después de todo, tiene que almacenar esto en algún lugar internamente, lo que significa que si es demasiado obvio, se puede subvertir fácilmente, e incluso si no es demasiado obvio, se puede revertir fácilmente restaurando las tablas adecuadas / 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 hecho con tu 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 con hash de "LIVE" + salt + timestamp 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, mayor será el rendimiento. Mientras las cosas coincidan (o se encuentre una coincidencia), la aplicación está viva; de lo contrario, incluso si el valor en el archivo o tabla especial es "EN VIVO", aún estará muerto si se intenta restaurar desde la copia de seguridad porque la marca de tiempo quedará 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 comprobación u otro método):

• CheckBlacklist
  • Convierta la clave de licencia en hash con sal
  • Solicitar el archivo de lista negra del servidor
  • ¿Mi hash está en el archivo?
  • Si es SÍ, entonces almacene el hash de "DEAD" + sal + marca de tiempo (truncado al día; no es necesario almacenar horas + días + minutos)
  • Si NO, entonces almacene el hash de "LIVE" + salt + timestamp (trunc'd)
• IsKeyAlive
  • Crear hash desde "LIVE" + sal + marca de tiempo truncada
  • Cargar hash DeadAlive
  • ¿Están de acuerdo?
  • Si es SÍ, entonces estamos vivos; volver VERDADERO.
  • Si NO, es posible que estemos 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? Volver VERDADERO
    • Agregue un día a la marca de tiempo y repita el hash
    • ¿Estamos de acuerdo ahora?
    • SI? Volver 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 y una de las formas en que esto puede fallar. Considere todas las formas posibles y construya un sistema confiable (incluido uno que asuma que el cliente es correcto si no se puede descargar el archivo de la lista negra). Pruebe, pruebe, pruebe, y luego pruebe un poco más antes de implementar, porque si sale mal, habrá perdido la confianza de su cliente.

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

¿Incluso 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 tuviera necesariamente 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 una responsabilidad penal.

Por lo tanto, le aconsejo que lo consulte 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, negocian, y si eso no ayuda, solo demandar. En muchos países, las demandas son relativamente indoloras y amp; barato si la situación del contrato es clara (en Alemania, por ejemplo, puede obtener un Mahnbescheid por menos de 20 €).

Si se alojan internamente, ¿en qué se diferencia esto de cualquier otro software que pueda enviar? Averigüe qué haría si estuviera enviando, por ejemplo, una aplicación de visualización de inventario de escritorio, y haga eso.

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

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

Dado que el sistema está alojado internamente, muchas de las soluciones mencionadas anteriormente que involucran la comunicación con un servidor remoto pueden no funcionar.

En su lugar, ¿por qué no incluir un archivo de licencia dentro del proyecto que incluya una fecha de caducidad? 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 manipulaciones. Cuando el usuario paga o se 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 lo edite el usuario, por lo que no importa qué tipo de seguridad haya implementado, el usuario puede ingresar y eliminarlo fácilmente. Si está utilizando ASP.NET o algún otro lenguaje compilado, esto no es un problema ya que el código no se puede modificar.

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

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

• Activar automáticamente la (s) licencia (s) del cliente. En el momento de la activación, cada instancia se bloquea automáticamente a los parámetros elegidos del sistema de destino, y los límites de licencia que configuró para ellos se aplicarán en su aplicación (por ejemplo, configuración de funciones, configuración de una prueba general o límite de tiempo de suscripción).
• 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 vencidos en el pago, puede desactivar su licencia en el servidor alojado y dejará de ejecutarse en el próximo teléfono de su 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 prolongar el intervalo de arrendamiento para compensar los inconvenientes para ellos con su necesidad de recibir un pago. Una vez que pagan, puedes hacer el intervalo de arrendamiento todo el tiempo que desees, hasta perpetuo.