👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

По 2му: jwt.io/introduction
Возможно тут найдете че-то полезное, хорошая статья: habrahabr.ru/...​mpany/mailru/blog/343288

Кстати, очень хорошая идея насчёт авторизации с токенами. Поясню вкратце в чём суть, и как реализовать.

Вобщем, когда юзер авторизован, вместо генерации sessionID, и включения его в таблицу сессий, генерируется токен, который состоит из всех необходимых данных, подписанных сервером. В данные можно включить ID юзера, время действия токена, и его основные права. Ещё можно включить хэш useragent и адреса, чтоб не угоняли токен. Далее эта инфа на основе закрытого ключа подписывается через ECDSA, и на основании открытого ключа может быть проверена на любом сервере. То есть решается таким образом ещё проблема одной точки входа. Считаем минимальную длину токена: 8 bytes userID + 8 bytes expiry time + 4 bytes crc32(useragent+IP) + 64 bytes signature = 84 bytes token. Есть один минус: сверка подписи — дорогостоящая операция, и основная часть нагрузки на сервер возможно будет приходиться на проверку подписей.

Есть один минус: сверка подписи — дорогостоящая операция

Я тут решил провести тесты, насколько это дорогостоящая операция. Написал 2 цикла на Go, оба выполняются 1000000 раз, в первом цикле вычисляется хэш SHA256 от 32 байт, во втором проверка подписи ECDSA. Так вот, у меня на проце Core i7-3770K вычисление хэша происходит за 376 мс, а сверка подписи за 1мин 44сек, то есть каждая подпись сверяется в 273 раза дольше вычисления хэша. Кроме того, тест показывает, что при 10тыс запросах в секунду проверка подписи положит сервер, и при 2,5млн запросов в секунду положит сервер проверка хэшей.

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

Написал 2 цикла на Go

дальше не читал

По второму пункту уже писали sha256. А можете и все 512, что бы наверняка.

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

Что бы иметь возможность гарантировать своим юзерам НЕвозможность слития этих самых идентификаторов (номера телефонов например)

Не зовсім зрозуміло, що мається на увазі під «слития». Щоб знизити к-сть мультиакаунтів потрібно вводити KYC процес, але це можливо буде не зовсім автоматичний процес. І всеодно ніхто не забороняє людині, використати чужі документи(фото, відео і т.д), але з точки зору вашої системи це будуть зовсім інші люди. Тут питання скоріше в тому перед ким Ви відповідальні за гарантію в неможливості свторити декілька акаунтів для людини

Давайте с терминами определимся. Мы говорим об аутентификации или об авторизации?

имеется ввиду создание для юзера сесии на сайте предварительно убедившись что рание он не получал авторизованый доступ с другими лич.данными

не сохранять этот самый идентификатор на сервере в чистом виде, тоесть чтобы даже не передавать его на сервер в чистом виде

Можно передавать как хэш, например sha256(salt + iv + userID), где salt — константная соль, iv — открытый ключ, индивидуальный для каждого. То есть, аналогично хранению паролей в базе.

Если хотите избежать мультиакков — создайте условия, при которых юзерам нет необходимости заводить кучу аккаунтов © Конфуций.

Так а что использовать в качестве юзерИд?

Уникальный идентификатор пользователя, который нужно оставить секретным (номер телефона например). Соль и iv используется для того, чтобы по хэшу не восстановить индетификатор/пароль через радужные таблицы. Хотя для sha256 это всё равно нереально выполнить.

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

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

Кстати, я однажды даже здесь написал тему со своим решением, как обеспечить защиту сервера от несанкционированного администрирования, когда третьи лица имеют доступ ко всему, и любые секреты на сервере могут быть скомпрометированы: dou.ua/forums/topic/17690

ок, давайте с каким нибуть примером из реальности чтоб стал понятнее требования к механизму:
не так давно закрылась не родившись толком укр.соц сеть
какой вердитк ИТ-сообщества? — «собрали личные данные юзеров и слились»
или 100500 примеров груп в соц.сетях где нагнетают рейтинг какихнибуть полит.сил

