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

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

без 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 юзать. Тогда нам вообще не надо ничего нигде хранить а проверять валидность можно по подписи токена. Да и реализация готовая есть.

Что делать если у пользователя отключены cookies и нельзя определить идентификатор сессии?

Сообщать ему что мол "чувак у тебя куки отключены!"

https://developer.mozilla.org/en-US/docs/Web/API/N...

1) session ID в любом случае придется передавать в каждом запросе, в заголовках, URI или куках - не важно. Самый простой способ - в URI но он же и не секьюрный... наверное... если перегенеривать часто то может и норм.
2) Какие собственно другие аспекты затрагивает? Поставьте обработку этого дела в onRequest и onResponse (http middleware) и там делайте с запросами ответами что хотите. Ваше приложение ничего даже не узнает. А переопределить сервис по работе с сессиями вы уж как-нибудь сможете.

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.