Жизнеспособно ли асимметричное шифрование паролей с использованием JavaScript?

Question

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

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

Answer 1

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

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

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

Я бы предложил:

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

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

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

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

Answer 2

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

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

• srpjs
• Библиотека склепа Javascript

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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