Как работает уникальность пользователя?

Question

[0x80070005]

Имеются вот расширения где присутствуют уникальные данные пользователя, но при это там нет авторизации. Как это работает? На стороне клиента генерируется уникальный ID, добавляем в LocalStorage и это и есть уникальность?

Comments

[setupx]

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

[0x80070005]

setupx, а какие варианты решения есть? Там где платные услуги они это как-то делают и авторизации нет

[0x80070005]

setupx, я просто не проходился по таким расширениям, сразу сюда зашел спросить)

[0x80070005]

setupx, у меня вот один вариант есть как это примерно можно реализовать. После покупки услуги выдает ключ и этот ключ пользователь активирует и сам ключ храним уже. Но все равно, а вдруг у нас просто данные хранятся без каких-либо покупок

[Ziptar]

0x80070005, примеры?

[0x80070005]

Ziptar, допустим, vpn

[Ziptar]

0x80070005, нет, не допустим, конкретное приложение/сервис, с конкретным названием

[0x80070005]

Ziptar, да любой vpn возьми. Почти у каждого есть покупка

[0x80070005]

Ziptar, Adblock, да куча таких расширений

[Ziptar]

0x80070005, у адблока нет платных функций. Там оплата в виде пожертвования сделана, ему нет никакой необходимости идентифицировать пользователя вовсе.

Answer 1

[0x80070005]

Решение: на стороне сервера у нас должен быть url который будет сверять переданный token из localstorage и если такого нет токена, генерируем новый и отдаем клиенту и кидаем в local. Все :)

Answer 2

[artem]

да, всё верно. уникальность пользователя часто реализуется через генерацию уникального ID на стороне клиента. этот ID сохраняется в localStorage, и каждый раз при взаимодействии с расширением используется для идентификации пользователя

Comments

[0x80070005]

Но этот айди же можно подменить :)

[AUser0]

Но этот айди же можно подменить :)

:-) :-) :-)
Ну подмените, пожалуйста, флаг в руки!
Если строка идентификации например 64 символа - сколько вы её будете подбирать, что бы она совпала с ID другого пользователя? Посчитали? Хотя-бы прикинули?
А теперь прикиньте поведение правильно построенного сайта, к которому 100500+ раз обратились с не существующими ID... Да даже 15-ти раз хватит!

[0x80070005]

AUser0, очень легко это делается. Открывается localstorage, меняем id на «123» и готово :)

Можно только рассчитывать на то, что пользователь которые решит сделать себе id “123” не будет актуальным.

[AUser0]

0x80070005, подменить-то легко, зато подобрать реальный ID другого пользователя - черезвычайно сложно. Конечно если сайт адекватный, и не использует 123 в качестве идентификатора. А если ещё и отслеживает перескоки пользователя с одного IP+UserAgent на другой IP+UserAgent...

[0x80070005]

AUser0, а как agent и ip поможет? Даже если я начну сверять формат I’d на сервере, все равно подменить легко.

[0x80070005]

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

Хотя стоп! Если мы генерируем айди на сервере, то подписывать его не нужно получатся. Просто сверяем айди если он даже подделан и меняем в случае чего

[AUser0]

0x80070005, да без разницы где генерировать случайный ID, хоть на сервере, хоть на клиенте. Главное - его длина/сложность, и его хранение/проверка на сервере. А дальше - хоть заподбирайся 64-ёхсимвольную, а ещё лучше 256-исимвольную случайную строку, ну-ну.

Нет, ну конечно, клиент, сгенерировавший себе ID в виде 000000000[64раза] - ССЗБ, это сразу понятно.

[0x80070005]

AUser0, разница есть. На клиенте если я буду генерировать токен и отдавать серверу, то смогу его подделать, а если я буду генерировать его на сервере и отдавать клиенту, подделать его уже невозможно :)

[AUser0]

0x80070005, вы подделаете только свой токен, вот и всё. Взламывать самого себя по своему-же токену? И куда это вас приведёт?
Единственная проблема генерации токенов у клиента - это возможность заспамить сервер новыми неиспользуемыми токенами.

[0x80070005]

AUser0, я же вам выше пример приложил того, что может быть на клиенте. Представим, у нас генерация на клиенте идет и какой-то пользователь решил сделать себе токен «123» а не 16-ти битный. Другой пользователь что сделает? Возьмет откроет localstorage и просто укажет «123», ради интереса и тут у него оказывается доступ к другому аккаунту.

В случае генерации на стороне сервера, пользователь не сможет указать собственный токен.

Если генерировать на стороне клиента, его нужно подписывать. А-ля, использовать сквозное шифрование.

То, что я ему сгенерирую 64 битный токен на клиенте и отдам его серверу, ему ничего не помешает этот формат поменять. Это клиент

[AUser0]

0x80070005, а с чего это вдруг клиент может менять токен как ему вздумается? Сервер не может проверить длину токена, количество символов в токене, их повторяемость типа 64 нуля подряд, не?

[0x80070005]

AUser0, может, но он эту длину и сам может придумать :)

[AUser0]

0x80070005, а сервер - проверить на взломоустойчивость и безапелляционно отвергнуть. Се-ля-ви, знаете ли!

[0x80070005]

AUser0, ты предлагаешь генерировать токен на клиенте, чтобы потом куча проверок делать на сервере? Зачем тебе сервер тогда? Логика где?

[AUser0]

0x80070005, я не настаиваю, что надо. Я говорю, что это вполне возможно, если не обращать внимания на возможность спама одноразовыми токенами.