Безопасная аутентификая пользователей без сессий?

Question

[Александр]

Здравствуйте.
Интересует, есть ли безопасный вариант аутентификации пользователей без сессий?
Нагуглил, что есть jwt. Но при краже токена злоумышленник может пользоваться учётной записью в пределах срока жизни access token.
Есть что-то безопаснее?

Comments

[Евгений Ромашкан]

Интересует, есть ли безопасный вариант аутентификации пользователей без сессий?
Нагуглил, что есть jwt. Но при краже токена злоумышленник может пользоваться учётной записью в пределах срока жизни access token.

При краже id сессии злоумышленник так же может пользоваться учётной записью в пределах срока жизни сессии.
А вообще - cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt...

[Александр]

Да, но кража сессий происходит на стороне сервера (или не только?). Так что в этом случае ничего не поможет. Интересует именно клиентская часть.

[Евгений Ромашкан]

Александр,

Да, но кража сессий происходит на стороне сервера (или не только?). Так что в этом случае ничего не поможет. Интересует именно клиентская часть.

Разберитесь как сессии работают. На клиенте всегда будут данные по которым вы его аутентификацируете и их всегда можно подделать.

[ThunderCat]

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

[Александр]

Евгений Ромашкан, разобрался. Вы правы, моё сравнение с сессией неудачное. Тогда вопрос сводится к тому, можно ли на 100% точно определить угнан или нет токен, пришедший от клиента (не важно хранится он у него в cookies или ls)?

[Александр]

ThunderCat, проблема может быть в получении доступа к персональным данным пользователей третьими лицами.
Я не профессионал, а Вы, надеюсь, да. Вот у Вас и спрашиваю. С задачей написания личного кабинета раньше не сталкивался. В руки попадались сайты с уже написанным кабинетом, и все были на сессиях. Сейчас нужно хранить аутентифицированного пользователя дольше, чем время жизни сессии. Начал изучать вопрос, и оказалось, что jwt - хороший вариант, за исключением того, что токен могут увести. Это гугление, а не мои придумки. Таких тем как эта полно. Но так и не нашёл полностью безопасный способ аутентификации пользователя.

[ThunderCat]

Александр,

за исключением того, что токен могут увести.

Еще раз - ВСЕ могут увести, все к чему может дотянуться яваскрипт (а он может дотянуться практически до всего что можно отправить в качестве ключа серверу) может быть скомпрометировано на стороне клиента. Это не ваша проблема, и это не проблема сервиса, по крайней мере если сервис обезопасил приложение от внешних вредоносных скриптов ЧЕРЕЗ САЙТ. Ничего не гарантирует защиты пользователя от действия третьих лиц, например левых плагинов в браузере, вирусов, подсмотренных паролей в браузере, просто тупо бумажки с логином и паролем на столе... Но все это не проблемы безопасности сервиса, это персональная защита данных, которую должен обеспечить пользователь самостоятельно. Все проблемы которые вы себе придумали (и в частности короткие сессии, которые кроме того что регулируются программно, еще и могут быть дублированы каким-то ключом в куках, как сделано на многих сайтах, где есть галочка "запомнить меня") в основном к вам как к разработчику никак не относятся.

[Александр]

ThunderCat, спасибо за развёрнутый ответ!

Answer 1

[FanatPHP]

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

Comments

[Александр]

Хотелось бы, чтобы на стороне клиента нельзя было подделать данные (например, токен). Jwt украли и всё тут. Да, можно с вместе токеном хранить на сервере юзер агент и прочее, но это тоже подделывается.

[FanatPHP]

Что значит подделать?
Что значит украли? Как именно?
Какой конкретно сценарий атаки в данном случае отрабатывается?
Чем сессия не устраивает?

[Robur]

Александр, Если у вас подразумевается что у клиента можно данные просто "украсть и все тут" - то никак.
Только аутентификация по видеозвонку менеджеру и то это не 100%.

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

[Александр]

