Использование сокета io через http, возможно ли безопасное протоколирование?

Question

Я создал игровой сервер в nodejs, используя socket io.

Я планирую удалить куки и куки-файлы из процедуры проверки подлинности и вместо этого использовать webstorage и клиент, который пытается войти в систему во время установления связи сокета io.

Однако, я использую http и отправляю идентификатор пользователя и пароль в открытом виде. Пожалуйста, помилуй меня! Я считаю, что использование https для всего соединения сокета добавит огромные накладные расходы, так как обновления отправляются каждые 100 мс. Мое текущее решение сработало для разработки, но я уверен, что это небезопасно.

Следует упомянуть, что я никогда не настраивал/не использовал https, поэтому исправьте меня, если я ошибаюсь в отношении накладных расходов, которые, как я знаю, являются очень обсуждаемой темой. Идеальное решение, как представляется, аутентифицирует пользователей по https-соединению, а затем передает информацию о состоянии игры через http, но я понятия не имею, как и как это можно достичь.

Наконец, у меня есть 2 варианта входа в систему. Я могу разрешить подключение сокета io на сервере и просто выпустить учетные данные журнала с клиента. Затем отключите их, если они неверны. Однако более чистым решением было бы отправить идентификатор пользователя и pw в заголовок http для рукопожатия, а затем аутентифицировать пользователя из промежуточного программного обеспечения socket.io, но я не уверен, что отправка данных таким образом будет безопасным.

Я не думаю, что это такая проблема ниши, что стандартная практика не существует, однако может быть просто использовать https. Я считаю, что нет никакой пользы для шифрования учетных данных пользователей, поскольку данные все еще можно отслеживать между клиентом и сервером. Любая информация о том, как я могу достичь этого, оценивается, Или просто укажите на меня в правильном направлении :)

Answer 1

Используйте одно соединение https для аутентификации входа и ответьте клиенту с уникальным маркером безопасности, если имя пользователя/пароль действует.

Используйте обычные http-соединения для остальной части диалога между клиентом и сервером. Включите маркер безопасности в диалоговом окне, если клиент запрашивает то, что требует проверки. Ваш клиент может хранить маркер безопасности в файле cookie, если вы найдете это удобным, поскольку токен может использоваться только для одного сеанса.

Имейте маркеры очистки сервера, когда клиент подписывается, или после того, как токен простаивает в течение некоторого периода времени.

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

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