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

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

Вобщем, когда юзер авторизован, вместо генерации 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 месте, а все остальные сервисы юзают публичный ключ.

Что не так с Go?

-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Матан-капча

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

Гемор относительный.

-