Решение с лицензионным ключом в веб-приложении, какой подход лучше?

14

Я озадачен просьбой моего менеджера. Я работаю в небольшом стартапе, и мы разработали веб-приложение по фиксированной ставке с соглашением об обслуживании для НАМНОГО более крупной компании. Зная ужасные истории о том, как крупные компании будут оплачивать свои счета только в последнюю секунду, мы решили, что хотели бы защитить себя, имея возможность лицензировать это веб-приложение таким образом, чтобы, если нам не платят, программное обеспечение больше не работает.

Я видел, как это было сделано ранее для настольных приложений, однако это будет веб-приложение, которое будет размещаться внутри и не будет доступно из Интернета.

Каков наилучший подход для этого, мы бы хотели, чтобы он занимал небольшую площадь, и хотели бы иметь возможность продлевать распространенный ими лицензионный ключ.

Кто-нибудь делал что-то подобное? Мы полностью сошли с ума? У кого-нибудь есть лучшие предложения?

web-development licensing web-applications

— maple_shaft
источник

Для того, чтобы сделать это правильно , вы будете нуждаться в МНОГО времени (или они просто разорвать его). Это намного дешевле, просто купив продукт, который предназначен для защиты Java-программ. В противном случае просто сделайте лицензию фрагментом кода Java-байта, который программа читает и затем выполняет.

Вот чего я боялся, я посмотрю на сторонние решения, но мы уже мучительно перегружены.

— maple_shaft

Тогда просто сделайте это мучительно медленно через 2 недели после оплаты.

@ Thorbjørn, LOL !! ^ _ ^ Как бы заманчиво это ни было, этот проект - лидер потерь, чтобы попытаться наладить дополнительные дела с этой компанией. ВЫСОКОЕ КАЧЕСТВО имеет НАИБОЛЕЕ значение. В то же время мы не хотим быть полностью облажанными, пока мы ищем горшок с медом.

— maple_shaft

@ maple, звучит как плохой бизнес-план. Тогда оставьте сбор денег бухгалтерам и не рассматривайте возможность доставки вредоносного ПО.

9

Есть много способов реализовать что-то подобное, но вот тот, который не должен быть слишком сложным:

Вам нужен общедоступный веб-сайт, где размещен файл, содержащий хэши лицензионных ключей, которые были в черном списке. Как вы управляете этим файлом, зависит только от вас, но сам файл должен иметь только хэш в каждой строке.

Затем, периодически, ваше программное обеспечение инициирует загрузку этого файла (большинство языков на стороне сервера обеспечивают это), а затем ищет в нем хэш установленного лицензионного ключа. Если он найден, то приложение знает, что оно должно умереть, пока черный список не будет удален.

MD5 или аналогичный плюс секрет должен быть достаточным для этого. Вы можете стать более привлекательным, если бы приложение отправляло запрос на ваш сайт, и вы могли бы найти его в базе данных на лету, но файл (который, я предполагаю, будет коротким списком), надеюсь, останется небольшим и может быть самый простой способ.

Сложнее будет сохранить приложение мертвым. В конце концов, вы должны хранить это где-то внутри, что означает, что если оно слишком очевидно, его можно легко подорвать, и даже если оно не слишком очевидно, его можно легко отменить, восстановив соответствующую таблицу (таблицы) / файл (ы). Поэтому я предлагаю и второй способ защиты.

Этот метод будет хранить «LIVE» или «DEAD» (или что-то достаточно похожее) в таблице или файле, но снова HASHed. Это должно быть хешировано с вашей солью и отметкой времени. Каждый раз, когда страница вашего приложения запускается, проверяйте это значение с помощью хэшированной версии «LIVE» + соль + временная метка, а затем разрешите допустимый диапазон временных отметок (например, один день, два дня, одна неделя, один месяц и т. Д.). Имейте в виду, что чем больше диапазон, тем тяжелее будет результативность.). Пока все совпадает (или найдено совпадение), приложение остается живым; в противном случае, даже если значение в специальном файле или таблице равно «LIVE», оно все равно будет мертвым, если будет предпринята попытка восстановления из резервной копии, поскольку отметка времени выйдет за пределы вашего порогового значения.

