Как запретить параллельное (одновременное) использование одного аккаунта разными пользователями?

Question

[Alex Goncharov]

Use case: есть платная платформа, в которой нужно запретить использование одного аккаунта большим (> 1) количеством пользователей одновременно. Если есть активность одного пользователя - то запрещать вход другим пользователям в этот аккаунт.

Каким образом реализуется данный функционал? Как запретить параллельное (одновременное) использование одного аккаунта разными пользователями? Как понять, что пользователь не активен и давать возможность залогиниться с другого устройства? Может быть ограничивать вход по IP?

Поделитесь практикой, коллеги.

Comments

[Antonio Solo]

по IP привязывать глупо, может быть динамический IP

надо создавать сессию в ней отслеживать активность, а ID сессии сохранять у пользователя.

ну и соответственно при попытке нового логина смотреть активность последней сессии и если она активна - блокировать вход (либо пропускать, но затирать старую)

Answer 1

[Dmitry Alekseev]

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

Comments

[sim3x]

Те если токен скопировать, то проблем не будет

[Dmitry Alekseev]

sim3x, ну, чтобы его скопировать, его нужно сначала узнать, а это уже вопрос защиты пользовательской стороны. Когда я делаю токены, то они создаются на основе различных полей и метрик, такие как идентификатор устройства, IP-адрес, User-Agent и тд. Т.е, если его просто скопировать на другое устройство это ничего не даст, потому что токен будет невалидным

[sim3x]

Dmitry Alekseev,
Круто
Значит просто скопируем профиль одного браузера
И тк большая часть юзеров сидит за серым ип...

[Dmitry Alekseev]

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

[GeneAYak]

sim3x, для этого делается два токена, access и refresh.
access токен это как раз тот, про который написали выше, прикладывается к каждому запросу. Но у него малое время жизни, например пять минут. Когда он истекает, используется второй, и когда проходит обновление, то присылаются оба новых. А на втором устройстве, ты уже не сможешь обновить первый.

[sim3x]

GeneAYak, те открыть сайт два раза на одном устройстве не получися нормально?

[sim3x]

Dmitry Alekseev, Я указал, в ответе, что проще, лучше и надежнее

[Dmitry Alekseev]

sim3x, Нет, Вы указали, какую-то либу, как идеальное решение и посоветовали сделать администраторам за акками. По мне так это не решение.

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

[sim3x]

Dmitry Alekseev,
Я указал как ее просто обойти

[Dmitry Alekseev]

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

Предложенная мной схема работает во множестве крупных IT-компаний. Хотел бы я посмотреть, как вы будете обходить сервис, который блокирует токен на первом же скомпроментированном запросе.

Не вижу смысла дальше продолжать этот спор.

[sim3x]

Dmitry Alekseev, никто не говорит о вредителе - разговор про оптимизацию оплаты в виде использования одного аккаунта для все фирмы

Дайте названия фирм

Пока что спор беспредметный

[Dmitry Alekseev]

sim3x, все API гулга и яндекса построено вокруг токенов.

[sim3x]

Dmitry Alekseev, круто

Где у гугла или яндекса стоит задача ограничения запуска на одном ПК?

[GeneAYak]

sim3x, если делать с двумя токенами то можно заходить с двух устройств, но в течение нескольких минут из одного из аккаунтов будет вылетать, так что дрочи пользователю это добавит. Но если использовать оба сразу, то не ясно из какого именно. Можно рассмотреть как вариант открытие сокета, тогда сразу и четко видно, что пользователь делает вторую сессию. Но это не спасет от пользования на двух устройствах, но в разное время (хотя ИМХО и не должно), а вот от одновременного да. Ну это простые варианты, а в целом, конечно, нужно строить систему анализа трафика, которая будет смотреть на айпишник, агент и так далее

[sim3x]

GeneAYak,

Как запретить параллельное (одновременное) использование одного аккаунта разными пользователями?

[GeneAYak]

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

[sim3x]

GeneAYak, или просто делать фингерпринт и не морочить голову оверинжинирингом на ровном месте

Answer 2

[hckn]

Просто делай логаут, если зафиксирован логин с другого устройства.

Comments

[hckn]

Alice Shevtsova, ну сессия же будет другая, а данные пользователя теже. Искать сессию с этими данными и удалять ее.

[hckn]

Alice Shevtsova, намного глупее утверждать что нечто глупо, не приведя никаких доводов в опровержение.

[Dmitry Alekseev]

Абсолютно правильный подход. При авторизации пользователя деактивировать все предыдущие сессии этого пользователя.

[hckn]

