Правильно ли я понял, как работает токен?

Question

[Shane Matte]

пишу rest api. У всех пользователей есть уникальный токен. С мобильного приложения я отправляю логин и пароль на сервер api. После если все верно я отдаю клиенту этот уникальный токен, и как мобильное приложение spa, сохраняю его в документе. И все запросы делаю через этот токен, на сервере проверяю, если такой существует, отдаю данные.

Answer 1

[Сергей Протько]

Да. Все верно.

Единственное что добавлю, пересылать токен лучше в заголовках. Причем желательно, поскольку механизм аутентификации нестандартный, в заголовке X-Authorization. Если вы решите хранить токен в куках и передавать его, это желательно должны быть http-only куки (хотя в случае JWT не обязательно) и на сервере должна быть защита от CSRF атак.

Так же поскольку у нас по сети гуляют по сути креденшелы, важно использовать SSL. Благо сегодня есть lets-encrypt что бы бесплатно получить сертификаты.

И последнее, что бы обезопасить себя еще, используйте refresh-токены. То есть наш уникальный токен который гуляет в каждом запросе будет иметь ограничение по времени жизни (скажем 5 минут) и для его обновления мы будем использовать refresh-токен. При получении refresh токена клиенту уходит новая пара токен + refresh-токен.

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

Comments

[DevMan]

заголовки вида X-* вроде же как в деприкейте, не?

[Сергей Протько]

DevMan: Да, но скажите это Apple и их гайдлайнам. Они категорически настаивают на том что бы для кастомной аутентификации использовались X-* заголовки, потому что дефолтный Authorization может быть переопределен системой.

В целом RFC 6648 говорит ли что это не рекомендуется но не запрещено.

[DevMan]

Сергей Протько: я не спорю, только прояснил для себя. спасибо.

[Shane Matte]

я пишу мобильное приложенте, простое с помощью phonegap. В заголовках там где хранить, если в meta теге? И что вы имеете обновлять токен, т.е. заново будет просить аутентификацию?

[Сергей Протько]

Shane Matte: в вашем случае нужно хранить в localStorage. С учетом того что вы собирались хранить в метатеге - рекомендую более детально разобраться что зачем и почему.

[Shane Matte]

Сергей Протько: да, но phonegap не может хранить в localstorage. И сейчас тестирую отправку данных с мобильного приложения, там лежат обычные html, js, css. Пишет cross ошибку, как с этим быть, если приложение будет работать локально на телефоне

[Александр]

Shane Matte: cordova умеет хранить в localstorage, чего б phonegap не уметь?

[Shane Matte]

Александр: А как бороться с Uncaught SyntaxError: Unexpected identifier? Сервер отправляет, но js дает эту ошибку

[Александр]

Shane Matte: ну по этой ошибке без кода не ясно)

[Shane Matte]

Александр: Смотри, при авторизации, если не верно, сервер отсылает обычную строку, такого пользователя нет, все ок, клиент принимает сообщение, но в консоле выводит ошибку Uncaught SyntaxError: Unexpected identifier. И скрипт дальше не выполняется

[Александр]

Shane Matte: открываем sources в браузере, ставим точку, дебажим.. смотрим почему там Unexpected identifier

[Shane Matte]

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

[Сергей Протько]

Shane Matte: а может вам хватит просто токена + SSL?

Answer 2

[xmoonlight]

Я мимо проходил и, вроде, все верно, кроме:

С мобильного приложения я отправляю логин и пароль на сервер api.

Никогда! Слышишь, Карл?! НИКОГДА НЕ ПЕРЕСЫЛАЙ данные авторизации на сервер БЕЗ ПРЕДВАРИТЕЛЬНОГО ХЕШИРОВАНИЯ на стороне клиента серверным ключом.