допустим я хочу сделать «стартап» — который предпологает участие большого количества людей, для голосования за что либо
в перспективе такой сервис может стать интересен кому нибуть кто схочет склонить «статистику на свою сторону» (скажем производитель товара с рейтингом с целью его увеличить). Тут и появляется заинтересованость в мультиАкках

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

Вы написали — сервер вычесляет хеш — это значит что телефон в явном виде я могу перехватить на сервере и сохранить например себе в отдельную базу
Речь идет о том чтобы гарантировать безопасность юзеров не на словах, а физически исключая такую возможность (недобросовесного использования личных данных)

Тут уж имхо только некий государственный электронный id

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

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

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

Если для вас даже это неприемлемо — поинтересуйтесь bank ID или работой с АЦСК, как здесь уже предлагали. Так вы предоставите процедуру аутентификации довереному лицу (банку или госконторе), а они будут вам отдавать уникальный айдишник, по которому будет невозможно узнать личные данные юзера напрямую (хотя вас все равно могут заподозрить в сотрудничестве с банком и сборе информации)

Смс без хранения телефона в базе данных. Погрешность от мультиаков будет не критичной.

не, вы не поняли. Он хочет не только в данных не хранить, но и на сервер телефоны не отправлять

Да вроде запрос на смс можно выслать и со стороны клиента, а на сервер отправлять хэш для хранения и сверки. Но это напоминает больше.

Но в целом, больше похоже, что у человека желание сделать без бэка сервис, исключительно на фронте...

Да вроде запрос на смс можно выслать и со стороны клиента, а на сервер отправлять хэш для хранения и сверки.

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

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

Вот и интересуюсь имеется ли возможность идентефицировать реальных людей (по максимуму) от фейк.аккаунтов.

Практически это нереально. Работал с некоторыми базами данных, и вот что могу сказать. Минимум 2-3 телефона есть практически у всех. Банковских счетов — может быть ещё больше. Квартир/домов тоже может быть несколько. Людей с несколькими паспортами — намного больше, чем кажется. Гран-при может получить какой-то чел из Москвы, у которого около 70 паспортов, удостоверяющих личность в разных странах, причём в одной и той же стране может быть по несколько штук. Вобщем, даже в реале мультиакк — вполне обычное дело.

Все зависит от уровня желаемой защиты от дубликатов. С одной стороны — никнейм+пароль, без проверок. Посредине: имейлы с доп защитой(например не паблик емейл домены), телефоны, какие-то личные данных(дата рождения, фио, и тд). С другой — нотариально заверенные копии идентификационных(и прочих государственных id) кодов.
Естествено, что в обычных сценариях пользователи не любят когда от них требуют 100500 личных данных и подтверждений.
Поэтому исходя из имеющихся данных, решение прикрутить OAuth выглядит нормальным и логичным. Крупные OAuth провайдеры(facebook, google, twitter etc.) сами не любят дубликатов и борются с ними по мере сил, тем самым снимают с вас приличную часть головняка.
Можете дополнительно требовать чтобы в профиле пользователей были обязательно заполнены поля типа мыло-телефон.

почему не будет возможности? отсылайте юзеру смс с кодом подтверждения

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

Есть хитрый способ: вход руб, выход два. То есть когда после регистрации эккаунт попадает в некий тамбур, и уже после оределённого количества действий его «неожиданно» ставят действие на подтверждение эккаунта, и все другие действия блокируются. За этот промежуток времени за мультиакком внимательно следят скрипты, чтобы прибить потом одним махом всю сеть. А владелец мультиакка даже не догадывается, что с самого начала надо было применить некоторые меры защиты.

От профессионалов не спасёт.

Максимально надежного — нет и не будет. Относительно надежные способы — использование ключей от Минюста или ДПА (вроде и от нас сейчас есть) — так вы сможете идентифицировать что кто-то авторизировался с данными ключами в такое-то время на вашем ресурсе.

Підписатись на коментарі