Прежде всего, это НЕ повышает безопасность вашего приложения (при условии, что это веб-приложение).
Используйте SSL (или фактически TLS, который обычно называется SSL), это не очень дорого (измерьте время, которое вы используете, чтобы найти способ обойти его, и умножьте его с минимальной заработной платой, покупка сертификата выигрывает почти всегда) .
Почему это просто. TLS решает проблему (при использовании с купленными сертификатами, а не с собственной подписью), которая довольно велика в криптографии: откуда мне знать, что сервер, с которым я разговариваю, является сервером, с которым я разговариваю? Сертификаты TLS - это способ сказать: «Я, центр сертификации, которому доверяет ваш браузер, удостоверяет, что веб-сайт по адресу [url] имеет этот открытый ключ с соответствующим закрытым ключом, который (закрытый ключ) знает только сервер, посмотрите Я подписал свою подпись по всему документу, если кто-то изменил ее, вы можете увидеть ".
Без TLS любое шифрование становится бессмысленным, потому что, если я сижу рядом с вами в кафе, я могу заставить ваш ноутбук / смартфон думать, что я сервер, а вы MiTM (Man in the Middle). При использовании TLS ваш ноутбук / смартфон будет кричать «Ненадежное соединение», потому что у меня нет сертификата, подписанного центром сертификации, который соответствует вашему сайту. (Шифрование против аутентификации).
Отказ от ответственности: пользователи, как правило, нажимают прямо через эти предупреждения: «Ненадежное соединение? Что? Мне просто нужны мои фотографии котят! Добавить исключение Нажмите Подтвердите Нажмите ДА! Котята! "
Однако, если вы действительно не хотите покупать сертификат, все равно НЕОБХОДИМО реализовать хеширование JavaScript на стороне клиента (и для этого использовать стандартную библиотеку (SJCL), НИКОГДА НЕ РЕАЛИЗОВАТЬ КРИПТО САМОГО ).
Почему? Повторное использование пароля! Я могу украсть ваш сессионный cookie (который позволяет мне притвориться, что я - ваш сервер) без HTTPS (см. Firesheep). Однако, если вы добавите на свою страницу входа JavaScript, который перед отправкой хэширует ваш пароль (используйте SHA256 или, что еще лучше, используйте SHA256, отправляете им сгенерированный вами открытый ключ, а затем шифруете хешированный пароль, вы не можете использовать соль с этим), а затем отправляет хешированный / зашифрованный пароль на сервер. Перепишите хэш на вашем сервере с солью и сравните его с тем, что хранится в вашей базе данных (сохраните пароль следующим образом:
(SHA256(SHA256(password)+salt))
(сохранить соль как открытый текст в базе данных также)). И отправьте свой пароль так:
RSA_With_Public_Key(SHA256(password))
и проверьте ваш пароль следующим образом:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Поскольку ЕСЛИ кто-то прослушивает ваш клиент, он сможет войти в систему как ваш клиент (перехват сеанса), но он НИКОГДА не увидит пароль в виде открытого текста (если только он не изменит ваш пароль). javascript, однако, хакер Starbucks, вероятно, не будет знать, как / быть заинтересован в этом.) Таким образом, они получат доступ к вашему веб-приложению, но не к их электронной почте / facebook / и т.д. (для которого ваши пользователи, вероятно, будут использовать тот же пароль). (Адрес электронной почты будет либо их логином, либо будет найден в их профиле / настройках вашего веб-приложения).