1. Данные на клиенте: hash(USER1:PASSWORD:SKEY:RANDOM),
2. Пересылаю на сервер: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM
3. Ищу на сервере совпадение:
ab1e37ab50c61d8c80fb5cb4b1e3122f===hash(USER:PASSWORD:SKEY:RANDOM) и получаю учётку пользователя, если все верно.

А так, да! Спасибо, Сергей Протько - все довольно четко и верно написано!

Comments

[Roman K]

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

[xmoonlight]

Roman Kitaev: ок. заменю на хэш!

[Алексей Ярков]

1. Данные на клиенте: md5(USER1:PASSWORD:SKEY:RANDOM),
2. Пересылаю на сервер: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM
3. Ищу на сервере совпадение:
ab1e37ab50c61d8c80fb5cb4b1e3122f===md5(USER:PASSWORD:SKEY:RANDOM) и получаю учётку пользователя, если все верно.

Как получить одинаковый RANDOM на сервере и на клиенте?

[Данил Бирюков-Романов]

Алексей Ярков: Как вариант сгенерировать его через https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D...

[xmoonlight]

Алексей Ярков: ах-да... я думал, что это просто, поясню: его отдаёт сервер при запросе авторизации и срок действия у него 15 секунд.

[Aves]

xmoonlight: это получается сервер должен знать пароль пользователя? Как-то некошерно.

[xmoonlight]

Aves: почему?! он может не знать даже логина) серверу нужно знать только UID=hash(USER:PASSWORD). Я же не пишу полную формулу, а пишу только принцип))) Думать надо!)

[Aves]

xmoonlight: в целом очень странная схема, клиент присылает хэш, сервер дожен получить из базы все логины с паролями, вычислить для каждого hash(USER:PASSWORD:SKEY:RANDOM) и если найдётся равный присланному, то авторизовать соответствующий аккаунт, так получается?
Как-то уж очень много недостатков по сравнению с простой передачей пароля по https.

[xmoonlight]

Aves: интересно, а про какие недостатки тут речь?

[Aves]

xmoonlight: как я писал выше - хранение пароля на сервер, плюс вычисление для каждой попытки логина хэшей всех пользователей - это готовый ddos.

[xmoonlight]

Aves: нет, если у вас есть поле hash и skey

[Aves]

xmoonlight: и как из полей hash и skey вычисляется hash(USER:PASSWORD:SKEY:RANDOM)?

[xmoonlight]

Aves: hash(UHASH:SKEY:RANDOM) SKEY - выписывается сервером и хранится напротив юзера. по skey - поиск и дальше - верификация.

[Aves]

xmoonlight: итак, клиент регистрируется. Сервер генерирует случайные skey и random1 и высылает из клиенту. Клиент придумывает user и password, вычисляет uhash1 = hash(user:password:skey:random1) и отправляет на сервер uhash1. Сервер записывает в базу uhash1 и skey.
На следующий день некто хочет залогиниться, как сервер найдёт в базе нужный skey?
Пусть в базе записано имя user и клиент говорит - я user и хочу авторизоваться. Сервер находит в базе запись с именем user, берёт из неё skey, генерирует random2, высылает skey и random2 клиенту. Клиент вычисляет uhash2 = hash(user:password:skey:random2) и отправляет на сервер uhash2. Итого у сервера есть user skey random2 uhash2, каковы дальнейшие действия сервера?

[Aves]

И забыл еще у сервера есть uhash1 в базе.

[xmoonlight]

Aves: я ж написал выше: "по skey - поиск и дальше - верификация. " В чем проблема то?

[Aves]

xmoonlight: я написал в чем проблема.

[xmoonlight]

Aves: сервер знает skey и uhash - они уникальны. поиск идет по skey и находится только 1 запись. Еще какие вопросы?!

[Aves]

xmoonlight: полный бред. uhash для каждой попытки логина разный, как он может использоваться в аутентификации? Откуда сервер берёт skey, по которому ведёт поиск?

[xmoonlight]

Aves: ок. закончили.

