11 ответов:
Это старый вопрос, но я почувствовал необходимость высказать свое мнение по этому важному вопросу. Здесь так много дезинформации
OP никогда не упоминал об отправке пароля в clear через HTTP - только HTTPS, но многие, похоже, по какой-то причине отвечают на вопрос об отправке пароля через HTTP. Тот сказал:
Я считаю, что пароли никогда не должны сохраняться (не говоря уже о передаче) в виде обычного текста. Это означает, что не хранится на диске, или даже в память.
люди, отвечающие здесь, похоже, думают, что HTTPS-это серебряная пуля, которой нет. Это, безусловно, очень помогает, однако, и должны быть использованы в любой аутентифицированной сессии.
на самом деле нет необходимости знать, что такое оригинальный пароль. все, что требуется, это надежный способ генерировать (и надежно повторно генерировать) аутентификационный "ключ" на основе исходного текста, выбранного пользователем. В идеальном мире этот текст должен немедленно генерировать "ключ", перемешивая его с помощью необратимой соли. Эта соль должна быть уникальной для создаваемых учетных данных пользователя. Этот "ключ" будет тем, что ваши системы используют в качестве пароля. Таким образом, если ваши системы когда-либо будут скомпрометированы в будущем, эти учетные данные будут полезны только для вашей собственной организации, и нигде больше, где пользователь был ленив и использовал тот же пароль.
Итак, у нас есть ключ. Теперь нам нужно очистить любые следы пароля на клиентах устройство.
Далее нам нужно получить ключ для вашей системы. Вы никогда не должны передавать ключ или пароль "в чистом виде". Даже не через HTTPS. HTTPS не является непроницаемым. Фактически, многие организации могут стать доверенными MITM-не с точки зрения атаки, а для выполнения проверок трафика для реализации своих собственных политик безопасности. Это ослабляет HTTPS, и это не единственный способ, которым это происходит (например, перенаправляет на атаки HTTP MITM). Никогда не предполагайте, что это так безопасный.
чтобы обойти это, мы хешируем ключ, как только сейчас. Этот nonce уникален для каждой отправки ключа в ваши системы-даже для одних и тех же учетных данных во время одного сеанса, если вам нужно отправить его несколько раз. Вы можете отменить этот nonce, как только он поступит в ваши собственные системы, чтобы восстановить ключ аутентификации и аутентифицировать запрос.
в этот момент я бы необратимо хэшировать его в последний раз, прежде чем он будет постоянно храниться в вашем собственном системный. Таким образом, вы можете поделиться солью учетных данных с партнерскими организациями для целей SSO и т. п., В то же время имея возможность доказать, что ваша собственная организация не может олицетворять пользователя. Лучшая часть этого подхода заключается в том, что вы никогда не делитесь ничем, созданным пользователем без его разрешения.
сделайте больше исследований, так как есть больше, чем даже я разглашал, но если вы хотите обеспечить истинную безопасность для своих пользователей, я думаю, что этот метод в настоящее время является самым полный ответ здесь.
TL; DR:
использовать HTTPS. Надежно хэш-пароли, необратимо, с уникальной солью на пароль. Сделайте это на клиенте - не передавайте свой фактический пароль. Передача исходного пароля пользователя на ваши серверы никогда не будет" ОК "или"отлично". Очистите все следы исходного пароля. Используйте nonce независимо от HTTP / HTTPS. Это гораздо более безопасно на многих уровнях. (Ответ на ОП).
Так как это по HTTPS, это определенно просто отлично, чтобы отправить пароль без хэширования (по HTTPS это не открытый текст). Кроме того, если ваше приложение зависит от HTTPS, чтобы сохранить его содержимое в безопасности, то бесполезно хэшировать пароль перед отправкой его по HTTPS (т. е. если злоумышленник может расшифровать данные на проводе, вы все равно привинчены)
нет, на самом деле это будет уязвимость. Если злоумышленник может получить хэш из базы данных, то он может использовать его для аутентификации без необходимости взломать его. Ни при каких обстоятельствах пользователь или злоумышленник не должен иметь возможность получить пароль хэшей.
весь смысл хэширования паролей заключается в добавлении дополнительного уровня безопасности. Если злоумышленник может получить хэш и соль из базы данных с помощью SQL-инъекции или небезопасной резервной копии, он должен найти простой текст, грубо заставляя его. Джон Потрошитель обычно используется для взлома соленых хэшей паролей.
Не использование https является нарушением OWASP Top 10:A9-Недостаточная Защита Транспортного Уровня
EDIT: Если в вашей реализации вы вычисляете
sha256(client_salt+plain_text_password)а затем вычислить еще один хэш на стороне сервераsha256(server_salt+client_hash)тогда это не серьезная уязвимость. Тем не менее, он по-прежнему восприимчив к подслушиванию и повтор запроса. Таким образом, это все еще явное нарушение WASP A9. Однако это все еще использует дайджест сообщения в качестве уровня безопасности.самое близкое, что я видел для замены https на стороне клиента-это Диффи-Хеллман в обмен ключами в javascript. Однако это предотвращает активные атаки MITM и, таким образом, до технической стороны является нарушением OWASP A9. Авторы кода согласны с тем, что это не полная замена HTTPS, однако это это лучше, чем ничего и лучше, чем система хэширования на стороне клиента.
отправка хэша по проводу полностью разрушает цель хэша, потому что злоумышленник может просто отправить хэш и забыть о пароле. В двух словах, система, которая использует хеш в открытом тексте, широко открыта и может быть скомпрометирована не более чем сетевым нюханием.
пароль в открытом виде показывать никогда (даже при использовании HTTPS) не покидайте клиент. Он должен быть необратимо хэширован перед выходом из клиента, так как сервер не должен знать фактический пароль.
хэширование затем передача решает проблемы безопасности для ленивых пользователей, которые используют один и тот же пароль в нескольких местах (я знаю, что делаю). Однако это не защищает ваше приложение как хакера, который получил доступ к базе данных (или каким-либо другим способом смог получить его руки на хэш), поскольку хакер может просто передать хэш и заставить сервер принять его.
чтобы решить эту проблему, вы, конечно, можете просто хэшировать хэш, который получает сервер, и называть его днем.
мой подход к проблеме в веб-приложении на основе сокетов, которое я создаю, заключается в том, что при подключении к клиенту сервер генерирует соль (случайную строку, которую нужно добавить перед хэшированием) и сохраняет ее в переменной сокетов, а затем передает этот хэш клиенту. Клиент берет пароль пользователя, хэширует его, добавляет соль с сервера и хэширует все это, прежде чем передавать его на сервер. Затем он отправляется на сервер, который сравнивает этот хэш с хэшем (хэш в DB + salt). Насколько я знаю, это хороший подход, но, честно говоря, я не много читал по этой теме, и если я ошибаюсь в чем-то, я хотел бы быть исправленным :)
Use HTTP Digest-он защищает пароль даже через http (но лучше всего использовать HTTP digest через https)
Википедия:
Проверка подлинности http digest access является одним из согласованных методов, которые веб-сервер может использовать для согласования учетных данных с веб-пользователем (с использованием протокола HTTP). Дайджест-проверка подлинности предназначена для замены незашифрованного использования базовой проверки подлинности доступа, что позволяет безопасно устанавливать удостоверение пользователя без необходимости отправки пароля в открытом виде по сети. Дайджест-аутентификация-это в основном применение криптографического хэширования MD5 с использованием значений nonce для предотвращения криптоанализа.Ссылка:http://en.wikipedia.org/wiki/Digest_access_authentication
Если вы хотите увидеть" реальную жизнь", вы можете посмотреть на phpMyID-провайдер PHP openid, который использует HTTP digest authentication http://siege.org/phpmyid.php
.. или вы могли бы начать с PHP auth samples at http://php.net/manual/en/features.http-auth.php
http digest rfc:http://www.faqs.org/rfcs/rfc2617
из моих тестов все современные браузеры поддерживают его...
Если вы хотите заменить пароль с открытым текстом по HTTPS хэшированным паролем по HTTP, то вы просите о проблемах. HTTPS генерирует случайный, общий ключ транзакции при открытии канала связи. Это трудно взломать, поскольку вы в значительной степени ограничены грубым принуждением общего ключа, используемого для (относительно) краткосрочной транзакции. В то время как ваш хэш можно просто понюхать, снять в автономном режиме и посмотреть в Радужном столе или просто грубо заставить над большим количеством время.
однако базовая обфускация пароля на стороне клиента (не хэш), отправленная по HTTPS, имеет некоторое значение. Если я не ошибаюсь эта техника используется некоторыми банками. Цель этого метода не для защиты от перехвата пароля по сети. Скорее, это для того, чтобы остановить пароль от использования для немых инструментов шпионажа и плагинов браузера, которые просто захватывают каждый запрос HTTPS GET/POST, который они видят. Я видел файл журнала, захваченный с вредоносного веб-сайта, который был 400 МБ случайных транзакций GET/POST, захваченных из пользовательских сеансов. Вы можете себе представить, что веб-сайты, которые использовали только HTTPS, будут отображаться с четкими текстовыми паролями в журнале, но веб-сайты с очень простой обфускацией (ROT13) также будут отображаться с паролями, которые не сразу используются.
отказ от ответственности: я не растягиваю эксперта по безопасности - и я отправляю сообщение с Надежда что другие будут критиковать мою позицию как чрезмерно осторожную или улучшаемую, и я буду учиться на ней. С учетом сказанного, я просто хочу подчеркнуть, что хеширование, когда оно покидает ваш клиент, не означает, что вам не нужно хэшировать на бэкэнде, прежде чем помещать его в базу данных.
а как
сделать и так:
хэширования поездка над помогает покрыть уязвимости транспорта, если соединение SSL скомпрометировано, они все еще не могут видеть необработанный пароль. Это не будет иметь значения с точки зрения возможности олицетворять авторизованных пользователей, но это защитит ваших пользователей от чтения их паролей в ассоциации с их электронной почтой. Большинство людей не следуют рекомендациям и используют один и тот же пароль для многих своих учетных записей, поэтому это может быть серьезной уязвимостью для ваших посетителей.
Если кто-то, так или иначе удалось прочитать пароли из базы данных (это происходит, думаю, SQL-инъекция), они все равно не смогут выполнять привилегированные действия, олицетворяющие пользователей через мой API. Это связано с асимметрией хэша; даже если они знают хэш, хранящийся в вашей БД, они не будут знать исходный ключ, используемый для его создания, и это то, что ваше промежуточное программное обеспечение auth использует для аутентификации. Именно поэтому вы всегда должны солить свое хэш-хранилище.
конечно, они могли бы сделать много другой ущерб, если у них была свобода действий, чтобы прочитать то, что они хотят от вашей базы данных.
Я просто хочу подчеркнуть здесь, что если вы решите хэшировать ключ перед отъездом от ваших клиентов, этого недостаточно - хеширование бэкэнда, ИМО, гораздо важнее, и именно поэтому: если кто-то перехватывает трафик от вашего клиента, то они увидят содержимое
Если вы подключены к серверу https, поток данных между сервером и браузером должен быть зашифрован. Данные только простой текст перед отправкой и после получения. статья в Википедии
на самом деле было бы менее безопасно хэшировать пароль и отправлять его по незашифрованному каналу. Вы будете выставлять свой алгоритм хэширования на клиенте. Хакеры могли просто понюхать хэш пароля, а затем использовать его для взлома позже.
используя HTTPS, вы не позволяете хакеру получить пароль из одного источника, так как HTTPS использует два канала, оба зашифрованы.
разве SSL / TLS не заменяет nonce? Я не вижу дополнительной ценности этого, так как SSL/TLS также защищает от атак воспроизведения.
Comments