Почему почти нет веб-страниц, хэширующих пароли в клиенте перед отправкой (и хэшированием их снова на сервере), чтобы «защитить» от повторного использования пароля?

46

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

Поэтому мне интересно, насколько сложно создать веб-страницу, которая хэширует пароли на клиентском компьютере (с Javascript), прежде чем отправлять их на сервер, где они будут повторно хэшироваться? Теоретически это не дает никакой дополнительной безопасности, но на практике это может быть использовано для защиты от «мошеннических сайтов», которые не хэшируют ваш пароль на сервере.

— Мартин Фиксман
источник

18

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

3

Лучшее решение - (imo) менеджер паролей на стороне клиента. Таким образом, вы можете генерировать случайную строку символов в качестве вашего пароля, и вы не полагаетесь на сервер, чтобы «защитить» вас.

— Дин Хардинг

2

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

— Steve314

2

@ Steve314 Моя точка зрения заключается в том, что на клиенте все по умолчанию скомпрометировано. Вы можете хешировать, хешировать и хешировать, если это делается на клиенте и передается туда и обратно на сервер, то clearэто просто математическая мастурбация в этой точке. Я должен был исправить систему, которую я унаследовал, которая была разработана точно так, как вы и ОП описываете, ее постоянно взламывали подростки с Wireshark. Мы заблокировали его, только когда включили REALшифрование, зашифровали и подписали все полезные данные на сервер и с сервера, манипулирование учетной записью прекратилось и после этого больше никогда не происходило.

5

Похоже, ваш план защиты от мошеннических сайтов состоит в том, чтобы попросить мошеннические сайты повысить безопасность. ?

— pc1oad1etter

46

Почему не используется? Потому что это много дополнительной работы для нулевого усиления. Такая система не будет более безопасной. Он может быть даже менее безопасным, поскольку создает ложное впечатление о большей безопасности, заставляя пользователей применять менее безопасные методы (такие как повторное использование паролей, парольные словари и т. Д.).

— Рейн Хенрикс
источник

2

Это лучший ответ на данный момент.

1

Это как шифрование Blu-Ray и DVD. Ему даже не нужен ключ для разблокировки. Единственная «защита», которую он обеспечил, заключалась в том, что, когда впервые появились DVD-диски, стоило купить диск для его копирования, а не полную копию фильма. Конечно, теперь вы можете купить DVD за доллар, а еще больше - тот факт, что ключи теперь общедоступны. То же самое происходит с Blu-Ray

— Майкл Браун

2

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

— Андомар

2

Я думаю, что подход x4u вполне может подойти для некоторых приложений, где требования безопасности находятся где-то между передачей паролей по проводам и использованием сертификатов. Я думаю, что некоторые из тех, кто говорит «нет», упускают из виду, что хеширование пароля перед его передачей по сети выполняется в дополнение к стандартной обработке учетных данных на стороне сервера. Таким образом, вопрос заключается в следующем: повышает ли предложение x4u безопасность в сценарии передачи пароля по проводам или нет. Я говорю, что это так. Ключ к пониманию этого заключается в использовании солей с паролем.

— LOAS

6

Правильный способ предотвращения MITM-атак - сквозное шифрование. TLS (https) существует: используйте его. Не изобретайте свои собственные крипто-схемы.

— Рейн Хенрикс

14

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

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

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

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

Если вы использовали javascript, все, что нужно «хакеру» - это использовать тот же метод для hashed-hashed-passwords. Как только у вас есть хешированная информация, нужно просто вычислить пароль-> тот же хеш в базе данных, который является фактором, препятствующим доступу к учетной записи.

— Ramhound
источник

1

Если ваш браузер всегда хеширует его одним и тем же способом, то да, ваш хеш может использоваться как пароль везде. Но что, если браузеры назначают соль на основе сайта (может быть, домена?) До хеширования и отправки на сайт? Я думаю, что это интересная идея.

— Tesserex

2

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

3

Когда вы цитируете оригинальный постер, отформатируйте текст как таковой (выделите текст и используйте значок цитаты прямо над редактором)

— Marjan Venema

1

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

— x4u

3

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

11

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

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

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

— Джон Рейнор
источник

3

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

— pc1oad1etter

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

— Leewz

6

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

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

Сертификат клиента может храниться на смарт-карте (и загружаться в безопасное онлайн-хранилище с использованием мастер-пароля).

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

Microsoft попыталась предоставить что-то подобное в Windows с помощью Cardspace, а затем представила это как открытый стандарт. OAuth чем-то похож, но опирается на посредническую «эмиссионную сторону». Инфокарты с другой стороны могут быть выпущены самостоятельно. Это реальное решение проблемы с паролями ... удаление паролей в целом.

OAuth - это шаг в правильном направлении.

— Майкл Браун
источник

5

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

— x4u

5

большинство ответов здесь, кажется, полностью упускают из виду хеширование пароля на стороне клиента.

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

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

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

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

— crutchy
источник

2

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

— Фрэнк

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

— костыль

@ Фрэнк принятый ответ граничит с тем, что слишком долго, чтобы беспокоиться о чтении. в нем слишком подробно рассказывается о том, как это может быть реализовано, и просматриваются преимущества к концу. Наличие TL; DR в другом ответе полезно.

— Жюль

2

@Jules: Вот почему существует редактирование.

— Роберт Харви

1

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

— zypA13510

1

Это определенно возможно, и на самом деле вам не нужно ждать сайт.

Посмотрите на SuperGenPass . Это букмарклет.

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

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

Он не очень безопасен (base64-MD5), но вы отлично распространяете реализацию на основе sha-2, если хотите.

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

— Матье М.
источник

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

— Aaronaught

3

это не более безопасно, чем любая другая схема, которая передает пароль в открытом виде. Это делает пароль уникальным, но он по-прежнему не зашифрован , но если у меня сервер посередине, я могу просто взять сложный, но все же чистый пароль и использовать его столько, сколько я хочу, он не меняется. Хеш - это не волшебная палочка, это даже не шифрование, их называют криптографическими, но это не значит, что они являются шифрованием. Не имеет значения, если мой пароль passwordи / или SHA-256 passwordс какой-то солью, которая известна клиенту, человек в среднем прикреплении может захватить его.

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

— Матье М.

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

— Матье М.

6

@Jarrod: это не мера безопасности для сайта , это мера безопасности для пользователя . Если бы все использовали схему, подобную этой, повторное использование пароля не было бы проблемой. Схема MITM может использовать хешированный пароль клиента для получения доступа к этому сайту, но только к этому сайту. Вот где лежит улучшение. Обычно вы ожидаете, что сможете получить доступ ко многим учетным записям, просто взломав один пароль, потому что этот пароль может быть использован повторно; в этом случае взломанный пароль практически гарантированно действителен только для сайта или базы данных, в которой он был найден.

— Aaronaught

0

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

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

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

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

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

— Крис Невилл
источник

1

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

— gbjbaanb

-1

Я думаю, что это хороший метод для использования при создании чего-то вроде фреймворка, CMS, программного обеспечения для форумов и т. Д., Где вы не контролируете серверы, на которых оно может быть установлено. То есть, ДА, вы всегда должны рекомендовать использовать SSL для входа в систему и входа в систему, но некоторые сайты, использующие ваш framework / cms, не будут иметь его, поэтому они все равно могут извлечь из этого пользу.

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

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

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

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

— matthewv789
источник