[Aves]

xmoonlight: да, отличный ответ, а то я ждал "поиск идет по skey и находится только 1 запись, дальше - верификация".
Всё с тобой понятно, клоун.

[xmoonlight]

Aves: клоун тот, кто не разобравшись - начинает хамить. Советую, просто сесть с ручкой и бумажкой ивсё расписать шаг за шагом, и все станет ясно.

[Aves]

xmoonlight: Ты сначала на заданные мной вопросы ответь, прежде чем советы раздавать, чтоб было видно, чего они стоят.

[xmoonlight]

Aves: нет смысла отвечать человеку, который не понимает (или не хочет понимать!)

[Aves]

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

[xmoonlight]

Aves: ок. предлагаю перейти к конструктивному диалогу. диаграмму состояний при обмене данными между сервером и клиентом в твоём понимании - в студию. Я посмотрю и мы поймём кто и где ошибся. Согласен?

[Aves]

xmoonlight: я уже диаграмму состояний твоей схемы расписал выше, и задал вопросы там, где она перестаёт работать. Ответь на них. Если я твою схему понял неправильно, напиши где.
Схема в ответе работает только при условии хранения пароля на сервере. Без отправки логина серверу придётся каждый раз вычислять хэш для всех аккаутов в базе. Дальнейший бред про "поиск по skey" просто неработоспособен.

[xmoonlight]

Aves:
1. Клиент и сервер - знают один и тот же skey.
2. Он привязывается к аккаунту в момент генерации на стороне сервера и его время формирования - также записывается.
3. Когда приходит на сервер hash от клиента, сервер знает уже: USER, PASSWORD, SKEY, SKEY_TIMESTAMP (юзера и пароль - лучше хранить в зашифрованном виде) и ему остаётся рассчитать серверный хеш (для проведения сравнения с клиентским), используя с RANDOM.
Сервер перебирает не все подряд аккаунты, чтобы посчитать хэш для проведения сравнения, а только за:
a) указанный максимально возможный интервал (5-10 сек)
б) в хронологическом порядке формирования SKEY, базируясь на SKEY_TIMESTAMP
В итоге - срабатывает всё мгновенно вне зависимости от кол-ва пользователей в системе.

[Aves]

xmoonlight:

1. Клиент и сервер - знают один и тот же skey.

Знают откуда? Божественное откровение? Вот я купил новый планшет, захожу на сайт, хочу залогиниться, где я беру skey?

3. Когда приходит на сервер hash от клиента, сервер знает уже: USER, PASSWORD, SKEY, SKEY_TIMESTAMP (юзера и пароль - лучше хранить в зашифрованном виде)

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

В целом ничего не прояснилось. Напиши так же, как я, пошагово:
1. Инициация попытки логина. На начало данного этапа идентификационной информации нет никакой. Что посылает клиент серверу.
2. Ответ сервера. Как находит и создаёт сервер данные для ответа, что отвечает клиенту.
3. Здесь по твоей схеме на клиенте вводится логин и пароль, происходит хеширование. По твоим словам отсылается на сервер только хэш.

[xmoonlight]

Aves:
1. "Откуда знают?" - догадаться было, канешн, трудно))))
Зарегился и пришел тебе PIN по СМС или код в линке на почту (двух факторная аутентификация).
2. можно не хранить пароль!)) можно хранить хэш-связку hash(логин:пароль) - это уже кто как хочет))) (главное, при этом - не забыть юзеру дать задать себе какое-то имя: friendly-name, но можно и без этого, просто ID-шники выводить, но это зрительно - не удобно будет)
3. LOGIN: отправляем hash и random от клиента на сервер.
4. "Как находит сервер данные для ответа?": Выборка с сортировкой по увеличению прошедшего времени на основе выставленных SKEY_TIMESTAMP: берет из стека верхнюю запись, вычисляет хэш и сравнивает с присланным клиентским.
5. "Про ввод логина и пароля" - да, просто людям так проще. можно было бы вводить просто парный хеш (как я написал в п.2)
6. "По твоим словам отсылается на сервер только хэш." - читай в ответе внимательно: "2. Пересылаю на сервер: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM"

