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

У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

Подскажите, пожалуйста, чем это можно сделать!
Спасибо

Здравствуйте, ribentrop79, Вы писали:

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

R>У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

R>1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
R>2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
R>3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

R>Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

R>Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

R>1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
R>2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
R>3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

R>И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

R>Подскажите, пожалуйста, чем это можно сделать!
R>Спасибо

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

Здравствуйте, ribentrop79, Вы писали:

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

>[SKIPPED]

Честно говоря, идея с защитой клиентской программы от копирования — совершенно дурацкая.
Я так понял, либо злоумышленник имеет доступ к компу, на котором находится легально скачанный клиент, либо есть недобросовестные пользователи, которые сами передают клиент злоумышленнику.
Вместо защиты от копирования предлагаю сделать следующее:
1) Убрать вообще какую-либо защиту с клиента (ибо она не нужна)
2) Пустить весь протокол через SSL (лишним не будет)
3) Организовать авторизацию пользователя, логин/пароль давать только легальным клиентам (когда срок договора с клиентом закончится, его учетную запись можно заблокировать)
4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)
Насколько мне известно, как-то так сделана система оплаты связи в салонах сотовой связи.
А еще можно убрать вообще какие-либо клиенты в виде исполняемых модулей, а все реализовать через веб.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, ribentrop79, Вы писали:

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

R>>У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

R>>1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
R>>2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
R>>3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

R>>Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

R>>Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

R>>1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
R>>2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
R>>3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

R>>И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

R>>Подскажите, пожалуйста, чем это можно сделать!
R>>Спасибо

А>Я вот только чего не понимаю — нафига оно все нужно?
А>Если система клиент-сервер, то без стыренного сервера клиентский экзешник никому нафиг не нужен,
А>если софт такой суперский и выполняет кучу всего самостоятельно, да еще и все это хорошо денег стоит,
А>обратите свой взор на хардлоки (типа алладин-usb) — давайте софт в аренду с ключом, в конце концов...
Спасибо за внимание!! К сожалению, я сам еще не погрузился целиком в идею – было мало времени, а задачку поставили. Так вот, тырить сервер не обязательно вовсе! Гораздо проще оказывается скопировать клиент, поставить его у себя и как бы от имени клиента таскать прайсы. Сейчас наши программеры привязывают к новой версии клиента процедуру обмена сеансовыми ключами с сервером. Сеансовик дается сервером клиенту для обращения номер N к серверу, после обращения N дается сеансовик для обращения N+1. Т.е. если и стырят клиента, то рано или поздно возникнет коллизия, когда с одинаковым сеансовиком будет 2 обращения. Хотелось бы не допустить и этого хорошей привязкой к железу внешними софтовыми средствами.

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

Здравствуйте, Сергей, Спасибо за внимание!!


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

Совершенно правильно поняли.

С>2) Пустить весь протокол через SSL (лишним не будет)

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

С>3) Организовать авторизацию пользователя, логин/пароль давать только легальным клиентам (когда срок договора с клиентом закончится, его учетную запись можно заблокировать)

Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

С>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

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

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

Здравствуйте, ribentrop79, Вы писали:

R>Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

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

С>>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

R>Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

О том и речь, чтобы такие схемы подключения запретить, совсем. Повторюсь, каждый салон совтовой связи имеет свой фиксированный IP-адрес, это "жжж" неспроста.

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

R>Начальник рассказал, что когда-то была такая модель, но от нее отказались – бабушкам-аптекаршам Веб не понравился – слишком сложно.

С этим ясно.

Итак, мой диагноз: либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.
Еще один приемлемый вариант — предложен Анонимом, заключается в аппаратных ключах защиты. Но с таким вариантом можно будет воссоздать протокол подключения и сделать альтернативного клиента к вашей системе. Других вариантов не вижу.

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, ribentrop79, Вы писали:

R>>Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

С>Недобросовестным пользователям давать по ушам. В виде блокировки аккаунта. И на видном месте об этом написать. В противном случае приемлемой защиты не получится — будут только костыли.

С>>>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

R>>Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

С>О том и речь, чтобы такие схемы подключения запретить, совсем. Повторюсь, каждый салон совтовой связи имеет свой фиксированный IP-адрес, это "жжж" неспроста.

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

R>>Начальник рассказал, что когда-то была такая модель, но от нее отказались – бабушкам-аптекаршам Веб не понравился – слишком сложно.

