Как правильно реализовать аутентификацию в SPA на Socket.io?

Question

[hbrmdc]

Socket.io, Express, PostgreSQL.
Веб-приложение доступно для просмотра как авторизованным пользователям, так и гостям. Все общение с сервером исключительно через wss. Просмотрев несколько статей о реализации аутентификации, я пришел к следующему.
Гость входит на сайт, происходит handshake, устанавливается соединение с сервером. Так как это не restful http соединение, а ws, то sid (session id) неавторизованным пользователям не нужен. Пока sidа нет, гостю доступен только ограниченный ряд функций (запросов в бд).
Гость вводит в форму авторизации логин и пароль, и жмет "войти". Пара логин-пароль отправляются по https. Так как имеется SSL сертификат, пароль отправляется без криптования. На сервере пароль криптуется SHA256, после чего происходит поиск по бд пары логин-криптованный_пароль соответствующий введенным данным. Если найдено соответствие, то генерируется sid (guid) и одноразовый ключ для ws (назовем его wskey). Оба ключа добавляются в в таблицу 'users' базы данных. Оба ключа отправляются клиенту. На клиенте sid сохраняется в куки с меткой HttpOnly, а wskey сразу же используется для отправки по ws. Серверный socket.io ищет в бд пользователя с этим wskey. Если нашел - то socket.io получает sid и как-то привязывает его к текущему соединению чтобы далее он прикреплялся ко всем запросам клиента к серверу.(1) Как это сделать? Как только sid сохранен в socket.io, wskey удаляется из бд.
То есть дальше клиент делает запросы без sidа или чего-то подобного, но socket.io его "помнит" и прикрепляет к каждому запросу sid, после чего отправляет его на дальнейшую обработку.
Пользователь сделал что хотел и закрыл браузер.

Пользователь снова открыл браузер и зашел на сайт.
Происходит HTTPS запрос, содержащий sid из куков. Сервер получил sid, нашел в бд в таблице пользователей строку с этим sidом и пошел по той же схемме - создать wskey, отправить клиенту и тд.

2. Если есть какие-то ошибки в написанном - пожалуйста, раскритикуйте)

Answer 1

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

пароль отправляется без криптования

без SSL пининга можно и покриптовать пароль, но это нужно далеко не всем.

На сервере пароль криптуется SHA256

не криптуется а хэшируется, и лучше хэшировать в BCRYPT (или SCRYPT даже но я бы еще подождал пару годиков)

после чего происходит поиск по бд пары логин-криптованный_пароль соответствующий введенным данным

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

var matches = true;
for(var i = 0; i < 1024; i++) {
    if (str1[i] !== str2[i]) matches = false;
}

почему так убого? потому что почитайте про тайминг атаки. Есть даже задокументированный случай с эксплуатацией тайминг атак для подбора коллизий к хэшам через интернет (то есть с задержками порядка 10 и более милисекунд)! Правда для этого надо сделать пару миллионов запросов ну да несуть.

Серверный socket.io ищет в бд пользователя с этим wskey

Еще хорошая идея - socker.io серверный спрашивает у сервера авторизации правильный wskey или нет но это если вы упарываетесь по масштабированию.

Если есть какие-то ошибки в написанном - пожалуйста, раскритикуйте)

В целом все верно. А если не загоняться такими вещами как разделение ответственности (мол у вас отдельно socket-io сервер и отдельно приложение) то можно еще и JWT юзать. Тогда нам вообще не надо ничего нигде хранить а проверять валидность можно по подписи токена. Да и реализация готовая есть.

Comments

[hbrmdc]

Благодарю, Сергей!
Так как. все-таки, вот это сделать?)
> **socket.io получает sid и как-то привязывает его к текущему соединению** чтобы далее он прикреплялся ко всем запросам клиента к серверу

[hbrmdc]

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

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

hbrmdc: JWT работает до безумия просто:

1) берем строку (в JWT это закадированный в base64 JSON, точнее две base64 JSON строки с разделителем в виде точки), вычисляем ее подпись (с приватным ключем высчитываем), отправляем на клиент.
2) когда пользователь делает запрос он присылает нам токен, если подпись верна - значит все хорошо. Подделать подпись можно только имея приватный ключ, который вы никогда никому не даете.

В этом случае ничего хранить сам токен не надо, а ID пользователя можно зашить в payload токена, и вообще какую-то несекьюрную но часто нужную инфу.

Есть сложные кейсы когда пользователю надо трекать все его сессии (например как у фэйсбуков и вконтактике) и тогда мы зашиваем ID сессии, в любом случае при аунтефикации лазать в базу не надо.

[hbrmdc]

На сколько я знаю, токен принято хранить в Cookies, чтобы js код веб-приложения не имел доступа к нему. А с JWT, я так понял, токен нужно сохранять в localStorage. Это же XSS уязвимость, верно?

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

hbrmdc: ну не совсем так, вы можете хранить JWT токен в куках, но это не удобно да и не нужно. Ну и само по себе хранение токена в local storage это не XSS уязвимость, просто если у вас есть XSS уязвимость то чувак может внедрить свой скрипт на страницу и стащить токен (и отправить его ajax-ом куда-нибудь). Но....

С куками вы делаете себя уязвивымими к CSRF атакам, с локал сторадж - к XSS атакам. Причем шутка в том что защититься нормально от обеих атак одновременно весьма сложно.

Но интересно еще вот что. От XSS защищаться нам надо всегда, а если нет кук - можно забить на CSRF. Вывод - можно хранить это дело в локал сторадже. в этом случае мы грустим только если злоумышленник крадет токен из браузера пользователя имея например физический доступ к его машине.

[hbrmdc]

звучит убедительно) Пошел изучать jwt. Если у вас есть какие-то полезные ссылки по всей этой теме или примеры кода - выложите их, пожалуйста)

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

hbrmdc: есть куча готовых реализаций, и под express-js, и под socket-io. Реализовывать самостоятельно не рекомендую, возьмите готовое.

Описанный вами алгоритм в принципе верен, а с JWT он просто в паре мест упрощается, так что...

[hbrmdc]

Ну так) если бы я нашел готовую реализацию, я бы тут не расписывал все это)

[hbrmdc]

находил только не очень популярные решения: https://github.com/auth0/socketio-jwt
смущает количество звезд.

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

hbrmdc: вы лучше на автора посмотрите - auth0 это весьма крутая организация на гитхабе. Да и 300+ звездочек это не 10+.

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

hbrmdc: ну и да, я сам ее использую на паре проектов, но не в восторге так как обычно делаю отдельный сервер авторизации (у меня основное приложение обычно на PHP пишется, socket-io только как шина данных между клиентом и сервером).

[hbrmdc]

добавьте, пожалуйста, к своему ответу информацию о JWT:
JSON Web Token (JWT) позволяет хранить в криптованом виде session id и прочую информацию о сессии в localStorage клиента, вместо того чтобы записывать эти данные где-либо на сервере.

Может кому-то пригодится. Из вашего ответа я это не понял. Вопрос о безопасности я еще изучу, но судя по всему это не глупые люди делали - наверняка все что можно уже предусмотрено.