В итоге (это предполагает, что у вас есть какой-то программный метод проверки действительности лицензионного ключа, такой как какая-то контрольная сумма или другой метод):

CheckBlacklist
- Преобразовать лицензионный ключ в хеш с солью
- Запросить файл черного списка с сервера
- Мой хеш в файле?
- Если ДА, то сохраните хэш "DEAD" + соль + метка времени (усеченный до дня; нет необходимости хранить часы + дни + минуты)
- Если НЕТ, то сохраните хеш "LIVE" + соль + метка времени (trunc'd)
IsKeyAlive
- Создать хеш из "LIVE" + соль + trunc'd отметка времени
- Загрузить DeadAlive хеш
- Они согласны?
- Если ДА, то мы живы; вернуть ИСТИНА.
- Если НЕТ, то мы, возможно, мертвы, но мы все еще можем находиться в нашем окне отметки времени:
  - Вычтите день из отметки времени и повторите хэш.
  - Согласны ли мы сейчас?
  - ДА? Возврат ИСТИНА
  - Добавьте день к метке времени и повторите хэш
  - Согласны ли мы сейчас?
  - ДА? Возврат ИСТИНА
- На данный момент мы вышли за пределы диапазона меток времени без совпадений. Вернуть ЛОЖЬ. (Убить приложение)

Теперь, боже мой, есть миллион и один способ, которым это может потерпеть неудачу. Рассмотрите все возможные способы и создайте надежную систему (включая ту, которая предполагает, что клиент прав, если файл черного списка не может быть загружен). Протестируйте, протестируйте, протестируйте его, а затем протестируйте еще несколько перед развертыванием, потому что, если это пойдет не так, вы потеряете доверие своего клиента.

— Керри Шоттс
источник

+1 За эпически сложный ответ О_о. Я могу ошибаться, но я не думаю, что это должно быть достаточно сложно. Я не распространяю Microsoft Office, это специально созданное приложение для одного клиента. Здесь остаются те же проблемы, что сервер, на котором размещено это приложение, может не поддерживать связь с внешней службой. Я не понимаю, почему шифрование, хэши и соли действительно необходимы здесь. Что мы действительно хотим, так это эффективный переключатель убийств.

— maple_shaft

Спасибо ;-) Причина, по которой я предлагаю использовать хеш, заключается в том, что никто, кто отслеживает трафик и / или просматривает код / таблицы / файлы на вашем клиенте, не может сказать, что происходит в мире. Хэши ничего не значат без участия обеих сторон, и клиент вряд ли поймет, что хеш - это фактически представление их лицензионного ключа. (Если бы оно было передано в открытом виде, они сразу бы об этом узнали.) Точно так же это уменьшает необходимость использовать любое шифрование или SSL для вашего файла черного списка - хэши сами по себе означают zip.

— Керри Шоттс

Примечание: если вы уверены, что клиент сочтет, что восстановление определенных таблиц / файлов является слишком сложным, вы можете значительно уменьшить сложность, снимая проверку при каждом запуске приложения. Тем не менее, это не займет у кого-то слишком много времени, чтобы понять, что происходит, и найти способ обойти это.

— Керри Шоттс

1

CheckBlacklist: license-server.example.com: no route to hostчто теперь? Сервер лицензий может даже не существовать когда-нибудь в будущем - и не говорите мне, что ваша компания будет еще жива через двадцать лет, что статистически невероятно.

— Писквор покинул здание

1

Есть много способов обойти это, в том числе не используя свои собственные серверы. Используйте Amazon или Google или что-то в этом роде. В качестве альтернативы, установите «доверие» к проверке, чтобы, если хост не работает, пользователи могли продолжать использовать приложение. Как я упоминал в посте, есть миллион способов, которыми он может потерпеть неудачу, и именно поэтому я против такого рода проверки. Я предпочел бы доверять своим клиентам, чем придумывать такие проверки. (Лицензионный ключ сам по себе, я пойду. Но занесение в черный список? Не стоит усилий, ИМО.)

