Как идентифицировать пользователя на сайте, по мимо fingerprints?

Моя задача сделать идентификацию пользователя на страничке, ip отметаем сразу т-к VPN cookie тоже, тк почистил кеш, и вуаля, ты новый человек fingerprints довольно сильный инструмент, но все же бывают ложные срабатывания Я думал о создании js тяжелого кода и фиксировать время его выполнения, тк на каждой машине разная мощность итд. Посоветуйте еще способы идентификации пользователей, есть группа недоброжелателей которая каждый раз создает новые аккаунты и продолжают заниматься грязными делами.


Ответы (2 шт):

Автор решения: xydope

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

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

Возможно, имеет смысл в целом переосмыслить ситуацию и ваши ответные меры. Вместо того, чтобы пытаться узнать (условно) имя того, кто вас "бьет", попробовать сделать так, чтобы не могли бить.

→ Ссылка
Автор решения: artomich

Автоматически со всех сайтов сразу почистить localStorage гораздо потруднее будет, чем куки, следовательно, чтобы усложнить работу тырнет-гангстерам, можно работать с ним.

Можно, например, формировать на сервере рандомную строку, кидать ее в базу приятных пользователей вместе с данными о нашем конкретном новозарегистрированном пользователе, а непосредственно на клиенте ставить ее в хранилище. Затем с каждым запросом отправлять ключ, чтобы проверять на сервере, существует ли он, соответствует ли он прикрепленному к сессии (тут хорош websocket) и нет ли его в базе неприятных пользователей. Если что-то не так - блокируем запрос и ругаем юзера.

При этом чтобы узнавать, когда юзер изменил ключ в storage или удалил его, можно реализовать две штуки: во-первых, отправлять крик о помощи на сервер в обработчике события storage (работает при любом изменении всегда, но можно любой обработчик удалить в консоли) - и тогда просить клиент снова поставить сохраненный и прикрепленный к сессии ключ в хранилище, предварительно перенаправив его в базу черного списка; во-вторых, пытаться отправлять этот ключ серверу каждую секунду-две, опять же, через сокет, чтобы сервер проверял, соответствует ли он первозданному (тут уж по производительности смотрите сами) - со всеми вышеуказанными вытекающими.
И да, повторюсь, стоит использовать websocket.

Ссылки, на всякий случай: о WebSocket (сторона клиента); о WebSocket (сторона сервера - node.js); о WebSocket (сторона сервера - php); localStorage (мало ли)

→ Ссылка