С>С этим ясно.

С>Итак, мой диагноз: либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.
С>Еще один приемлемый вариант — предложен Анонимом, заключается в аппаратных ключах защиты. Но с таким вариантом можно будет воссоздать протокол подключения и сделать альтернативного клиента к вашей системе. Других вариантов не вижу.


Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).
Тогда засланный казачёк у программы и так может нажать PrintScreen и отдать инфу налево (если инфа не меняется каждые 5 секунд),
понятно, что ему придется это делать регулярно, что неудобно, но при любой защите кроме "перед прочтением сжечь" утечка возможна.
Аппаратная привязка — это жутко неудобно для пользователя, однако можно ввести ряд нарастающих мер, например
1) использовать крипто (SSL) сертификаты и ключи (сертификаты можно отзывать)
2) явный или неявный логин системы
3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается
4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)
5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)
6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)
7) сеансовик — идея неплохая, но он дается только один раз как начальный вектор, после каждого коннекта вычисляется следующая итерация наложения (с использованием того-же пароля входа), только нужно четко определять момент удачного логина для вычисления следующей последовательности.
8) Ну и административные меры, конечно... чуть какая трабла — наказывать, и менять ключи/серты. Как вариант — делать вид что ничего не произошло но на терминал похитителей выдавать "дезу" — всякий очень похожий на правду левак.
Это я все взял из своей жизни, ничего не напридумывал (кроме 7).

Здравствуйте, ribentrop79, Вы писали:

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

Здравствуйте, Сергей, Вы писали:


С>Итак, мой диагноз: либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.
С>Еще один приемлемый вариант — предложен Анонимом, заключается в аппаратных ключах защиты. Но с таким вариантом можно будет воссоздать протокол подключения и сделать альтернативного клиента к вашей системе. Других вариантов не вижу.

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

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

Здравствуйте, Аноним, Вы писали:



А>Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).

Если это финансовая информация реального времени, значит клиент за нее платит. Раз платит, его право давать свой пароль кому угодно. А право владельцев сервера — следить, чтобы было только подключение по одному паролю. Второго просто не соединять. Элементарно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:



А>>Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).

А>Если это финансовая информация реального времени, значит клиент за нее платит. Раз платит, его право давать свой пароль кому угодно. А право владельцев сервера — следить, чтобы было только подключение по одному паролю. Второго просто не соединять. Элементарно.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Сергей, Вы писали:


С>>Итак, мой диагноз: либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.
С>>Еще один приемлемый вариант — предложен Анонимом, заключается в аппаратных ключах защиты. Но с таким вариантом можно будет воссоздать протокол подключения и сделать альтернативного клиента к вашей системе. Других вариантов не вижу.



А>

А>либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.

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


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

Здравствуйте, Аноним, Вы писали:

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

Согласен, "Какая-то мутная проблема" непонятно толком даже что вообще на фирме автора топика хотят
сделать.
Защищать клиент -- маразм. Или вы торгуете клиентами? Тогда это маразм в квадрате,
но хоть понятна задача.

Защищать информацию? Ну так защита информации -- совершенно другая задача,
практически никак не связанная с защитой клиента от копирования. Будь он хоть
сто раз защищён от копирования -- потырить инфу может оказаться проще пареной репы. Хоть ручкой
переписать. И, блин, первый раз вижу, чтобы кто-то секретил прайсы на свои услуги.
Я бы при наличии более вменяемых конкурентов постарался не связываться с таким поставщиком.
К тому же я не спец в законах, регламентирующих торговлю, но есть смутное подозрение, что
секретные цены на свои услуги -- это даже не вполне законно, во всяком случае, магазины
запросто штрафуются за неправильный или отсутствующий ценник на товар.

Кстати, а как тогда ваши клиенты, да и вы сами перед налоговой собрались отчитываеться?

Может быть вы недостаточно чётко сформулировали задачу, стоящую перед вами и на самом
деле вам нужна не секретность информации и не защита клиента от копирования, а
надёжная идентификация пользователя? Тогда, если обычных логина/пароля недостаточно, смотрите
в сторону электронной цифровой подписи. А если вы боитесь недобросовестного поведения
клиента, так он в конце-концов может просто на свой комп пустить другого человека и с этим
уж точно ничего нельзя поделать.

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