— Kerri Shotts

4

Другие ответы уже сделали хорошую работу по освещению технической стороны. Но, пожалуйста, также рассмотрите юридическую сторону.

Есть ли у вас право заблокировать их приложение, если они не платят? Если вы не упомянули об этом заранее в договоре, вы можете не иметь права сделать это, даже если платежи истекут (например, вы не обязательно имеете право забрать то, что продали). Кроме того, во многих странах действуют специальные законы, запрещающие «манипулирование компьютерными программами» - то, что вы делаете, может рассматриваться как таковое и даже может привести к уголовной ответственности.

Поэтому я бы посоветовал сначала обсудить это с юристом, чтобы не попасть в горячую воду.

В конце концов, может быть, лучше просто положиться на правовую систему. Если они не платят, ведут переговоры, и если это не помогает, просто подайте в суд. Во многих странах судебный процесс является относительно безболезненным и дешевым, если ситуация с контрактом ясна (в Германии, например, вы можете получить Mahbbescheid менее чем за 20 €).

— sleske
источник

Такого рода связь с ответом на мой вопрос о том, сошли ли мы с ума. Однако у меня сложилось четкое впечатление, что у меня нет выбора, и это то, на чем настаивают мои начальники, хотя это не входит в контракт. К сожалению, я живу и работаю в США, где вы не можете взять крупную корпорацию, даже если вы правы. У них есть армии юристов, которые будут хоронить все документы достаточно долго, чтобы вывести нас из бизнеса, если они действительно захотят.

— maple_shaft

Я согласен с @sleske на использование легальных каналов. Удостоверьтесь, что договор обоснован, а затем подайте в суд на них, если они нарушают условия. Или, по крайней мере, угрожать подать в суд. В том, что я видел в крупных компаниях, они очень готовы платить поставщикам, чтобы избежать судебного преследования или нарушения контракта.

— RationalGeek

@maple_shaft: Понятия не имею о правовой ситуации в США, но я надеюсь, что юридическая ситуация не так безнадежна, как вы ее рисуете. В любом случае, если бы вам сказали это реализовать, я бы просто указал на потенциальные проблемы. Если вы все-таки получили разрешение (в письменной форме, конечно), вы сделали все, что могли.

— слеске

Не будет проблем с наличием системы лицензирования с ограниченным сроком действия, когда после истечения срока действия лицензии приложение становится бесполезным. Это делают многие компании, большие и маленькие, например, Adobe.

— Джеймс Снелл

2

Если они размещаются внутри, как это может отличаться от любого другого программного обеспечения, которое вы можете отправить? Выясните, что бы вы сделали, если бы отправляли, скажем, приложение для отображения инвентаря на рабочем столе, и сделайте это.

— Дэвид Торнли
источник

Я думаю, я просто не понимаю, что делать в целом. Я полагаю, что приложение должно выполнять ночную проверку своего лицензионного ключа, отправляя запрос на внешний веб-сервер с номером лицензии. Ответ будет успешным или неудачным и будет сохранен в переменной уровня контекста приложения. Приложение по существу «выключится», если лицензионный ключ недействителен. Таким образом, мы можем просто «аннулировать» этот номер лицензии, если это необходимо.

— maple_shaft

Считаете ли вы, что эта простая страница аутентификации лицензии должна быть зашифрована SSL? Даже если бы кто-то реализовал анализатор пакетов и мог получить действительный номер лицензии, он должен был бы иметь распределенную копию приложения, чтобы это было полезно, и даже в этом случае оно было специально разработано. Я не могу представить, чтобы это было полезно кому-либо, кроме моего прямого клиента.

— maple_shaft

1

Это зависит от системы. Вы расширили существующий фреймворк, такой как Magneto, или написали целое приложение с нуля? Если это позже, встроить требование лицензирования не слишком сложно. Вы просто доставляете приложение с краткосрочной лицензией, срок действия которой истекает через 45 дней после выставления счета, а затем выдает постоянную лицензию.

