Доброго времени суток. Сейчас проектирую клиент-серверное приложение по сбору данных с клиентских машин. Клиент написан на си, open source, закачка бинарной сборки возможна из личного кабинета на сайте. Для идентификации программы-клиента планируется использовать некий токен — рандомное число, порядка 10 байт, которое внедряется в код программы непосредственно перед заливкой на сайт. То-есть факт закачки данного экземпляра привязывает токен к аккаунту клиента. Сама по себе клиентская часть бесполезна, но зато при этой схеме идентификации есть возможность осуществления банального саботажа — путём запуска экземпляра программы, с подобранным token'ом, на хосте не имеющего отношения к заказчику, при этом она будет слать свою информацию, в итоге на сервере вместо полезной статистики получится информационный мусор. Как вариант, защиту можно усилить вторым токеном передаваемом на этапе инсталяции клиентской части, например mac-адресом. Но что-то мне в этой схеме не нравится, что-то на интуитивном уровне — просто ещё не осознал какие грабли из этого могут получится. Пожалуйста, раскритикуйте данную схему идентификации.
тут просто много вариантов, в зависимости от того насколько критичен авторизованный доступ от клиентов. Если ни на что не влияет — можно завести новую пару и пропускать, если наоборот за этим стоят деньги, то блокировать токен совсем. В любом случае можно письмо кинуть что появиласть новая неавторизованная пара.
Разбираться надо, поскольку это может быть просто смена адреса у клиента. Могут быть совсем экзотичные вещи типа несколько адресов на сервере и падение одного из аплинков.
вы о том, что mac-адрес легко изменить? если да, то предложенные вами варианты так-же бесполезны, ибо как я уже сказал, клиентская часть — open source, для потенциального вредителя изменить алгоритм формирования второго токена не составит труда.
Средний
Сложный
