Вхід і реєстрація
Розробка · 9 грудня 2017, 20:29 2367
Андрюха Цибрій, Freelancer в freelance

Способы авторизации

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Допустим есть веб-сервис для доступа на который нужна идентификация юзера

Задача:
1 — использовать максимально недежный способ идентификаци что бы снизить к минимуму количество мульти-аккаунтов
2 — не сохранять этот самый идентификатор на сервере в чистом виде, тоесть чтобы даже не передавать его на сервер в чистом виде

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

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

Теми: авторизация
👍ПодобаєтьсяСподобалось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
Olegek Bondar Senior Developer 12.12.2017 00:09

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

Відповісти
Підтримати
schwarzlichtbezirk 12.12.2017 03:22

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

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

Відповісти
Підтримати
Olegek Bondar
schwarzlichtbezirk 12.12.2017 06:36
Есть один минус: сверка подписи — дорогостоящая операция

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

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

Відповісти
Підтримати
schwarzlichtbezirk
Artyom Krivokrisenko 12.12.2017 08:08
Написал 2 цикла на Go

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

Відповісти
Підтримати
schwarzlichtbezirk
Александр Шевченко Java developer 10.12.2017 13:06

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

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

Відповісти
Підтримати
Maksym Besida Scala developer 10.12.2017 12:04
Что бы иметь возможность гарантировать своим юзерам НЕвозможность слития этих самых идентификаторов (номера телефонов например)

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

Відповісти
Підтримати
Sergey Solution Architect 10.12.2017 10:53

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

Відповісти
Підтримати
Андрюха Цибрій Freelancer в freelance 10.12.2017 14:18

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

Відповісти
Підтримати
Sergey
schwarzlichtbezirk 10.12.2017 00:58
не сохранять этот самый идентификатор на сервере в чистом виде, тоесть чтобы даже не передавать его на сервер в чистом виде

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

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

Відповісти
Підтримати
Андрюха Цибрій Freelancer в freelance 10.12.2017 01:25

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

Відповісти
Підтримати
schwarzlichtbezirk
schwarzlichtbezirk 10.12.2017 12:47

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

Відповісти
Підтримати
Андрюха Цибрій
Андрюха Цибрій Freelancer в freelance 10.12.2017 14:20

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

Відповісти
Підтримати
schwarzlichtbezirk
schwarzlichtbezirk 10.12.2017 15:28

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

Відповісти
Підтримати
Андрюха Цибрій
schwarzlichtbezirk 10.12.2017 15:47

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

Відповісти
Підтримати
schwarzlichtbezirk
Андрюха Цибрій Freelancer в freelance 10.12.2017 17:44

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

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

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

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

Відповісти
Підтримати
schwarzlichtbezirk
Alex Koshterek погромизд 10.12.2017 18:12

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

Відповісти
Підтримати
Андрюха Цибрій
Andriy Maletsky 10.12.2017 18:20

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

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

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

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

Відповісти
Підтримати
Андрюха Цибрій
Александр Шевченко Java developer 10.12.2017 18:31

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

Відповісти
Підтримати
Андрюха Цибрій
Andriy Maletsky 10.12.2017 18:38

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

Відповісти
Підтримати
Александр Шевченко
Александр Шевченко Java developer 10.12.2017 23:30

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

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

Відповісти
Підтримати
Andriy Maletsky
schwarzlichtbezirk 11.12.2017 06:12
Да вроде запрос на смс можно выслать и со стороны клиента, а на сервер отправлять хэш для хранения и сверки.

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

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

Відповісти
Підтримати
Александр Шевченко
schwarzlichtbezirk 10.12.2017 19:25
Вот и интересуюсь имеется ли возможность идентефицировать реальных людей (по максимуму) от фейк.аккаунтов.

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

Відповісти
Підтримати
Андрюха Цибрій
Sergey Solution Architect 10.12.2017 23:06

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

Відповісти
Підтримати
Андрюха Цибрій
Andriy Maletsky 10.12.2017 17:01

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

Відповісти
Підтримати
Андрюха Цибрій
Олексій Пєніє 09.12.2017 23:43

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

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

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

Відповісти
Підтримати
anonymous 09.12.2017 20:48

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.