Это предполагает, что вы не переворачиваете источник. :)

— Кристофер Биббс
источник

Мы не переворачиваем источник. Мы будем контролировать исходный код и распространять регулярные выпуски и исправления ошибок при необходимости.

— maple_shaft

1

@maple_shaft: Ну, всегда есть возможность просто отказаться от выпуска каких-либо исправлений или обновлений до тех пор, пока счет не будет оплачен, так как я подозреваю, что обслуживание встроено либо в первоначальную покупку, либо продается как текущая вещь с регулярными датами оплаты ( обычно, но не всегда, ежегодно).

— Ватин

Чтобы продолжить работу над @Vatine, для предыдущих проектов, в которых отсутствовало строгое лицензирование, мы использовали дефекты в качестве рычага для получения платежей. Некоторые из дефектов, возможно, не были полными несчастными случаями.

— Кристофер Биббс

@maple_shaft - если у вас есть только один клиент. Решение простое. Не предоставляйте обновления для указанной программы, если их баланс не равен $ 0.

— Ramhound

1

Принимая во внимание, что система размещена внутри, многие из упомянутых выше решений, включающих связь с удаленным сервером, могут не работать.

Почему бы вместо этого не включить файл лицензии в проект, который включает дату истечения срока действия. Как только системные часы превышают срок действия, система перестает функционировать. Чтобы обезопасить файл, зашифруйте его содержимое, чтобы предотвратить подделку. Когда пользователь платит или продлевает его на дополнительный год, вы отправляете ему новый файл лицензии.

Обратите внимание, что если вы используете PHP, код легко доступен для редактирования пользователем, поэтому независимо от того, какую защиту вы установите, пользователь может легко войти и удалить его. Если вы используете ASP.NET или какой-либо другой скомпилированный язык, это не проблема, так как код не может быть изменен.

— Гэвин Коутс
источник

Это хорошее предложение, но это упакованное и развернутое Java-приложение. Предоставление им нового файла лицензии означает, что он может либо правильно вставить его в файл WAR, либо дать им совершенно новый файл WAR, который будет раздражать всех. У них есть куча документов и множество ИТ-специалистов, которым нужно оправдывать свое существование в своей организации, участвуя в них всякий раз, когда появляется новая версия стороннего приложения. Я не преуменьшаю ваше предположение, просто чтобы оно было наименее оскорбительным.

— maple_shaft

Я думаю, что даже с большинством скомпилированных языков, таких как java, jar можно легко декомпилировать, обновить, перекомпилировать и затем включить в войну, так как же с этим справиться?

— Сударшан

1

(Раскрытие - я работаю на Agilis Software, поставщика систем управления лицензиями ).

Наиболее эффективным решением является использование автоматической активации продукта с арендой лицензии. Из коробки это позволяет вам:

Автоматически активировать клиентские лицензии. Во время активации каждый экземпляр автоматически привязывается к выбранным вами параметрам целевой системы, и ограничения лицензии, которые вы для них устанавливаете, будут применяться в вашем приложении (например, настройка функций, установка общего пробного периода или ограничения по времени подписки).
Установите «интервал аренды», который является максимальным сроком действия любого события активации. Для клиентов с подозрительным кредитом вы можете установить это, скажем, на две недели, что означает, что каждые две недели ваше приложение будет автоматически «звонить домой» в фоновом режиме для повторной проверки лицензии. Если они просрочили платеж, вы можете отключить их лицензию на размещенном сервере, и он перестанет работать на следующем домашнем телефоне.
Если сетевое соединение с целевой системой отсутствует, происходит процесс активации пользователем самообслуживания посредством обмена зашифрованными файлами на любом веб-терминале. Если ваш пользователь находится в этом положении, вы можете увеличить интервал аренды, чтобы уравновесить неудобства для него и необходимость получать оплату. После того, как они заплатят, вы можете сделать интервал аренды столько, сколько хотите, до бесконечного.

— Dominic
источник