Является ли асимметричное шифрование паролей с помощью JavaScript жизнеспособным?

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

Я понимаю, что SSL существует, но это не вопрос.

6
cryptography encryption javascript

6 ответов

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

JavaScript не может использоваться для обеспечения безопасности. Вы есть использовать HTTPS.

2

Шаг первый: не доверяйте людям в Интернете, я предложу слабый алгоритм, чтобы гарантировать, что я могу его сломать.

Шаг второй: Не создавайте свой собственный алгоритм или не реализуйте чужие в производственной системе, пока у вас нет PHD в области компьютерной безопасности

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

I предлагаю:

  1. пользователь вводит там пароль
  2. клиент запрашивает токен с сервера
  3. сервер возвращает уникальный случайный токен и сохраняет его в сеансе пользователей (с помощью cookie, хранящегося на сервере)
  4. клиент шифрует пароль + токен с помощью открытого ключа и передает его на сервер.
  5. сервер расшифровывает это, используя ваш закрытый ключ, и проверяет, что маркер соответствует этому сеансу, не был использован до и старше 30 секунд.
  6. сервер проверяет, что хэш пароля соответствует хэшу пароля пользователя, хранящемуся в хранилище данных.

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

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

У меня нет знаний о реализациях асимметричного шифрования, реализованного в javascript, но в этом подходе нет ничего принципиально небезопасного.

5

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

существует несколько реализаций Javascript SRP:

4

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

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

1

есть еще проблемы с этой моделью, потому что вы еще просто передать текст через связи. Без некоторой меры даты в процессе шифрования / дешифрования / сравнения вы все равно получаете потенциал для атаки воспроизведения.

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

1

Если вы начинаете с не аутентифицируемого сообщения, вы всегда рискуете человеком в середине.

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

кроме того, не храните это значение, но снова соль и гашиш.

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

0