AISА ещё есть пример, когда пользователь для работы скачивает клиенское приложение, которое в защищенном режиме общается с сервером и никто другой доступа к информации не имеет, т.к. без клиенского ПО связи нет. Ставится подписка на месяц, и пусть смотрит сам, с другом или кум, сват брат, но через это клиенское ПО.
Клиенсткое ПО не подходит, если его само придётся защищать, как в вашем случае. Если же это просто удобный интерфейс пользователя к моему АПИ (которое находится полностью на моём сервере), то и отдельно скачивать нет резона - HTML достаточно.

AISВы не с теми сайтами сравниваете.
Сравните, например, сайты по законодательству (ЛигаЗакон) или рассылка смс (ТурбоСМС).
Чтобы начать пользоваться - авторизуйся. Потом пользуйся согласно расценок. Клиент за живые деньги покупает виртуальные "деньги", типа "юниты", и тратит их. Хочеш скачать "закон" - уплати 2 юнита. Хочеш отправить СМС - плати N-юнитов.
Зашел в свой аккаунт, посмотрел расходы (за что когда платил).
Что тут не понятного, нового, сложного?

Это реально работает. На лицо "мотивация" клиента управлять своими расходами и беспокоится за их сохранность.
И последнее. Клиент купил "юниты" и в праве их использовать как хочется ему, т.е. и поделится с другом.
Если пользуются на пару по согласию, то на этой паре даже теоритически больше не заработать, т.е. Вы ничего не теряете.
А не материальный доход - это скрытая реклама, которую клиент дает своему другу. И наступет день и этот друг сам себе купит эти самые юниты. Теория о будущих доходах ;)
Это "модель онлайн-игр". Игровая валюта, виртуальная валюта. Наши пользователи, я считаю, к этому ещё не готовы. Это, как правило, серьёзные дяди, зачастую, пожилого возраста, выросшие не на таких играх и могущие даже не знать, что такое виртуальная валюта. Я даже своему начальнику это долго буду объяснять...

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

AISP.S. Вы бы действительно приоткрыли бы занавес "что делаете". Легче было бы посоветовать. Направленный мозговой штурм всегда продуктивней, чем абстрактный креатив :)
Так я же писал - делаю сайт. Я его называю веб-приложением, потому что сайт и есть веб-приложение. Просто раньше мы делали небольшие приложения для десктопа, распространяемые на дисках или загружаемые с сайта в виде дистрибутивов, а сейчас надо проверить возможность переноса этих приложений в веб в виде сайтов на портале. Но если диски раньше защищали USB-токенами, то как быть с сайтом я пока не придумал. Одно для меня ясно, что тут модель продажи подойдёт лучше всего подписочная.

AIS user7320,
по размещению и планы как бы понятны. Я предлагал, полагаю как и другие ранее, обозначить Вам тему ПО, т.е. это игры, инфа, корпоративный контент и т.д. Не как выводить (об этом и креатив), а что Вы хотите распространять?
Это информация для обучения в специфической области. Мы её просто собираем и выкладываем как базу данных или своего рода учебник для ознакомления или обучения. Только раньше в виде приложения для десктопов распространяли, а сейчас в виде сайта будет.

miksoftДля того же онлайн-вещания, например, это может быть единственная онлайн-сессия. Залогинился кто-то другой - тебя вышибло . Например, Steam вторую сессию не пускает.
miksoftuser7320Допустим, юзер скопировал куки с одной машины на другую и пользуется сервисом с той же сессией, что "осталась" на прежней машине.На простых сайтах, действительно, сессия может быть угнана таким образом.
Однако, более продвинутые сайты при этом проверяют, чтобы все соединения одной сессии были с одного и того же ip-адреса, что в случае разных машин возможно, только если они "сидят" за общим NAT-ом.
Еще более продвинутые сайты регулярно меняют идентификатор сессии, т.е. уже через несколько секунд старые куки будут бесполезны .
Да, пожалуй, я выберу именно это сочетание.

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

Если куки меняются каждые 10 секунд, например, то такую схему может сломать только специально написанное ПО, которое будет синхронизировать куки между браузерами.

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

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

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

Всё основано на ASP.NET MVC. Там есть понятия Responce (набор данных ,пришедших от юзера на сервер, включая куки), Request (набор данных, уходящих с сервера к юзеру), Profile (набор данных на сервере, относящийся к конкретному юзеру).

На моём сайте есть два понятия сессии. Одна - FormsAuthentication - за неё отвечает залогинивание в функции LogOn и вылогинивание в функции LogOut. Другая - моя система, ограничивающая доступ к определённым адресам на сайте. Она реализована в виде фильтра, который может применяться к конктроллерам и действиям.

Алгоритм работы системы такой:

(рисунок)




Несколько сценариев. Простые сценарии, вроде стёртых куки, разбирать не буду, т. к. они сразу ведут к перелогиниванию.

Сценарий 1. Честный юзер залогинен и у него установлены куки (cookieIsSet == true).

1; 2; 3; 4; 5; 7; 9 или 11; 12.

Сценарий 2. Честный юзер логинится с другого браузера, тогда как на первом браузере он уже залогинен и у него установлены куки в этом первом браузере (cookieIsSet == true).

1; 2; 3; 4; 6 (на втором-то браузере куки не установлены ещё).

Сценарий 3. Продолжение сценария 2, но для первого браузера. При этом, если во втором браузере юзер уже перелогинился и успел пройти по фильтру, то для юзера первого браузера повторяется сценарий второго браузера и так по кругу - таким образом я запрещаю две одновременные сессии на двух разных браузерах.

А если во втором браузере не успел перелогиниться и пройти по фильтру, то на первом браузере юзер работает как и раньше работал.

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

Сценарий 4 (САМЫЙ ИНТЕРЕСНЫЙ). Нечестный юзер. Он своровал куки честного юзера один раз и вклиниватеся в сессию этого честного юзера с другого браузера. Т. е. нечестный уже залогинен, у него и куки в Request есть, причём совпадающие с теми, что на сервере в Profile, и на сервере в Profile в переменной cookieIsSet у него стоит true - как и для честного юзера. Т. е. на текущий момент они различаются только браузерами, НО МОЯ СИСТЕМА ИХ НЕ РАЗЛИЧАЕТ.

До того момента, как куки устареют, оба юзера работают как легальные и проходят по такому пути алгоритма:

2; 3; 4; 5; 7; 9; 12.

Далее, как только приходит первый запрос с устаревшими куки, не важно, от какого пользователя - честного или нечестного - предыдущий путь изменяется так, что после 9 идёт 11 и затем 12.

Теперь пользователи называются не "честный" и "нечестный", а "пользователь со старыми куки" и "с новыми куки". Тот, кто с новыми, становится "легальным" и работает дальше по маршруту выше (2; 3; 4; 5; 7; 9; 12), а со старыми идёт по маршруту

2; 3; 4; 5; 7; 10.

Т. е. этот пользователь рассматривается как нелегальный и ему предлагается перелогиниться. Ну а дальше по разобранным ранее сценариям.



Итого, что я получаю:

1. Пользователь мотивируется не делиться своей учёткой, иначе это создаст ему неудобства в работе (постоянные перелогинивания).

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

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



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

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

В сценарии 1 без первого пункта - иначе cookieIsSet будет false.

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

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