Dmitry Alekseev, имхо, наиболее класно - это хранить все сессии и показывать их юзеру, чтобы он сам выбрал которую деактивировать. Но это больше мороки с имплементацией. :)

[Dmitry Alekseev]

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

[Сергей Соколов]

«Логаут остальных» не решает проблему. Да, одновременно не будет сессии нескольких одновременно. Но все продолжат одновременную работу в бессессионном режиме: автологинясь при очередном запросе.

[hckn]

Сергей Соколов,

автологинясь при очередном запросе

Каким образом? При логауте удаление сессии. Логин только после предоставления логин:пасс. Что за автологин в даном случае?

[Сергей Соколов]

hckn, в вопросе нет деталей. Ну, допустим, расширение в браузере, которое автоматом логинит.

[hckn]

Сергей Соколов, да вы фантазер.

[Сергей Соколов]

hckn, без деталей от ТС говорить не о чем.
Общий принцип причины и следствия в варианте «залогинился другой — отключай более раннего» ошибочен.

[hckn]

Сергей Соколов, в чем ошибочен? Он ошибочен только если вы начинаете фантазировать про какие-то расширения. Этот способ пуленепробиваем.

[Сергей Соколов]

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

[hckn]

Сергей Соколов, я добиваюсь

запретить параллельное (одновременное) использование одного аккаунта

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

Надо максимально привязать аккаунт к одному пользователю? Ну прикрутите СМС для логина, например, это усложнит использование аккаунта несколькими сторонними людьми

[Сергей Соколов]

hckn, не определено, что значит “использовать”. Например, стриминг видео: стартанул один и смотрит. Другой, третий. В вашем варианте любое число юзеров может залогиниться и стартануть каждый свой стрим, если в процессе просмотра не перепроверяется активность “сессии”

[hckn]

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

Answer 3

[Сергей Соколов]

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

Как отличать «этот» визит от «других». Точно не по IP, т.к. пользователь может быть мобильным. По «отпечатку браузера» или по набору cookies.
При очередном запросе мутировать куку, чтобы копирование кук на другое устройство не помогло. Что-то вроде CSRF-токенов использовать при каждом запросе.
На случай вылета пользователя предусмотреть timeout, по истечении которого разрешать любой логин в этот аккаунт.

Comments

[FanatPHP]

а что не так с мобильными пользователями?
и зачем "запирать"? проще авторизовывать следующего.

[Сергей Соколов]

FanatPHP, у мобильного меняется ip по пути. Проще не значит лучше.

Answer 4

[sim3x]

Вам нужны forevercookies и/или идентификация по доп параметрам, например https://github.com/Valve/fingerprintjs2

Но лучше такие вещи решать административным способом - так чтоб использовать один акк на несколько человек не требовалось

Comments

[hckn]

forevercookies? это нечто из теории. не видел ниодной имплементации. Даже определения четкого нету у этой штуки. Что вы можете рассказать об forevercookies? Если речь об этом, то интерес к этой поделки может быть разве что исследовательский - https://github.com/samyk/evercookie

Никто это не использует.

[sim3x]

hckn,
сами указали на имплементацию и сами ее не видите. Странно

Хорошо, что кроме NSA и соцсетей никто ее не использует

[hckn]

sim3x, соцсети это не используют. Иначе их саппорт был бы завален сотнями тысяч ишью по ложным срабатываниям ежедневно (+ я как практикующий ботовод могу это утверждать по своему опыту). Ну и ТС явно не NSA и не Фейсбук.

[sim3x]

hckn, а кто сказал, что они используют их для таких целей?
Сколько там % аудитории соцсеточек боты и зачем сеточкам отрезать ботов?

Не надо обижать ТСа

Answer 5

[WTERH]

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

Я бы использовал дополнительное поле в базе, куда записывал бы 1, после авторизации.
А на этапе авторизации, проверял бы это поле, если там 1, облом, иначе авторизуем.

Но это лишь пример.

Comments

[WTERH]

Dmitry, О бож, к чему такое утрирование?

[WTERH]

Dmitry, не надо сводить это к прямой зависимости от поля. Можно же вести контроль за ним и предусмотреть возможность кулдауна

Answer 6

[Сергей Сулаков]

При логине сохраните session_id() в базе данных. Затем сравниваете текущий с тем, что записано в базе, и если не совпадает - логаут.

$db_session_hash= $db_session_hash ?: get_session_hash($__id);//Хеш "текущей" активной сессии в базе если не получен ранее
			if($db_session_hash!=$_SESSION['auth']['session_hash']){
				unset($_SESSION['auth']);
				add_notification('danger', 'В ваш аккаунт выполнен вход на другом устройстве или браузере.');
			}