Стоит ли хэшировать пароли на стороне клиента

прежде всего, это делает не улучшить безопасность приложения (если это приложение).

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

почему это просто. TLS решает проблему (при использовании с купленными сертификатами, а не самоподписанными), которая довольно большой в криптографии: как я знаю, что сервер, с которым я разговариваю, - это сервер, с которым я думаю, что я разговариваю? Сертификаты TLS-это способ сказать:"Я, центр сертификации, которому доверяет Ваш браузер, удостоверяет, что веб-сайт по адресу [url] имеет этот открытый ключ с соответствующим закрытым ключом, который (закрытый ключ) знает только сервер, посмотрите, я подписал свою подпись по всему документу, если кто-то изменил его, вы можете увидеть".

без TLS любое шифрование становится бессмысленным, потому что если Я сижу рядом с вами в кафе, я могу заставить ваш ноутбук/смартфон думать, что я сервер и MiTM (человек в середине) вы. С помощью TLS ваш ноутбук / смартфон будет кричать "ненадежное соединение", потому что у меня нет сертификата, подписанного центром сертификации, который соответствует вашему сайту. (Шифрование и аутентификация).

отказ от ответственности: пользователи, как правило, нажимают прямо через эти предупреждения: "ненадежное соединение? Что? Я просто хочу мои фотографии котят! Добавить Исключение кликподтвердитьклик УРА! Котята!"

