Подтвердить что ты не робот

Существуют ли какие-либо асимметричные параметры шифрования для JavaScript?

Мне нужно передать некоторую конфиденциальную информацию по вызову JavaScript AJAX по незашифрованному каналу (HTTP, а не HTTPS).

Я хотел бы зашифровать данные, но шифрование на стороне JavaScript означает, что я выставляю ключ, который делает симметричное шифрование только упражнением в безопасности по неизвестности.

Есть ли асимметричное шифрование для JavaScript? Таким образом, я могу хранить секретный ключ сервера. (Я не беспокоюсь о безопасности Серверa > сообщений JavaScript, только о безопасности определенного сообщения JavaScript > Сервер)

4b9b3361

Ответ 1

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

Если злоумышленник может изменить трафик, он также сможет изменить script, который выполняет шифрование. Простейшей атакой было бы просто полностью удалить шифрование из script. Если у вас нет https, и man-in-the-middle возможно (что имеет место практически для каждого сценария), то у вас нет никакого контроля над html или javascript, который представлен до конца пользователь. Злоумышленник может полностью переписать ваш html-код и javascript, отключить шифрование, создать новые поля формы в вашей форме и т.д. Https является обязательным условием для безопасной связи на веб-канале.

Ответ 3

Являются ли сообщения серверa > JavaScript по HTTPS?

Если нет, ничто не мешает человеку посередине менять скрипты. Любое шифрование будет бесполезным, если код, который имеет доступ к незашифрованным данным, скомпрометирован.

Ответ 4

Я сделал это. Я использую это асимметричное RSA-шифрование на стороне клиента на стороне клиента, чтобы предотвратить учетные данные для входа в обычный текст через HTTP.

Цель состоит в том, чтобы предотвратить атаки повторного использования запроса на вход, основанные на сетевом обнюхивании. Конечно, это не так безопасно, как HTTPS, поскольку он не будет сопротивляться атакам "человек в середине", но этого может быть достаточно для локальных сетей.

Клиентское шифрование использует Travis Tridwell отличную работу, которая основана на JSBN. Веб-страница Travis также может генерировать частные и общедоступные ключи RSA (если вы слишком ленивы использовать openssl). Клавиши создаются в PKCS # 1 PEM формате. Я шифрую username+password+timeInMs+timezone, чтобы зашифрованное содержимое менялось при каждом входе в систему.

На стороне сервера мой код Java читает PEM файл PKCS # 1 с помощью Apache JMeter org.apache.jmeter.protocol.oauth.sampler.PrivateKeyReader:

PrivateKey pk = (new PrivateKeyReader("myPrivateKeyFile.pem")).getPrivateKey();

Затем я дешифрую зашифрованный контент, используя

byte[] enc = DatatypeConverter.parseBase64Binary(clientData);
Cipher rsa = Cipher.getInstance("RSA");
rsa.init(Cipher.DECRYPT_MODE, pk);
byte[] dec = rsa.doFinal(enc);
String out = new String(dec, "UTF8");

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

Ответ 5

асимметричный открытый ключ/закрытый ключ - единственный способ сделать это. Чтобы защитить от атак MIM, сервер может хэш-ключ с открытым паролем пользователей, тогда пользователь (в браузере) перекомпилирует хэш - если они совпадают, пользователь может быть уверен, что открытый ключ, отправленный с сервера, был подделан - это зависит от того, что только сервер и пользователь знают пароль пользователей.

PS Я хотел написать это как комментарий, поскольку это было бы более подходящим, чем ответ, но у меня недостаточно очков:)