Библиотека шифрования на стороне клиента

При общении всегда следует использовать безопасный способ связи. Например, HTTPS. И при работе с сокетами вы можете использовать безопасность веб-сокетов (WSS), в которой соединение зашифровано через TLS / SSL.

Если вы используете HTTPS и WSS, ваше общение уже зашифровано с использованием SSL, поэтому вам не следует беспокоиться о шифровании данных на стороне клиента, если это не является абсолютно необходимым.

bcrypt - это функция хеширования паролей, разработанная Нильсом Прово и Дэвидом Мазьером на основе шифра Blowfish. Хеширование необратимо. После того, как вы создали хэш, вы не сможете его расшифровать. Если вам нужно расшифровать, вы можете использовать AES256. Для получения дополнительной информации об AES вы можете начать с ВИКИПЕДИЯ

bcrypt - это алгоритм, который может быть реализован на любом языке, причем bcrypt (пакет npm) - это реализация алгоритма.

Талха уже ответил на ваш вопрос, но я просто предоставлю некоторые подробности.

What is the risk factor in having server-client communication where the exchange of information between them is never encrypted.

Теоретически каждый компьютер в сети, через который проходят данные, может их прочитать. Реальность еще хуже - внедренная в настоящее время защищенная передача Wi-Fi WPA2 может быть перехвачена.

Should I bother encrypting the information.

Перефразируем ваш вопрос: следует ли передавать информацию в зашифрованном виде? Да, нет причин не делать этого (кроме случаев, когда вы ленитесь учиться этому). Использование HTTPS гарантирует конфиденциальность и целостность (что никто не испортит ваши данные, и вы говорите на правильном сервере). HTTPS стал доступен сегодня. Существуют даже бесплатные службы сертификации (например, letsencrypt.org).

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

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

If I should bother encrypting the information on the client before transmission, what is the best client-side encryption library to do so (in a React context, if that makes a difference).

Я использовал библиотеку CryptoJS для шифрования JS (я использовал ее на стороне сервера, но считаю, что это не имеет значения).

Also, how would I go about sending encrypted server information to the client, which decrypts it with a different technology than bcrypt; or, should I use entirely client-side encryption, while the server just reads and writes the encrypted information with no knowledge of its contents.

Просто - используйте TLS (HTTPS). В определенный момент вам нужно доверять своему серверу. На самом деле вы все равно должны защищать свои данные (например, пароли).

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