LINUX.ORG.RU

Как сделать аутентификацию?

 , , , ,


0

1

Здравствуйте

Сделал свой велосипед вместо JSON-RPC. Сделал простейшую аутентификацию: встроенные методы «login» и «register», которые вызываются с параметрами user и password и возвращают id сессии

// Логин
>> ['@call', ['@login', 'user', 'password']]
<< ['@ans', ['sid123']]

// Дальше все методы вызываются с полученным sid-ом
>> ['@call', ['sum', 1, 2], 'sid123']

Подскажите советов мудрых, как проапгрейдить процесс аутентификации, чтобы она не была зашкваром? Что-нибудь зашифровать, захешировать, подписать, посолить. Безопасно чтобы было, в общем

Deleted

Последнее исправление: Deleted (всего исправлений: 1)

// Дальше все методы вызываются с полученным sid-ом

Если это делается в браузере, то по сравнению с типикал cookies ты избавился от CSRF (не такая сложная проблема изначально) и получил проблему с XSS (каждый скрипт с CDN может стащить твою сессию и ты ничерта с этим не сделаешь).

Что-нибудь зашифровать, захешировать, подписать, посолить

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

Если ключ сессии предсказуем — стоит сделать его достаточно длинным.

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

x3al ★★★★★
()
Ответ на: комментарий от x3al

и получил проблему с XSS

Это да. Есть мысли что с этим сделать, исключительно в рамках RPC? Т.к. хочется сделать его универсальным, не только для браузера

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

Реализация хранилища сессий и юзеров не входит в RPC. Хранилище лишь должно реализовать интерфейс (checkSid(sid) -> boolean и проч.)

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

Буду рад выслушать любые предложения на этот счет )

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от x3al

Из стандартного работал только с JWT, там всё состояние в токене. Но сессии мне нравятся больше по ряду причин

Deleted
()
Ответ на: комментарий от Deleted

Реализация хранилища сессий и юзеров не входит в RPC

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

Буду рад выслушать любые предложения на этот счет )

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

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

Не, ну технически cookie — это всего лишь http-заголовок, никто не запретит использовать их вне браузера.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Как-то пытался, не осилил. Попробую

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.