В Интернете существует множество сайтов, которым требуется информация для входа в систему, и единственным способом защиты от повторного использования пароля является «обещание», что пароли хешируются на сервере, что не всегда верно.
Поэтому мне интересно, насколько сложно создать веб-страницу, которая хэширует пароли на клиентском компьютере (с Javascript), прежде чем отправлять их на сервер, где они будут повторно хэшироваться? Теоретически это не дает никакой дополнительной безопасности, но на практике это может быть использовано для защиты от «мошеннических сайтов», которые не хэшируют ваш пароль на сервере.
javascript
security
client-relations
hashing
client-side
Мартин Фиксман
источник
источник
clearэто просто математическая мастурбация в этой точке. Я должен был исправить систему, которую я унаследовал, которая была разработана точно так, как вы и ОП описываете, ее постоянно взламывали подростки с Wireshark. Мы заблокировали его, только когда включилиREALшифрование, зашифровали и подписали все полезные данные на сервер и с сервера, манипулирование учетной записью прекратилось и после этого больше никогда не происходило.Ответы:
Почему не используется? Потому что это много дополнительной работы для нулевого усиления. Такая система не будет более безопасной. Он может быть даже менее безопасным, поскольку создает ложное впечатление о большей безопасности, заставляя пользователей применять менее безопасные методы (такие как повторное использование паролей, парольные словари и т. Д.).
источник
Как именно это защищает вас? Похоже, все, что вы хотите сделать, это хешировать хешированный пароль, который является бессмысленным. Потому что хешированный пароль станет паролем.
Как насчет того, чтобы не использовать один и тот же пароль для более чем одного сайта. Теоретически веб-сайты хэшируют пароль, чтобы предотвратить доступ к вашей учетной записи, если ОНИ взломаны. Использовать один и тот же пароль для нескольких сайтов просто глупо.
Если вы использовали javascript, все, что нужно «хакеру» - это использовать тот же метод для hashed-hashed-passwords. Как только у вас есть хешированная информация, нужно просто вычислить пароль-> тот же хеш в базе данных, который является фактором, препятствующим доступу к учетной записи.
источник
Потому что это мало что даст. Причина хэширования в том, что если ваша база данных будет взломана, у хакера не будет списка действительных паролей, только хэши. Поэтому они не могли выдать себя за любого пользователя. Ваша система не знает пароля.
Безопасный приходит от сертификатов SSL плюс некоторая форма аутентификации. Я хочу, чтобы мои пользователи указали пароль, чтобы из него можно было вычислить хеш.
Кроме того, алгоритм хеширования будет находиться на сервере в более безопасной области. Размещая его на клиенте, довольно просто получить исходный код для Javascript, даже если он содержит скрытые ссылочные файлы сценариев.
источник
Решение проще, чем это. Клиентские сертификаты. Я создаю сертификат клиента на моей машине. Когда я регистрируюсь на веб-сайте, мы делаем рукопожатие, используя мой сертификат клиента и сертификат сервера.
Пароли не обмениваются, и даже если кто-то взломает базу данных, все, что у них будет, - это открытый ключ моего клиентского сертификата (который должен быть засолен и зашифрован сервером для дополнительного уровня безопасности).
Сертификат клиента может храниться на смарт-карте (и загружаться в безопасное онлайн-хранилище с использованием мастер-пароля).
Прелесть всего этого в том, что он устраняет концепцию фишинга ... вы никогда не вводите пароль на веб-сайт, вы просто рукопожатие с этим веб-сайтом. Все, что они получают, это ваш открытый ключ, который бесполезен без закрытого ключа. Единственной уязвимостью является обнаружение столкновения во время рукопожатия, и это может сработать только один раз на одном сайте.
Microsoft попыталась предоставить что-то подобное в Windows с помощью Cardspace, а затем представила это как открытый стандарт. OAuth чем-то похож, но опирается на посредническую «эмиссионную сторону». Инфокарты с другой стороны могут быть выпущены самостоятельно. Это реальное решение проблемы с паролями ... удаление паролей в целом.
OAuth - это шаг в правильном направлении.
источник
большинство ответов здесь, кажется, полностью упускают из виду хеширование пароля на стороне клиента.
Дело не в том, чтобы защитить доступ к серверу, на который вы входите, поскольку перехват хэша не более безопасен, чем перехват пароля в виде простого текста.
Суть в том, чтобы действительно защитить пароль пользователя , который обычно гораздо более ценен, чем доступ для входа на отдельный сайт, так как большинство пользователей повторно используют свой пароль для нескольких сайтов (они не должны этого делать, но реальность такова, что они делают это, его не следует отменять). ).
ssl отлично подходит для защиты от митм-атак, но если приложение входа в систему скомпрометировано на сервере, ssl не защитит ваших пользователей. если кто-то злонамеренно получил доступ к веб-серверу, он, вероятно, сможет перехватывать пароли в виде простого текста, поскольку в большинстве случаев пароли хешируются только сценарием на сервере. тогда злоумышленник может попробовать эти пароли на других (обычно более ценных) сайтах, используя похожие имена пользователей.
безопасность - это глубокая защита, а хеширование на стороне клиента просто добавляет еще один уровень. помните, что хотя защита доступа к вашему сайту важна, защита секретности паролей ваших пользователей гораздо важнее из-за повторного использования паролей на других сайтах.
источник
Это определенно возможно, и на самом деле вам не нужно ждать сайт.
Посмотрите на SuperGenPass . Это букмарклет.
Он просто распознает поля паролей, объединяет то, что вы вводите с доменом веб-сайта, хеширует его, несколько корректирует его, чтобы получить только «допустимые» символы в пароле, и только тогда ваш хэшированный пароль отправляется по проводам.
Таким образом, используя домен сайта, вы получаете уникальный пароль для каждого сайта, даже если вы всегда используете один и тот же пароль.
Он не очень безопасен (base64-MD5), но вы отлично распространяете реализацию на основе sha-2, если хотите.
Единственным недостатком является изменение домена, в этом случае вам нужно будет попросить веб-сайт сбросить пароль, потому что вы не сможете восстановить его самостоятельно ... хотя это случается не часто, поэтому я считаю это приемлемый компромисс.
источник
passwordи / или SHA-256passwordс какой-то солью, которая известна клиенту, человек в среднем прикреплении может захватить его.Мне нравится ответ X4u, но, на мой взгляд, что-то вроде этого должно быть интегрировано в браузер / html-спецификацию - так как на данный момент это только половина ответа.
Вот проблема, которую я имею как пользователь - я понятия не имею, будет ли мой пароль хешироваться на другом конце при сохранении в базе данных. Строки между мной и сервером вполне могут быть зашифрованы, но я понятия не имею, что происходит с моим паролем, когда он достигает места назначения - он может храниться в виде простого текста. Парень администратора базы данных может в конечном итоге продать базу данных, и, прежде чем вы узнаете об этом, весь мир знает ваш пароль.
Большинство пользователей повторно используют пароли. Не технические люди, потому что они не знают лучше. Специалисты, потому что как только вы получите 15-й пароль или около того, у большинства людей не будет шансов запомнить их, если они не запишут их (что, как мы все знаем, также является плохой идеей).
Если бы Chrome или IE или что-либо еще, что я использовал, мог сказать мне, что поле пароля мгновенно будет хешироваться на стороне клиента с использованием соли, сгенерированной сервером, и эффективно изолировать сам пароль - тогда я знал бы, что как пользователь я мог бы повторно использовать пароль с меньшим риском. Я все еще хотел бы, чтобы зашифрованные каналы, а также я не хотел, чтобы во время передачи происходил сбрасывание карнизов.
Пользователь должен знать, что его пароль даже недоступен для отправки на сервер - только хеш. В настоящее время, даже используя решение X4U, они не могут знать, что это так, потому что вы не знаете, используется ли эта технология.
источник
Я думаю, что это хороший метод для использования при создании чего-то вроде фреймворка, CMS, программного обеспечения для форумов и т. Д., Где вы не контролируете серверы, на которых оно может быть установлено. То есть, ДА, вы всегда должны рекомендовать использовать SSL для входа в систему и входа в систему, но некоторые сайты, использующие ваш framework / cms, не будут иметь его, поэтому они все равно могут извлечь из этого пользу.
Как уже отмечали другие, преимущество здесь состоит не в том, что атака MITM не может позволить кому-то другому войти в этот конкретный сайт, как у вас, а в том, что злоумышленник не сможет использовать то же имя пользователя и пароль для войдите в десятки других сайтов, на которых у вас есть аккаунты.
Такая схема должна содержать либо случайную соль, либо некоторую комбинацию солей, специфичных для сайта и имени пользователя, так что тот, кто получает пароль, не может использовать его для того же имени пользователя на других сайтах (даже на сайтах, использующих одинаковую схему хеширования). ), а также против других пользователей сайта, которые могут иметь такой же пароль.
Другие предлагают пользователям создавать уникальные пароли для каждого сайта, который они используют, или использовать диспетчеры паролей. Хотя это хороший совет в теории, мы все знаем, что в реальном мире полагаться на это глупо. Процент пользователей, которые делают любую из этих вещей, невелик, и я сомневаюсь, что это изменится в ближайшее время.
Таким образом, хэширование паролей в javascript является своего рода наименьшим из того, что может сделать разработчик фреймворка / cms, чтобы ограничить ущерб от перехвата паролей при пересылке (что в наши дни легко в сетях Wi-Fi), если и владелец сайта, и конечные пользователи проявляют небрежность о безопасности (что они, вероятно, являются).
источник