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

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

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

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

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

Сделайте Антивирусный маршрут, выполните внешний вызов для "Обновлений". Если Вы не получаете обновления, приложение прекращает работать, если они не платят, прекратите давать им обновления.

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

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

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

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

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

Я не могу говорить с юридическими вопросами.

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

До затем повреждения любых данных после истечения, я не сделал бы этого. Я думаю, что зашифровал бы некоторые ключевые объекты в данных, которые требуют, чтобы приложение дешифровало.

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

Я реализовал бы некоторый метод в скомпилированном dll, который Вы храните в каталоге bin. Назовите его чем-то другим, чем timebomb.dll.

у Вас должен затем быть метод в этом dll, который возвращает TRUE или FALSE:

public bool hasTimeExpired() {
  //Pseudocode
  DateTime expires = new DateTime(Janurary 10, 2009);
  return ( DateTime.Now() >= expires );
}

Просто проверяют hasTimeExpired () метод на Запуске Приложения (global.ascx??) или на определенных кодовых страницах, в зависимости от того, как Вы хотите обработать сообщение истечения.

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

Кроме этого, действительно необходимо работать с Адвокатом, но иногда блокировка на части одолженного программного обеспечения как это является более эффективной и более дешевой, чем Адвокат.

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

Разговор о Ваших проблемах и разработка замораживания, при необходимости - я предполагаю, что они хотят продукт, в конце концов!

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

Как со многими другими, у меня было бы резервирование о фактической реализации этого.

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

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

я думал бы дважды прежде просто согласиться с этим на вашем месте.

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

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

Это походит на задание для адвоката.

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

Две мысли:

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

2) Мы сделали подобный этому прежде. Мы провели намного больше времени, рассматривая, как любая возможная "бомба замедленного действия" будет на 100% пуленепробиваемой так, чтобы она не могла уйти случайно или перед конечным сроком, или в некоторое время, случайно будучи "разряженным". Например, может быть лучше на самом деле удалить код, а не просто изменить флаг от "Пробной версии" до "Неограниченного использования"

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

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

На заметке на полях, 'логика бомбит', напоминает Вам Меч-рыба также?

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

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

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

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

Несколько вопросов для рассмотрения:

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

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

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

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

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

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

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

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

Хорошо вот некоторые вещи, о которых я могу думать

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

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

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

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

Для нашего использования мы только предоставляем имя клиента к регистрационному ключу calulcation алгоритм, но Вы могли бы хотеть добавить номер версии или некоторую другую дату. Регистрационный ключ затем сгенерирован путем вычисления хеша MD5 предоставленного имени, объединенного с кодом secred (некоторые случайные байты в массиве).

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

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