Необходима бомба замедленного действия в приложении ASP.NET

Question

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

[Редактировать:] Только технические ответы, пожалуйста! Является ли это хорошей (или юридической) идеей - вопрос для CEOoverflow.com ; -)

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

Мой вопрос: как и где мы должны хранить дату истечения срока действия заявки?

Некоторые моменты, на которые следует обратить внимание:

• Приложение установлено на одном сервере в офисах клиента.
• Данные приложения хранятся в базе данных SQL Server 2005 на том же сервере. База данных была разработана нами и не используется ни для чего другого.
• Приложение доступно только в их внутренней сети: нет доступа к приложению через Интернет.
• В настоящее время у нас есть удаленный доступ к рабочему столу на их сервере, но мы ожидаем, что потеряем его, если что-то пойдет не так.
• Приложение написано на .NET 2.0.
• Безопасность обрабатывается с помощью FormsAuthentication.
• Нам нужно иметь возможность отключить бомбу замедленного действия или легко изменить дату ее запуска (предположим, что для этого у нас все еще есть доступ к удаленному рабочему столу).
• Сервер обычно может получить доступ к Интернету, но было бы лучше не полагаться на это.
• Бомба замедленного действия блокирует только пользователей: она не уничтожает никакие данные.
• Если это не сработает, клиент никогда не должен знать о существовании бомбы замедленного действия.
• Их айтишник с удовольствием покопается в web.config или в базе данных. Он не программист, но он не боится что-то менять «просто чтобы посмотреть, что происходит». Декомпиляция или обратный инжиниринг приложения будут за пределами его возможностей.

За дополнительные кредиты, как вы думаете, насколько это нормально, если в этом случае можно положиться на безопасность через неизвестность?

[ Edit: ]

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

Answer 1

«Они вряд ли заплатят за это, поэтому наш босс хотел бы, чтобы мы внедрили бомбу замедленного действия».

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

Это неэтично, возможно, незаконно, но в основном это просто глупо.

Answer 2

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

Для проверки мы храним «регистрационный ключ» в файле web.config. Мы сравниваем это с ключом, который вычисляем, и алгоритм его вычисления хранится в отдельной сборке. Если ключи совпадают, мы предполагаем, что продукт лицензирован.

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

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

Answer 3

Ну вот некоторые вещи, которые я могу придумать

1. Положите логическую бомбу, которая зависит от того, входит ли кто-то из ваших людей в систему, чтобы через определенное количество дней после последнего входа в систему приложение закрылось.
2. Чтобы использовать блокировку на основе даты и сохранить дату в таблице на сервере SQL. Но зашифруйте значение, хранящееся в стандартном алгоритме, который использует соль, скрытую в вашем коде. Таким образом вы избегаете выставления даты системному администратору.
3. Используя метод, описанный выше, сохраните большое целочисленное значение, от которого вы начнете обратный отсчет, как только приложение загрузится в IIS - как только оно достигнет нуля, удалите значение в БД и заблокируйте приложение - вам придется сбросить значение, используя шифрование для его работы снова.
4. Безопасность от неясности хороша, если это приложение, но если вы хотите продать его как продукт, вам понадобится какое-то шифрование.

Ничто из этого не является надежным ...
Отказ от ответственности: я не какой-либо юридический эксперт - я ответил на это только с технической точки зрения. Лично я бы не стал этого делать, поскольку считаю, что это морально неоднозначно.

Answer 4

Если оставить в стороне этические проблемы, если вас беспокоит взлом вашей реализации серийного номера, почему бы не использовать сертификат X509? Например, если у вас установлен Windows-сервер с установленным сервером сертификатов, он может открыть список отзыва сертификатов в Интернете.

Выдайте каждому клиенту сертификат идентификации клиента (бонус, если вы предоставляете проверку обновлений центральному серверу - теперь вы можете использовать HTTPS клиент / сервер, не беспокоясь о паролях).

Если клиент не платит, отозвать сертификат. При запуске приложения просто загрузите сертификат и проверьте его действительность ...

Answer 5

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

Answer 6

Спасибо за все ваши ответы!

Мы не совсем сделали то, что предложил один человек, но использовали идеи нескольких из вас.

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

В любом случае, техническая реализация выглядит так:

Мы хотели, чтобы дата истечения срока была скрыта там, где ее нельзя было бы наткнуться, и, если бы она была замечена, была бы в форме, которую нельзя было бы легко изменить. Это также должно было быть где-то, мы могли быть уверены, что не пострадали бы непреднамеренно, даже несмотря на то, что на сервере мы не имеем такого большого контроля.

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

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

Мы рады этому решению по следующим причинам:

• Нам легко изменить дату истечения срока действия заявки.
• Нет никакой зависимости от доступности интернета или чего-либо еще кроме их сервера.
• Защита выживет при резервном копировании и восстановлении, или если приложение будет перемещено в другой ящик.

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

Answer 7

Пара моментов для рассмотрения:

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

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

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

Звучит как работа юриста.

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