Это старый вопрос, но я чувствовал необходимость высказать свое мнение по этому важному вопросу. Здесь так много дезинформации
ОП никогда не упоминал об отправке пароля в незашифрованном виде по HTTP - только по протоколу HTTPS, однако многие, похоже, отвечают на вопрос об отправке пароля по HTTP по какой-то причине. Это сказало:
Я считаю, что пароли никогда не должны храниться (не говоря уже о передаче) в виде простого текста. Это означает, что не хранится на диске или даже в памяти.
Люди, которые отвечают здесь, похоже, думают, что HTTPS - это серебряная пуля, а это не так. Это, безусловно, очень помогает, и его следует использовать в любом сеансе аутентификации.
Нет необходимости знать, что представляет собой оригинальный пароль. Все, что требуется, - это надежный способ создания (и надежного повторного создания) аутентификационного «ключа» на основе выбранного исходного текста. пользователем. В идеальном мире этот текст должен немедленно генерировать «ключ», хешируя его, используя необратимую соль. Эта соль должна быть уникальной для создаваемых учетных данных пользователя. Этот «ключ» будет тем, что ваши системы используют в качестве пароля. Таким образом, если ваши системы когда-либо будут скомпрометированы в будущем, эти учетные данные будут полезны только для вашей собственной организации, и нигде больше, где пользователь ленив и использовал тот же пароль.
Итак, у нас есть ключ. Теперь нам нужно очистить любой след пароля на клиентском устройстве.
Далее нам нужно получить этот ключ для ваших систем. Вы никогда не должны передавать ключ или пароль «в открытом виде». Даже не по HTTPS. HTTPS не непробиваем. На самом деле, многие организации могут стать доверенными MITM - не с точки зрения атаки, а с целью проверки трафика для реализации своих собственных политик безопасности. Это ослабляет HTTPS, и это не единственный способ, которым это происходит (например, перенаправление на атаки HTTP MITM). Никогда не думайте, что это безопасно.
Чтобы обойти это, мы хешируем ключ с одноразовым разом. Этот одноразовый номер уникален для каждой отправки ключа в ваши системы - даже для одного и того же удостоверения в течение одного сеанса, если вам нужно отправить его несколько раз. Вы можете отменить этот одноразовый номер, как только он поступит в ваши собственные системы, чтобы восстановить ключ аутентификации и аутентифицировать запрос.
В этот момент я бы необратимо хэшировал его в последний раз, прежде чем он будет постоянно храниться в ваших собственных системах. Таким образом, вы можете поделиться информацией о полномочиях с партнерскими организациями для целей единого входа и т. Д., В то время как возможность доказать, что ваша собственная организация не может выдать себя за пользователя. Лучшая часть этого подхода заключается в том, что вы никогда не передаете что-либо, сгенерированное пользователем, без его разрешения.
Проведите больше исследований, поскольку в этом есть нечто большее, чем я обнародовал, но если вы хотите обеспечить истинную безопасность своим пользователям, я думаю, что этот метод в настоящее время является наиболее полным ответом здесь.
TL; DR:
Использовать HTTPS.
Надежно хешируйте пароли, необратимо, с уникальной солью за пароль. Сделайте это на клиенте - не передавайте свой действительный пароль. Передача оригинального пароля пользователя на ваши серверы никогда не бывает «OK» или «Fine». Очистите все следы оригинального пароля.
Используйте nonce независимо от HTTP / HTTPS. Это гораздо более безопасно на многих уровнях. (Ответ на ОП).