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

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

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...

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

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

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

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

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

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

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

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

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

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, каковы дальнейшие действия сервера?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xmoonlight:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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