Когда я хочу установить систему входа в систему, я всегда сравниваю MD5 данного пароля с его значением в таблице пользователей на стороне сервера.
Однако мой друг сказал мне, что «чистый» пароль может быть перехвачен сетевым программным обеспечением.
Итак, мой вопрос: это хорошая идея - хешировать пароль на стороне клиента? Это лучше, чем хеширование на стороне сервера?
В общем, твой друг прав. Но простое хеширование пароля на стороне клиента только просто лучше, чем отправка его в виде обычного текста на сервер. Кто-то, кто может прослушивать ваши пароли в виде обычного текста, безусловно, также может прослушивать хешированные пароли и использовать эти захваченные хеши для аутентификации на вашем сервере.
В этом отношении более безопасные протоколы аутентификации обычно проходят через ряд обручей, чтобы убедиться, что такая атака воспроизведения не может работать, обычно, позволяя клиенту выбрать кучу случайных битов, которые хешируются вместе с паролем. , а также передается на сервер в открытом виде.
На сервере:
На клиенте:
Поскольку серверу известна как собственная случайная информация, так и случайные биты клиента (он получил их в виде открытого текста), он может выполнять практически то же преобразование. Этот протокол гарантирует, что никто, слушающий в этом разговоре, не сможет использовать информацию позже для ложной аутентификации с использованием записанной информации (если не использовался очень слабый алгоритм ...), пока обе стороны генерируют разные «биты шума» каждый раз, рукопожатие выполняется.
Изменить. Все это подвержено ошибкам, утомительно и отчасти сложно исправить (читай: безопасно). Если возможно, подумайте об использовании реализаций протокола аутентификации, уже написанных знающими людьми (в отличие от меня! Вышесказанное взято из памяти книги, которую я прочитал некоторое время назад). Обычно вы действительно не хотите писать это самостоятельно.
Во-первых, это НЕ повышает безопасность вашего приложения (если это веб-приложение).
Используйте 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 / и т. д. (для которого ваши пользователи, скорее всего, будут использовать один и тот же пароль). (Адрес электронной почты будет либо их логином, либо будет найден в их профиле / настройках в вашем веб-приложении).
Вы, вероятно, в порядке, чтобы не беспокоиться об этом - как упоминает Дирк, даже если вы хешируете пароли, злонамеренный пользователь может быть в сети и видеть, что хэш отправляется, и может просто отправить тот же хеш самостоятельно.
Это немного лучше, так как не позволяет злоумышленнику узнать пароль, но поскольку они все еще могут войти в систему (или потенциально восстановить исходный пароль), это не так уж и полезно.
В общем, если вы беспокоитесь о безопасности паролей и данных вашего пользователя (а вы должны быть уверены!), Вам нужно использовать безопасный сервер SSL. Если вас это не беспокоит по какой-либо причине, вы можете не беспокоиться о хешировании; это просто безопасность через неясность.
Редактировать, август 2014 г .: Google все сильнее и сильнее подталкивает веб-сайты к везде переключайтесь на HTTPS, потому что защита самого соединения - единственный способ предотвратить атаки сетевого сниффинга. Попытки обфускации передаваемых данных будут только препятствовать, а не останавливать специализированного злоумышленника, и могут дать разработчикам опасное ложное чувство безопасности.
x пользователя и доступе к единой службе. Если учесть коллективный эффект, я бы сказал, что это намного лучше; потому что это предотвращает создание больших баз данных поиска паролей, используемых для перебора хешей с солью в нескольких службах. ИМО. Посмотрите, что AWS Cognito делает в клиенте, для справки.
- person f1lt3r; 06.09.2018
На самом деле я не согласен с тем, что хеширование на стороне клиента в этом случае более безопасно. Я думаю, это менее безопасно.
Вся суть хранения хэша пароля в вашей базе данных в отличие от реального пароля (или даже зашифрованного пароля) состоит в том, что математически невозможно получить исходный пароль из хэша (хотя теоретически возможно получить конфликтующий пароль). хэш-вход, сложность которого зависит от уровня безопасности алгоритма хеширования). Возможный вектор атаки здесь заключается в том, что если потенциальный злоумышленник каким-то образом скомпрометирует вашу базу данных хранилища паролей, он / она все равно не сможет получить исходные пароли ваших пользователей.
Если ваш механизм аутентификации отправляет хэш пароля, то в этом сценарии нарушения безопасности злоумышленнику не нужно знать настоящий пароль - он просто отправляет хэш, который у них есть, и, эй, престо, у них есть доступ к учетной записи определенного пользователя, и, соответственно, всю вашу систему. Это полностью лишает смысла хранить хешированный пароль в первую очередь!
По-настоящему безопасный способ сделать это - отправить клиенту одноразовый открытый ключ для шифрования пароля, а затем вы расшифруете и повторно хешируете его на стороне сервера.
Кстати, на этот вопрос, вероятно, будет больше ответов экспертов на Security StackExchange.
Обратите внимание, что защита паролей от третьих лиц - это еще не все.
Если речь идет о конфиденциальности (а в наши дни, когда это не так?), вы не хотите знать пароль. Вы не можете злоупотреблять или передавать то, чего у вас нет есть, поэтому и вы, и ваши клиенты можете спать лучше, если вы никогда не увидите их пароли в открытом виде.
Следовательно, хеширование / шифрование на стороне клиента имеет смысл.
x пользователей n служб, которые шифруют только на сервере. Если каждая служба уникальным образом хеширует пароль перед тем, как покинуть клиента, большая база данных межсервисных паролей становится намного меньше. Проверьте свой входной трафик AWS, посмотрите, что они делают. Вероятно, мой дорогой Ватсон.
- person f1lt3r; 06.09.2018
Это зависит от того, вы можете использовать хеширование на стороне клиента, но использование соли на стороне сервера будет невозможно.
взгляните на ссылку Шифрование пароля на стороне клиента
Недавно и GitHub, и Twitter объявили, что пароли хранятся во внутренних журналах. У меня это случалось случайно в отчетах об ошибках и других журналах, которые попали в splunk и т. Д. Для твиттера, если пароль Трампа был в журнале, это могло быть большим делом для администратора, чтобы «увидеть», для других сайтов, вероятно, не так большое дело, так как администраторы не будут в этом много пользы. Мы, админы, не любим видеть пароли.
Итак, вопрос в том, действительно ли хеширование должно происходить на стороне клиента для безопасности, но как мы можем защитить пароль до того, как он в конечном итоге будет хеширован и сравнен на стороне сервера, чтобы он каким-то образом не регистрировался.
Шифрование - неплохая идея, потому что разработчикам, по крайней мере, приходится преодолевать некоторые препятствия, и если вы обнаружите, что пароли попали в журналы, вы можете просто изменить ключ шифрования, уничтожить оригинал, и эти данные станут бесполезными. Еще лучше поворачивать клавиши каждую ночь, и это может значительно уменьшить окна.
Вы также можете использовать хэш в своей пользовательской записи. Утечка паролей будет хешированными паролями в виде простого текста. Сервер будет хранить хешированную версию хеша. Конечно, хеш становится паролем, но если у вас нет фотографической памяти, вы не запомните 60 символов bcyrpt. Солим с логином. Если вы могли собрать что-то о пользователе во время процесса входа в систему (при этом не раскрывая, что запись пользователя существует), вы также можете добавить это, создав более надежный хэш, который не может быть разделен между сайтами. Ни один человек посередине не сможет просто вырезать и вставить захваченный хэш между сайтами.
В сочетании с файлом cookie, который не отправляется обратно на сервер, возможно, вы что-то заметили. При первом запросе отправьте файл cookie клиенту с ключом, затем убедитесь, что этот файл cookie не возвращается в службу входа в систему, так что вероятность его регистрации в системе очень мала. Сохраните ключ в хранилище сеанса, а затем удалите его сразу после входа в систему или по истечении срока действия сеанса ... это требует состояния для вас, ребята, JWT, но, возможно, просто используйте для этого службу nosql.
Итак, в дальнейшем администратор сталкивается с одним из этих хешированных и зашифрованных паролей в splunk или инструменте сообщения об ошибках. Это должно быть бесполезно для них, поскольку они больше не могут найти ключ шифрования, и даже если они это сделают, им придется перебрать хеш-код. Кроме того, конечный пользователь не отправлял ничего открытого текста по строке, так что любому человеку в середине, по крайней мере, это тяжелее, и вы не можете просто перейти на другой сайт и войти в систему.
Я много работал над этим в последнее время, IRL есть две проблемы с хешем на стороне клиента / симметричным шифрованием, которые действительно убивают идею: 1. Вы должны вернуть соль на сервер КАК-ТО ... и чтобы зашифровать его на стороне клиента, вам понадобится пароль ... что противоречит цели. 2. Вы раскрываете свою реализацию хеширования (это не ОГРОМНАЯ сделка, поскольку большинство сайтов используют один из 3 или 4 алгоритмов хеширования), что упрощает атаку (просто нужно попробовать один, а не n).
В конечном итоге я перешел к асимметричному шифрованию на клиенте с использованием OpenPGP.js или аналогичного ... Это зависит от импортированного или сгенерированного на стороне клиента ключа на клиенте и сервера, отправляющего его открытый ключ. Только открытый ключ клиента может быть отправлен обратно на сервер. Это защищает от атак MIM и является таким же безопасным, как и устройство (в настоящее время я храню закрытый ключ клиента по умолчанию в localStore, это демонстрация).
ГЛАВНОЕ преимущество этого заключается в том, что мне никогда не нужно хранить данные пользователей / даже в незашифрованной памяти на моем сервере / хранилище данных (а закрытый ключ моего сервера физически отделен)
Основа этого заключалась в том, чтобы предоставить людям способ безопасного общения там, где HTTPS был ограничен (например, Иран / Северная Корея и т. Д.), А также просто забавный эксперимент.
Я далеко не первый, кто подумал об этом, http://www.mailvelope.com/ использует это
Если кто-то может видеть входящие и исходящие данные в вашем соединении, аутентификация вас не спасет. Вместо этого для суперсекретных вещей я бы сделал следующее.
Пароли предварительно хешируются на стороне клиента перед отправкой на сервер. (Сервер хранит другое хешированное значение этого хэша, отправленное из браузера).
Таким образом, атака посредника может позволить им отправить то же хешированное значение для входа в систему, что и они, но пароль пользователя не будет известен. Это помешает им попытаться использовать другие службы с такими же учетными данными для входа в другое место.
Данные пользователей зашифрованы и на стороне браузера.
Ах, значит, атака посредника получит зашифрованные данные, но не сможет их расшифровать без фактического пароля, используемого для входа в систему. (пароль пользователя сохраняется в DOM браузера при входе в систему). Таким образом, реальный пользователь увидит расшифрованное содержимое, а средний человек - нет. Это также означает, что никакое АНБ или другое агентство не сможет запросить у вас / компании / хостинг-провайдера расшифровку этих данных, поскольку они также не смогут это сделать.
Несколько небольших примеров обоих этих методов есть в моем блоге http://glynrob.com/javascript/client-side-hashing-and-encryption/
Эта идея хеширования на стороне клиента предназначена для защиты пользователя, а не вашего сайта. Как уже неоднократно упоминалось, простой текст или хешированные пароли имеют доступ к вашему сайту в равной степени. Вы не получаете преимущества в плане безопасности.
Но фактический текстовый пароль ваших пользователей должен быть известен только им. Знание того, что они выбрали в качестве пароля, - это информация, которая может быть использована против них на других сайтах и в других системах. Вы являетесь сайтом, ориентированным на клиентов, защищая их от того, что их выбор пароля будет обнаружен разработчиками вашего сервера или третьими лицами.
Учти это:-
Клиент отправляет серверу запрос «У меня есть пароль для проверки».
Сервер отправляет клиенту одноразовую случайную строку. Реалов
Клиент вставляет пароль пользователя в эту строку (на основе любых (переменных) правил, которые вы хотите применить).
Клиент отправляет строку на сервер, и если пароль в порядке, сервер входит в систему.
Если сервер получит еще один запрос на вход с использованием R $, пользователь выходит из системы, и учетная запись замораживается в ожидании расследования.
Очевидно, что будут приняты все другие (обычные) меры безопасности.