, Если вы действительно не хотите покупать сертификат, все равно реализуйте хеширование javascript на стороне клиента (и использовать библиотеку standford (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 / и т. д. (за что ваши пользователи будут использовать тот же пароль). (Адрес электронной почты будет либо их loginname или будет найден в их профиле/настройках на вашем веб-приложении).

вы, вероятно, в порядке, чтобы не беспокоиться об этом - как упоминает Дирк, даже если вы хэшируете пароли, вредоносный пользователь может быть в сети и видеть, что хэш отправляется, и может просто отправить тот же самый хэш.

Это немного лучше, в том, что он предотвращает злоумышленника от зная, что пароль, но так как они все еще могут войти в систему (или потенциально восстановить исходный пароль), что не так полезно.

В общем, если вы беспокоитесь о безопасности паролей и данных вашего пользователя (и вы должны быть!), вы хотите использовать безопасный сервер SSL. Если это не беспокоит вас по какой-либо причине, вы можете также не беспокоиться о хешировании; это просто безопасность через неясность.

---

Редактировать Август 2014: Google толкает все более и более сильно для веб-сайтов, чтобы переключиться на HTTPS везде, потому что обеспечение безопасности самой связи является единственным способ предотвращения сетевых атак обнюхивания. Попытки запутать передаваемые данные будут только мешать, а не останавливать выделенного злоумышленника и могут дать разработчикам опасное ложное чувство безопасности.

на самом деле я не согласен, что хэширование на стороне клиента является более безопасным в этом случае. Я думаю, что это менее безопасно.

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

Если ваш механизм аутентификации отправляет хэш пароля, то в этом сценарии нарушения безопасности злоумышленнику не нужно знать реальный пароль - они просто отправляют хэш, который у них есть, и hey presto, у них есть доступ к определенной учетной записи пользователей, а также расширение, вся ваша система. Этого полностью теряется смысл хранить хэш пароля в первую очередь!

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

кстати, этот вопрос, вероятно, получит больше экспертных ответов на безопасность StackExchange.

Это зависит, вы можете использовать хэширование на стороне клиента, но соль на стороне сервера будет невозможна.

посмотрите на ссылку шифрование пароля на стороне клиента

в последнее время я много работаю над этим, IRL есть две проблемы с хэшем на стороне клиента / симметричного шифрование с действительно убивают идею: 1. Вы должны как-то вернуть соль на сервер...и для его шифрования на стороне клиента, вам понадобится пароль...что разрушает цель. 2. Вы выставляете свою реализацию хэширования (не огромное дело, поскольку большинство сайтов используют один из 3 или 4 хэширующих Альго), что упрощает атаку (так как просто нужно попробовать один, а не северный.)

то, что я в конечном итоге пошел на асимметричное шифрование на клиенте с помощью OpenPGP.js или подобное... Это зависит от импортированного или созданного на стороне клиента ключа на клиенте и сервере, отправляющем его открытый ключ. Только открытый ключ клиента может быть отправлен обратно на сервер. Это защищает от атак MIM и так же безопасно, как и устройство (в настоящее время я храню закрытый ключ клиента по умолчанию в localStore, это демо).

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

основании этого был предоставить людям возможность безопасно обмениваться данными по протоколу https, где было ограничено (напр., Иран / КНДР УВД...), а также просто забавный эксперимент.

Я далеко не первый, кто думает об этом,http://www.mailvelope.com/ использует это

Если кто-то может видеть данные В и из вашего соединения, то аутентификация не спасет вас. Вместо этого я бы сделал следующее для супер секретных вещей.

пароли предварительно хэшируются на стороне клиента перед отправкой на сервер. (Сервер хранит другое хэшированное и соленое значение этого хэша, отправленного из браузера).

таким образом, атака среднего человека может позволить им отправлять одно и то же хэшированное значение для входа в систему, но пароль пользователя не будет известен. Это остановит их попытки другие службы с такими же учетными данными для входа в другое место.

данные пользователей шифруются и на стороне браузера.

Ах, так что атака среднего человека получит зашифрованные данные, но не сможет расшифровать их без фактического пароля, используемого для входа в систему. (пароль пользователя хранится в DOM в браузере при входе в систему). Таким образом, реальный пользователь увидит расшифрованное содержимое, но средний человек не сможет. Это также означает, что любое АНБ или другое агентство не сможет попросите вас/компанию / хостинг-провайдера расшифровать эти данные, поскольку это было бы невозможно для них.

некоторые небольшие примеры обоих этих методов находятся в моем блоге http://glynrob.com/javascript/client-side-hashing-and-encryption/

недавно и GitHub, и Twitter объявили, что пароли хранятся во внутренних журналах. У меня это произошло непреднамеренно в отчетах об ошибках и других журналах, которые нашли свой путь в splunk и т. д. Для twitter, если пароль Трампа был в журнале, это может быть большое дело для администратора, чтобы "увидеть", для других сайтов, вероятно, не так важно, как администраторы не будут иметь много пользы для него. Независимо от того, как администраторы нам не нравится видеть пароли мы.

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

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

вы также можете хэшировать хэш в своей записи пользователя. Просочившиеся пароли будут хэшироваться простыми текстовыми паролями. Сервер будет хранить хэшированную версию хэша. Конечно, хэш становится паролем, но если у вас нет фотографической памяти, вы не запомните 60 символов bcyrpt. Соль с именем пользователя. Если вы можете собрать что-то о пользователе во время процесса входа в систему (не раскрывая, что запись пользователя существует), вы можете посолить это также создает более надежный хэш, который не может быть разделен между сайтами. Ни один человек в середине не сможет просто вырезать и вставлять захваченный хэш между сайтами.

объедините с файлом cookie, который не будет отправлен обратно на сервер, и вы можете быть на что-то. При первом запросе отправьте файл cookie клиенту с ключом, а затем убедитесь, что файл cookie не возвращается в службу входа в систему, поэтому вероятность его регистрации невелика. Храните ключ в хранилище сеансов, а также затем удалите его сразу после входа в систему или когда сеанс истек... для этого требуется состояние для вас, ребята JWT, но, возможно, просто используйте для этого службу nosql.

таким образом, по дороге администратор сталкивается с одним из этих хэшированных и зашифрованных паролей в splunk или инструмент отчетности об ошибках. Это должно быть бесполезно для них, поскольку они больше не могут найти ключ шифрования, и даже если бы они это сделали, им пришлось бы перебирать хэш. Кроме того, конечный пользователь не отправил ничего открытого текста вдоль линии, поэтому любой человек в середине, по крайней мере, имеет более трудное время, и вы не можете просто перейти на другой сайт и войти в систему.

обратите внимание, что сохранение паролей в безопасности от третьих сторон-это еще не все.

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

поэтому хэширование / шифрование на стороне клиента имеет смысл.

рассматривайте это:-

клиент отправляет запрос на сервер "у меня есть пароль для проверки".

сервер отправляет клиенту только одну случайную строку. R$

клиент вставляет пароль пользователя в эту строку (на основе любых (переменных) правил, которые вы хотите применить).

клиент отправляет строку на сервер и если пароль ОК, сервер регистрирует пользователя.

если сервер получит другой запрос на вход с помощью R$, пользователь выйдет из системы и учетная запись заморожен в ожидании расследования.

очевидно, что все другие (нормальные) меры безопасности будут приняты.

можно рассмотреть такие сайты, как amazon.com и linkedin.com . Эти сайты не хэшируются на стороне клиента. (По состоянию на апрель 2018 года).

можно использовать любые сторонние библиотеки, такие как

jCryption

шифрование на стороне клиента с помощью jCryption