Вношу рацпредложение — опубликовать прайс и ввести скидки от объёма (ну, типа по первой колонке, по второй, по третьей — как в больших компьютерных конторах).

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

Здравствуйте, Аноним, Вы писали:

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

А>Вношу рацпредложение — опубликовать прайс и ввести скидки от объёма (ну, типа по первой колонке, по второй, по третьей — как в больших компьютерных конторах).

А>А иначе плодится толпа незаменимых менеджеров по продажам с индивидуальным подходом к клиенту.

Вам не стать очень богатым человеком ибо в торговле вы ничего не понимаете

Здравствуйте, Michael7, Вы писали:

так он в конце-концов может просто на свой комп пустить другого человека и с этим
уж точно ничего нельзя поделать.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Michael7, Вы писали:


А>

А>так он в конце-концов может просто на свой комп пустить другого человека и с этим
А>уж точно ничего нельзя поделать.
А>

А>

Ага, как в анекдоте "говно этот ваш Паваротти, сам его, правда, не слышал, мне Васка напел"
Вариант защиты обрастает — видеокамера, распознавание персоны у компьютера, проверка а не фото-ли это неподвижное...

Здравствуйте, Аноним, Вы писали:

А>Ага, как в анекдоте "говно этот ваш Паваротти, сам его, правда, не слышал, мне Васка напел"
А>Вариант защиты обрастает — видеокамера, распознавание персоны у компьютера, проверка а не фото-ли это неподвижное...

Ну поставит он туда ЖК монитор с ПОДВИЖНЫМ фото, дальше что делать будете?

Здравствуйте, ribentrop79, Вы писали:

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Ага, как в анекдоте "говно этот ваш Паваротти, сам его, правда, не слышал, мне Васка напел"
А>>Вариант защиты обрастает — видеокамера, распознавание персоны у компьютера, проверка а не фото-ли это неподвижное...

А>Ну поставит он туда ЖК монитор с ПОДВИЖНЫМ фото, дальше что делать будете?

шо-шо... искать муаровые помехи от наложения растра камеры и растра монитора....

Всем спасибо!!! Нужно было мнение людей в теме! Создалась полная картина че да как сделать, шоб лучше. Жаль только, что программулину привязывающую никто так и не посоветовал. Вот WINlicence распробовал только что — вроде то, что надо. Содает лицензию, привязанную к железу. осталось догадаться, как поставить на поток заворачивание клиентских версий — каждому свою с соответствующим ему Hardware ID!

ribentrop79 wrote:

> Всем спасибо!!! Нужно было мнение людей в теме! Создалась полная картина
> че да как сделать, шоб лучше. Жаль только, что программулину
> привязывающую никто так и не посоветовал. Вот WINlicence распробовал
> только что — вроде то, что надо. Содает лицензию, привязанную к железу.
> осталось догадаться, как поставить на поток заворачивание клиентских
> версий — каждому свою с соответствующим ему Hardware ID!
Так ты ничего и не понял.
Сказали ведь — нафиг тебе hardware? У тебя есть сервер, а у него клиенты — вот и ограничивай клиентов, выдавай им
логины/пароли (или сертификаты). А передачу клиентами своих идентификационных данных — отслеживать (по статистике числа
орбащений, по ip-адресам и прочее) и отстреливать банами/штрафами.

Понятно...

Исходя из технических реалий (нефиксированный IP, нерпименимость WEB) и коммерческих требований , вот на чем вроде как остановилось (слова из типа как отчета):

...Для увеличения трудоемкости реализации угрозы копирования полагаем эффективным попеременное использование нескольких ASProtect-подобных продуктов (протекторы кода) .Проведен анализ рынка ASProtect-подобного ПО для привязки «клиента» к клиенту. Некоторые из них (WINlicence, PC Guard (??) ) дополнительно позволят обеспечить привязку «клиента» к клиенту своими собственными средствами...

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


...В настоящее время прорабатывается вопрос использования HARDWARE-ключей… Это позволит…

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

===============

Вообще, конечно, все черезжописто получается, не как у людей...

Здравствуйте, Аноним, Вы писали:


А>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

А>4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)

ну это вроде ж разновидность тех ж сеансовиков... нет?

А>5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)

Наскольуо я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

Интересно было бы узнать, насколько тут трудоемка была бы подмена/эмуляция IP адреса...

