Некоторые из парней здесь разрабатывают приложение, которое включает в себя некоторые «безопасные области», доступные при входе в систему. В прошлом форма входа в систему и последующие «безопасные» страницы представляли собой простой текст, передаваемый через http, поскольку это приложение, которое выходит из использовать на общих серверах, где мало шансов использовать SSL (например, WordPress и тому подобное). Большинство людей просто пожали плечами, потому что это все, чего они ожидали - это вряд ли национальный банк.

Теперь мы думаем о написании следующей версии с использованием внешнего интерфейса JavaScript, с преимуществом загрузки всех изображений и CSS один раз, а затем записи HTML в DOM с помощью extJS (или, возможно, jQuery). Мы хотели бы зашифровать пользовательский ввод на клиенте перед отправкой на сервер, а затем расшифровать вывод на сервере в браузере, прежде чем отобразить его в HTML, чтобы обеспечить некоторую защиту пользователей. Есть также преимущества, которые можно получить, сократив время загрузки страницы, поскольку мы отправляем только сжатый JSON туда-сюда.

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

Для простоты...:

Пользователь подключается к странице входа по стандартному http, где браузер загружает пакет JavaScript, содержащий алгоритмы хеширования и шифрования (например, SHA-256 и AES).Пользователь входитusername, password а такжеsecret в форму входа.Браузер JavaScript отправляет хэшusername а такжеpassword на сервер через AJAX.secret хранится только в JavaScript и никогда не отправляется через Интернет.Сервер ищет хеш и получаетusername а такжеsecret из базы данных.Сервер отправляет хэш (тот же алгоритм, что и в браузере)username а такжеsecret вернуться в браузер.В браузере JavaScript создается хешusername а такжеsecret и сравнивает его с хэшем, отправленным обратно с сервера.Если они одинаковы, браузер JavaScript шифруетresponse с участиемsecret и отправляет сообщение обратно на сервер.Сервер расшифровывает сообщение с помощьюsecret найти ожидаемоеresponse и начинает новый сеанс.Последующие сообщения шифруются и дешифруются в обоих направленияхsecret.

Кажется, есть некоторые преимущества этого типа системы, но мы правы, думая:

Пользователь знает, что он разговаривает со своим сервером, если серверу удается создать хэшusername а такжеsecretдоказывая сервер знает и понимаетusername а такжеsecret.Сервер знает, что пользователь является подлинным, если ему удается зашифроватьresponse с участиемsecret, доказывая, что пользователь знаетsecret.Ни разуsecret когда-либо передается в виде простого текста, или это можно определитьsecret из хешаСниффер только когда-либо узнает «безопасный» URL и обнаружит сжатые хэши и шифрование в строке запроса. Если они отправляют запрос на неправильный URL-адрес, ответ не дается. Если им каким-то образом удается угадать соответствующий запрос, они все равно должны иметь возможность расшифровать его.

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