Пару дней назад Петя Диденко у себя в твиттере задал вопрос, как решить достаточно распространенную задачу «Если оплачен один аккаунт, как не дать работать двум юзерам», ну и получил он огромную пачку ответов, среди которых был и мой самый простой вариант решения проблемы. Распишу сначала свое решение поподробнее, прежде чем двигаться дальше: в соглашении данной услуги пишем, что пользоваться услугой может только человек, на которого зарегистрирован аккаунт, если будут замечены случаи передачи аккаунта третьим лицам, то аккаунт будет заблокирован без возможности возврата денежных средств (особо юридические текста я писать не умею, но смысл должен быть понятен). То есть пункт в договоре есть, читать, правда, его все равно никто не будет, но мы предупредили. Дальше ведем список активных сессий и просто следим, что при попытке зайти под определенным аккаунтом, если активна другая сессия с этим же аккаунтов, то просто предыдущую сессию затирать, в результате чего человека с предыдущей сессией просто выкинет на страницу авторизации. Ну и соответственно все такие вещи стоит записывать в лог, из которого иногда выдирать те аккаунты, у которых часто происходит этот такой обрыв сессий – и их уже анализируем. Сессии пускай имеют timeout по 30 минут, если меняешь компьютер, с которого используешь этот аккаунт с домашнего на рабочий, скорее всего, столько времени и нужно, чтобы добраться до работы, и сессия просто оборвется, потому наше правило на этот случай не будет распространяться. Решение предельно простое, и никак не напрягает правомерных пользователей.
Давайте теперь рассмотрим другие варианты, которые были предложены Пете, и, со всем уважением к Пете, подумаем, почему им выбранный вариант не так уж и хорош.
Кстати, хочется заметить, что это опять разговор на тему Мнимая безопасность VS юзабилити, которую я недавно поднимал уже.
Сертификат, как средство аутентификации
Макс предложил вариант использования неэскортируемого сертификата для каждого пользователя. Идея примерно в следующем: каждый пользователь будет иметь неэскортируемый сертификат на компьютере (более того один раз импортируемый), тогда, вроде, у пользователя просто не будет возможности зайти с двух компьютеров. Тут, конечно, задача требует уточнения. Во-первых, если приложение нужно будет сертифицировать (в плане регистрации или оно будет использоваться государственными учреждениями), то придется использовать алгоритмы ГОСТа, а значит, пользователи должны будут покупать клиентское ПО, вроде Крипто-Про, для работы с сертификатами, заточенными под эти алгоритмы, а это уже будет не дешево для простого сервиса. Так же, вроде как, неправомерно раздавать сертификаты подобным образом просто через веб, за ним нужно будет топать ногами, а потому чтобы сделать сертификат неэскортируемым уже нужно будет к тому же еще и использовать всяческие eToken, которые опять стоят денег. Но это все в случае, когда приложение как-то будет связано с нашим государством, если это услуги другого характера, вроде продажа видео-контента, то решение просто отличное, так как тогда можно будет забыть про eToken и ГОСТы и воспользоваться реализацией, предложенной Максом. Возможность обхода этого способа все же есть – это импорт сертификата на виртуальную машину, и дальнейшее клонирование этой виртуальной машины. Но это уже будет решаться на уровне реально «продвинутых парней». Таким способом можно отсечь простых малознающих пользователей (чтобы тетя Зина не передавала пароль тете Лене), да даже «продвинутые парни» не всегда додумают до такого способа, да и могут просто залениться заморачиваться, а это уже хорошо. Главное еще, чтобы сертификаты было легко устанавливать, и все было интуитивно понятно простому пользователю – ну а этого можно добиться через хорошую справочную систему и систему мастеров. Ну и тут еще можно заметить про один минус: если будем использовать ActiveX, то тогда только приложение будет нормально работать только под Internet Explorer, под другие браузеры нужны специальные плагины позволяющие запускать ActiveX.
Подумал еще, что может быть и есть возможность перехватить сертификат до того как его установить ActiveX в хранилище компьютера, вроде не вижу ничего запрещающего это сделать, только сложно понять как. Но надо будет, придумают.
В аккаунте держать приватные данные
Ну от того что «тетя Зина передаст пароль тете Лене» это не спасет. У меня мама при регистрации думала раньше, что это нормально вводить номер паспорта, если спросят, я хоть ей объяснил, что это не очень хорошо. Но думаю, если ее подруга попросит аккаунт от чего-нибудь, где есть приватные данные – она его отдаст без проблем. Вообще, я могу сказать одно: я вашим сервисам доверяю меньше, чем вы мне. Да я даже номер телефона свой теперь не дам банку, чтобы он мне потом не слал всяческие предложения о том, какие у них теперь классные кредиты. В общем, идея – полный бред. Это надо иметь супер уникальный сервис без альтернатив, чтобы я все-таки согласился ввести туда свой паспорт, да и то, как это спасет от того, что я введу левый паспорт? В общем и целом идея просто никак не решает данную проблему.
Привязка сессии к компьютеру на длительный срок
Вроде очень длинной, к примеру, 2х недельной сессии. Как мне пользоваться сервисом и дома и на работе, как мне пользоваться сервером с двух домашних компьютеров? А если я переустановил/купил новый компьютер, мне теперь ждать 2 недели? Притом привязка будет как осуществляться? При помощи cookie? MAC-адреса? Сообразительным парням эту защиту будет проще взломать даже чем с одноразовыми сертификатами. Данное решение – только вред честным пользователям и смех для сообразительных парней.
Одноразовые пароли
Одноразовые пароли в виде sms, приходящих на телефон, указанный в договоре/аккаунте, либо специальное устройство генерирующее пароль вам для данной сессии. Устройство – сразу нет, потому что недешево для пользователей. SMS подешевле конечно, чуть меньше цента за одну отправку, и расходы уже пойдут на компанию, которая данные сервис предоставляет. Но в целом, если я этим сервисом пользуюсь 3 часа в день, а моему знакомому тоже нужно около 3х часов в день на этот сервис, разве мы не можем договориться о том, чтобы платить вместе, заходить по очереди, и скидывать пароль друг другу? Да без проблем, все зависит конечно от того сколько стоит данные сервис. Если дешево, то, скорее всего, без проблем купим себе по отдельному сервису, если дорого, то будем пользоваться так. В общем не вижу, что решит данная проблема, кроме как увеличит расходы компании, предоставляющий сервис и следовательно и цену за этот сервис.
Хочется заметить, что основная идея данного подхода в том, чтобы не дать возможность злоумышленникам своровать ваш аккаунт и воспользоваться им. А от того, что пользователь сам хочет поделиться своим аккаунтом - этот вариант не спасет.
Вывод
Далеко ходить не нужно, посмотрите вокруг. У Blizzard есть Battle.net, если бы все его пользователи сидели только под своими аккаунтами и не передавали друг другу, то, как думаете, больше ли был у них доход и на сколько? Почему они не делают супер авторизаций, денег больше не нужно? :) Думайте больше о пользователях и создавайте качественные сервисы – это совет пользователя. ;)