А>6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)

думаем

Здравствуйте, ribentrop79, Вы писали:

R>Здравствуйте, Аноним, Вы писали:


А>>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

R>Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

У нас в Саратове — порядка 30 руб/мес

Здравствуйте, ribentrop79, Вы писали:

R>Здравствуйте, Аноним, Вы писали:


А>>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

R>Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

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

А>>4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)

R>ну это вроде ж разновидность тех ж сеансовиков... нет?

о сеансовых ключах принято говорить как о временном ключе для текущей сессии, сгенерированной в процессе идентификации/аутентификации, я говорил о запрете двух одновременных сессий, идентифицированных как одна учетная запись (читай — клиент)

А>>5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)

R>Наскольуо я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

Блин! Ну все разжевать... В случае фиксированного IP — отслеживать IP, если адреса динамические — смотреть конкретно по ситуации, главное тут — набирать статистику, например если адрес меняется раз в пять минут между двумя IP в течение рабочего дня — то подозрительно..., если нерегулярно три раза в день размазанно по подсети провайдера (кстати, в договоре прописывать провайдера подписчика — их раз в день не меняют) — то может и нет. Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).
И нужно определиться с потенциальными источниками атак (внутренние, внешние, недобросовестные клиенты, сторонние организации...)


R>Интересно было бы узнать, насколько тут трудоемка была бы подмена/эмуляция IP адреса...
В локальной сети — не проблема, всякие диалапы включая adsl — уже труднее

А>>6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)

R>думаем

Вообще чтоб выполнить вашу работу нужно (грубо):
1) провести анализ угроз с точки зрения бизнеса (классификация)
2) провести анализ этих угроз с точки зрения реализации атак (синтез)
3) выработать и классифицировать методы противодействия и мониторинга
4) передать на реализацию соответствующим подразделениям (юристам, программистам, службе безопасности итп)
5) тщательно наблюдать в процессе опытной эксплуатации

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

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

Здравствуйте, ribentrop79, Вы писали:

R>Исходя из технических реалий (нефиксированный IP, нерпименимость WEB) и коммерческих требований , вот на чем вроде как остановилось (слова из типа как отчета):

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

Здравствуйте, Аноним, Вы писали:

R>>Здравствуйте, Аноним, Вы писали:

А>А так, читая это ваше все, создается ощущение что объемную задачку дали стажеру (ну, стажеру от этого может и неплохо, опыта набирается, а вот задача решается медленно, дорого и неэффективно) — без обид.

Ну отчасти так Отчасти потому что вроде как стажеру и мне и правда было интересно со всем этим разбираться. Но мне ее не дали, а подкючили к ней. А задачка в то же время решается уже давно! Вчера разговаривал с руководством и программером, который ведет эту систему на протяжении 3-4 лет уже! Создалось впечатление, что правая рука не знает, что делает левая, и что не хватает административных рычагов, чтобы внедрить то, что уже давным-давно придумано, продумано и способно защитить, исходя из угроз, коммерческих требований, маркетинга и проч…

Далее читать, если зубрам действительно интересно


Нижеследующие шаги уже давно были проделаны:

А>1) провести анализ угроз с точки зрения бизнеса (классификация)
А>2) провести анализ этих угроз с точки зрения реализации атак (синтез)
А>3) выработать и классифицировать методы противодействия и мониторинга
А>4) передать на реализацию соответствующим подразделениям (юристам, программистам, службе безопасности и т.п.)
А>5) тщательно наблюдать в процессе опытной эксплуатации.


Сначала немного по деталям:

R>>Насколько я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

А>Блин! Ну все разжевать... В случае фиксированного IP — отслеживать IP, если адреса динамические — смотреть конкретно по ситуации, главное тут — набирать статистику, например если адрес меняется раз в пять минут между двумя IP в течение рабочего дня — то подозрительно..., если нерегулярно три раза в день размазано по подсети провайдера (кстати, в договоре прописывать провайдера подписчика — их раз в день не меняют) — то может и нет.

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

А> Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).

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



Ну так вот, возвращаясь к задаче…

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

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

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

