Задача: Есть сервер на .Net, при подключении к нему, клиентские приложения проходят авторизацию. Нужно чтобы сервер ограничивал количество одновременно авторизирированных пользователей согласно количеству купленных лицензий. (если куплено 30 лицензий, то при попытке аворизироваться 31м — отвечать ему отказом)
После того как я погуглил и покумекал у меня возникла
Идея:
Шаг 1:вынести саму проверку в маленький класс (назовем его
LicenseCheker), который в результате проверки должен возвращать некий
токен- объект реализующий спец.интерфейс
ILicenseToken. Если в результате проверки мы получил токен — все ок.
Шаг 2: Код реализующий
LicenseCheker и
ILicenseToken выносим в отдельный файл. шифруем его закрытым ключем.
Шаг 3: Во время выполнения расшифровуем файл, проводим динамическую компиляцию — получаем работающий код.
Шаг 4: (????)Для надежности можно раз в 15 минут сбрасывать и повторять шаг 3
Дополнительно: можно все это поместить в электронный ключ.
Вопросы:
1. На сколько идея бредовая
2. Посоветуйте хороший алгоритм шифровканиичя открытым\закрытым ключем. Есть ли готовые реализации?
3. Что вы думаете по поводу электронного ключа — нужно ли это тут
4.(совсем неккоретный, но) Как бы вы оценили объем трудозатрат.
Огромное спасибо за ответы
Здравствуйте, vladpol, Вы писали:
V>Шаг 1:вынести саму проверку в маленький класс (назовем его LicenseCheker), который в результате проверки должен возвращать некий токен- объект реализующий спец.интерфейс ILicenseToken. Если в результате проверки мы получил токен — все ок.
Зачем тебе объект в качестве токена, непонятно. По моему токен, должен быть не более чем набором байт... Но это не принципиально.
V>Шаг 2: Код реализующий LicenseCheker и ILicenseToken выносим в отдельный файл. шифруем его закрытым ключем.
Хорошая мысль.
V>Шаг 3: Во время выполнения расшифровуем файл, проводим динамическую компиляцию — получаем работающий код.
Самое слабое звено
. Все что появилось в памяти процесса элементарно дампиться... Последствия уточнять не будем.
V>Шаг 4: (????)Для надежности можно раз в 15 минут сбрасывать и повторять шаг 3
Мысль хорошая но не спасет...
V>Дополнительно: можно все это поместить в электронный ключ.
См. комментарии к 3 и 4.
V>1. На сколько идея бредовая
Против хомячков поможет. Если твой софт комуто станет нужен, сломают в течении получаса.
V>2. Посоветуйте хороший алгоритм шифровканиичя открытым\закрытым ключем. Есть ли готовые реализации?
Алгоритмов, как и реализаций пруд-пруди. Гугл в помощь.
V>3. Что вы думаете по поводу электронного ключа — нужно ли это тут
Зависит от ценности софта.
V>4.(совсем неккоретный, но) Как бы вы оценили объем трудозатрат.
Реализовать, и отладить — день, с чаем блекджеком и шлюхами...
V>Огромное спасибо за ответы
И тебе не хворать...
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, vladpol, Вы писали:
V>>Шаг 1:вынести саму проверку в маленький класс (назовем его LicenseCheker), который в результате проверки должен возвращать некий токен- объект реализующий спец.интерфейс ILicenseToken. Если в результате проверки мы получил токен — все ок.
А>Зачем тебе объект в качестве токена, непонятно. По моему токен, должен быть не более чем набором байт... Но это не принципиально.
V>>Шаг 2: Код реализующий LicenseCheker и ILicenseToken выносим в отдельный файл. шифруем его закрытым ключем.
А>Хорошая мысль.
V>>Шаг 3: Во время выполнения расшифровуем файл, проводим динамическую компиляцию — получаем работающий код.
А>Самое слабое звено . Все что появилось в памяти процесса элементарно дампиться... Последствия уточнять не будем.
А если сверху обфускатором полирнуть? И вообще что посоветуете?
Защитить .Net приложение от взлома достаточно сложно. Но кое-что можно попытаться сделать.
В Вашем случае, например, количество лицензий зашифрованное вашим закрытым ключом хранить в отдельном файле. В программе расшифровывать открытым ключом. Но нужно защитить процедуру проверки лицензии обфускатором (через code-flow obfuscation).
Для того, чтобы помешать несанкционированному распространению файла лицензий, его можно держать в "железном" носителе (типа eToken).
