Некоторые из парней здесь разрабатывают приложение, которое включает в себя некоторые «безопасные области», доступные при входе в систему. В прошлом форма входа в систему и последующие «безопасные» страницы представляли собой простой текст, передаваемый через 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!