2. По определению, клиентская программка защищена/зашифрована, инсталлер привязывает клиента/его ключ к его компу. Используется ключик, завязанный на параметры компа. Но, как показала жизнь, это конкуренты отламывают. Решение такое: а) менять алгоритм образования ключа в новых версиях клиента, что совсем не сложно. А вариантов генерации ключа уйма. Не сложна и процедура обновления клиента с сервера. б) Менять алгоритм шифрования этим ключом, что тоже не трудоемко.

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

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

И следующие меры становятся не нужны:

-фиксированный IP (соответственно и подмена IP отпадает)
-хардлоки (к тому же при количестве клиентов в несколько тысяч – накладно)

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

Предыдущий пост — мой!

А>> Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).

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

Понятно куда ходите в свободное время...



А>Ну так вот, возвращаясь к задаче…

А>Ее специфика такая. Опасность представляет не отдельно стянутый прайсик, а постановка этого дела на поток у многих клиентов сразу! Ибо, как уже здесь писалось, клиентов много, у каждого свой прайс, свои скидки. Вот составление конкурентом всей этой полной картины и представляет опасность. Для этого, к примеру, из 10000 клиентов нужно получать прайсы 2000.


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


А>Какие шаги предложил вышеупомянутый программер. Перечислены в порядке необходимости внедрения:

А>1. Обязательно сеансовики! Процедура сеансовиков породит многочисленные коллизии обращения к серверу с последующим отрубанием клиента или злоумышленника. На такое, по его словам, они не пойдут, ибо это может остановить всю систему, а это как бы несимметричный удар со всеми последствиями, ибо то же делаем потом мы, рушим их систему, а потом можно еще подключить органы и прочее…

добавьте просто передачу набора локальных данных компа (мак адрес, список айпи, список драйвов и метки томов хардов, модель материнки и видюшки, размер памяти, точную версию винды...) , т.е. первый запуск — просто передача, далее сравнение и анализ на предмет "фрода". Разрешение работы только одного UserID. При высокой вероятности "нелегала" — навязывать дезу.

А>2. По определению, клиентская программка защищена/зашифрована, инсталлер привязывает клиента/его ключ к его компу. Используется ключик, завязанный на параметры компа. Но, как показала жизнь, это конкуренты отламывают. Решение такое: а) менять алгоритм образования ключа в новых версиях клиента, что совсем не сложно. А вариантов генерации ключа уйма. Не сложна и процедура обновления клиента с сервера. б) Менять алгоритм шифрования этим ключом, что тоже не трудоемко.

это уже не надо

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

и это уже не надо

А>Практика может показать, что и первого шага будет достаточно… Если же нет, то самое главное, чтобы время на преодоление/взлом вышеуказанных схем защиты 2 и 3 было бы велико по сравнению с временем между сменой сеансовиков, после чего они уже не сунуться. Вот такая понятая мной логическая цепочка. Защита целиком программными средствами.

это верно. а против бабы мани с ксероксом как?

А>И следующие меры становятся не нужны:

А>-фиксированный IP (соответственно и подмена IP отпадает)
А>-хардлоки (к тому же при количестве клиентов в несколько тысяч – накладно)

верно

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

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

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

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

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

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

Вдвоём на одном аккаунте жить можно будет, но надо будет постоянно таскать эту куку между двумя компьютерами. Если соединания устанавливаются часто, это будет доставать.
Файл с кукой можно лочить на время работы (чтобы надо было останавливать клиента чтобы забрать куку).
Можно сохранять куку где-нибудь у винды в protected storage (опять же, достать всё равно можно, но уже не Far'ом).

Ресинхронизация куки — после трёпа по телефону.
В нерабочее время клиентов не впускать.
Уже писали — не пускать 2 соединения для одного аккаунта одновременно — им придётся договариваться, чтобы аптекарши выключали на время своего клиента. Договориться с 2000 аптекарш тоже непросто.

Куку можно постоянно (раз в 2/5/15 мин менять) — она будет устаревать пока её несут.

Здравствуйте, ribentrop79, Вы писали:

Довольно таки интересно. Простите за нескромный вопрос А у вас вообще есть аналитик по той же безопасности хоть что-то понимающий в защите данных? От доступа копирования и т д? Вы вкурсе как устроены те же электронные магазины Доступ к БД банков. Литературу какую-нибудь используете? Что классическое вам известо о защите информащии. У меня создалось впечатление что Вы пытаетесь решить большую проблему пажарными методами -- так не делается. Возникнут ещё большие проблемы.