FanatPHP, выше ThunderCat привёл пару примеров кражи токена: "действия третьих лиц, например левых плагинов в браузере, вирусов". И ThunderCat верно заметил, что это будет вина пользователя. Вопрос, можно ли в этом случае 100% понять, что этот краденый (но ещё валидный токен) используется не тем, кому он выписан?
Сессии не устраивают сроком жизни.

Answer 2

[Александр Аксентьев]

Ну вот как раз таки JWT у вас угонят и вы не узнаете, а сессию вполне себе можно привязать к юзерагенту/ip/чему угодно на серверной стороне. Хотя и в JWT можно это вписать, но проще уж с сессиями тогда.

А так кроме сессий никаких авторизаций больше и нет как класс. В любом случае что-то в браузере хранится что сервер может распознать, и это есть "сессия".

Comments

[Александр]

Юзерагент/ip подделывается.
А, если установить для cookie HttpOnly, это поможет от считывания их через js, верно? Какими средствами для защиты пользовательских данных Вы пользуетесь?

Answer 3

[Владимир Скибин]

https://gist.github.com/zmts/802dc9c3510d79fd40f9d...
умейте пользоваться поиском тут

Comments

[Александр]

Спасибо за ссылку. Вопросы в других комментариях к этому посту остались.

Answer 4

[xmoonlight]

Токен привязывется к браузеру.
Как именно?
1. При аутентификации, отпечаток клиента (fingerprint) шифруется парольным хешем пользователя (на стороне клиента!) и сверху, "оборачивается": шифруется публичным ключом сервера, и затем, пересылается серверу.
2. Сервер открывает своим приватным ключом пакет, расшифроввывает с помощью своего парольного хеша (для этого конкретного юзера, из БД), и получает данные fingerprint.
3. Сервер привязывает данные fingerprint к токену и отправляет токен и функцию хеширования fingerprint'а клиенту.
4. При каждом запросе, клиент отправляет свой токен и подписываем запрос хешем fingerprint'а.
5. Сервер сверяет токен и подпись запроса (хешем fingerprint'а).
6. При их несовпадении - токен становится невалидным (сессия завершается).

Чтобы сохранить хеш fingerprint'а ещё более надёжно, его можно привязать к IP-адресу.
При смене IP - произойдёт "прозрачная" переинициализация сессии (и с запросом реального fingerprint'а клиента), незаметная для конечного пользователя (если у него валидный токен для вновь определённого fingerprint'а).

При краже кук или перехватие трафика - злоумышленник не знает реального fingerprint.
А без него - он не сможет подделать подпись, чтобы воспользоваться текущим токеном.

Comments

[Александр]

Спасибо за развёрнутый ответ!

Я правильно понимаю, что Ваш метод отличается от jwt тем, что там подпись основывается на хэше заголовка и полезной нагрузки, а у Вас на хэше fingerprint'а?

Вопросы по пунктам:
1)

отпечаток клиента (fingerprint)

Fingerprint получается с помощью какой-то js библиотеки? Что бы Вы посоветовали?

шифруется парольным хешем пользователя

Пароль берём из формы аутентификации, куда пользователь его вводит, получаем его хэш (любой функцией?) и с его помощью шифруем (чем лучше шифровать?) fingerprint, верно?

Все операции первого пункта происходят на клиенте? Видимо, с помощью какой-то js библиотеки?

2)

Сервер открывает своим приватным ключом пакет

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

[xmoonlight]

Александр, ой...
Вы ничего не понимаете (как бы грустно это не звучало).
Могу сказать, что:
1. Либа - fingerprint2.js (гуглите)
2. Почитайте на википедии про синхронное и асинхронное шифрование и обмен ключами, чтобы понимать принцип работы.
3. Мой метод основывается на том, чем пользуются сейчас банки и крупные мировые платёжные системы.
А именно: комплексная проверка клиентских данных при любых операциях через мобильный терминал (без посещения офиса): данные аутентификации, данные клиента взаимодействия (ПО: браузер и т.д.), данные сессии при её миграции/роуменге по разным подсетям/геолокациям (мобильное устройство клиента), используя все известные вычисленные данные (кроме данных авторизации!) после этапа авторизации.
Разница с jwt, надеюсь, понятна.