Сейчас всё стало понятно?!)))

[Aves]

xmoonlight: Опять начался бред с кучей условий, допущений и предположений. Началось с того, что клиенту достаточно выслать один хэш, закончилось двухфакторной авторизацией. Если есть двухфакторная авторизация, то зачем дальнейшая чушь нужна, достаточно ввести пришедший на почту или sms одноразовый код.

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

[xmoonlight]

Aves: "Началось с того, что клиенту достаточно выслать один хэш" - это где такое было?!

[Aves]

xmoonlight: угу, началось "где я такое говорил", "я не это имел в виду", "тут надо было догадаться".
Предлагаю последний раз, напиши по пунктам, начиная с полного отсутствия идентификационной информации. На комментарий типа "что тут может быть непонятного, тут всё очевидно" я даже отвечать не буду, трепло.

[Сергей Протько]

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

[xmoonlight]

Сергей Протько: ключ можно располовинить: половину из письма - линк с GET-запросом (или PIN из SMS), половину - вернём с сервера при клике (или после ввода PIN в поле ввода). В итоге - две половины окажутся у клиента разными путями и затем захешировать и положить готовый ключ в LocalStorage для дальнейшего использования.
Или я не прав здесь?...

[Сергей Протько]

xmoonlight: в принципе правы... но зачем это делать? SSL + SSL pinning + обычный digest не решают этой проблемы достаточно хорошо?

[xmoonlight]

Сергей Протько: я не хотел заменять что-то существующее и работающее хорошо (не было целью), я спросил конкретно про безопасное хранение... А так - да: SSL+digest вполне себе решают проблему.

[Владимир Шестаков]

xmoonlight: >> Никогда! Слышишь, Карл?! НИКОГДА НЕ ПЕРЕСЫЛАЙ данные авторизации на сервер БЕЗ ПРЕДВАРИТЕЛЬНОГО ХЕШИРОВАНИЯ на стороне клиента серверным ключом.

И при регистрации? Как сервер получит исходные данные (логин, пароль), чтобы потом генерировать хэши?

[xmoonlight]

Денис: лично я не имел ввиду этот метод, в описанном мной методе, фактически, доставка всего ключа идёт разными каналами связи и без каких-либо клиентских скриптов.

[xmoonlight]

Владимир Шестаков: сервер при инициализации процедуры регистрации отправляет серверный ключ (SKEY) через хэш по двум каналам на клиент.
Затем, сервер получает хэш-пару от клиента с подписанным этим ключом и формирует запись на сервере (т.е. clientID=hash(user+pass+SKEY+RANDOM) и отдельно пересылает RANDOM), далее - можно сменить пару clientID, используя ранее выданный токен или refreshToken.
Сервер никогда не знает отдельно логина и пароля.
Для визуального отображения пользователей на странице - заводится поле FriendlyName и все.

[Владимир Шестаков]

xmoonlight: Хэшированный ключ? Из хэша же ключ не вытащить, чтобы потом делать cliendId. Или что значит "отправляет серверный ключ (SKEY) через хэш"?

Можно пример двух каналов связи?

Сильно интересно разобраться, но пока путаница какая-то из-за неточностей в утверждениях. Если сервер не знает пароля/логина, то из чего он хэши новые генерирует? А если знает, то как они попадают на сервер и он их хранит значит? Как по clienId с фронта будет найден пользователь на сервере? От чего такая система защищает?

[xmoonlight]

Владимир Шестаков: сервер знает ключ и пару (логин и пароль) в едином хеше, которые пересылются посредством сгенерированного сервером ключа через процедуру замены (сгенерированного ранее самим сервером).