Стоит ли шифровать передаваемую информацию на стороне клиента?

Question

[xmoonlight]

Стоит ли всегда шифровать передаваемую информацию на стороне клиента перед отправкой на сервер?

1. Логин/пароль
2. Текстовые поля
3. Файлы

И почему?

Comments

[Сергей delphinpro]

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

<form action="/login" method="post">
  <input type=text>
  <input type=password>
  <input type=submit>
</form>

[xmoonlight]

Сергей delphinpro,

Но если я правильно понимаю, то с вашей точки зрения, обычная форма логина с сегодняшнего дня перестала быть безопасной?

она никогда и не была таковой!

Вкратце, это нужно для e2ee: чтобы обезопасить себя от mitm как без ssl, так и с ssl.

PS: здесь задавался вопрос про ssl: безопасно ли и стоит ли шифровать дополнительно при ssl? Несколько человек ответили, что лучше шифровать даже с ssl.

[Сергей delphinpro]

xmoonlight, допустим.
но какое именно шифрование вы предлагаете применить на практике на клиентской стороне?
Обычное хеширование типа md5 не подойдёт — оно точно также подвержено митм атаке.
Хеширование типа bcrypt, которое используется в password_hash тоже не подойдет — там на выходе всегда разный хэш, а значит мы не можем его соотнести с сохраненным в базе. А сохранять в базу то что пришло с клиента, пусть даже зашифрованное тоже не вариант.

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

[xmoonlight]

Сергей delphinpro, Если речь только про пароль - хешировать я предлагаю его, а не шифровать...

Это не относится к методу безопасной аутентификации ни коим местом!

Это относится только к скрытию самого пароля в чистом виде от всех подряд, кто получит доступ к содержимому формы после её отправки.

[Сергей delphinpro]

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

[xmoonlight]

Сергей delphinpro,

шифрования

ну что ты заладил!))
Говорю же: хеширование!

Таким, что если у юзера одинаковый логин/пароль на разные сервисы, то без хеширования админ/mitm легко смогут залогиниться под ним на другие сервисы. А если будет хеширование, то вероятность совпадения парольного хеша 1-в-1 на разных сервисах сильно снижается, т.к. алгоритмы хеширования могут быть любыми. И при "утечке" БД нельзя будет сразу узнать пароли юзеров в plain text.

Answer 1

[Армянское Радио]

Все это уязвимо перед одной атакой - MITM. Защита универсальна - HTTPS

Пароли, очевидно, никогда не должны попадать на сервер, на сервер должен попадать только хэш.

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

Comments

[xmoonlight]

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

[Froggyweb]

Пароли, очевидно, никогда не должны попадать на сервер, на сервер должен попадать только хэш.

на сервер или в БД?
Какой смысл шифровки на клиенте?

[Армянское Радио]

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

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

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

[xmoonlight]

Фокс Йовович, я думаю так же, но здесь (на форуме этом) есть те, кто с этим не согласен.

PS:

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

хорошо, что заметил! Не забыть про подпись всех post-пакетов!

[Армянское Радио]

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

[Армянское Радио]

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

[xmoonlight]

Фокс Йовович, Согласен полностью!
Ps: ща с мобилы, линк позже дам на то обсуждение.

[xmoonlight]

Фокс Йовович, Какой способ лучше защитит пароль? вот тут, смотри ветку к моему ответу.

[Anton Kuzmichev]

Фокс Йовович, а своё имя слабо сказать, чтобы люди могли посудить о вашей некомпетентности и пополнить свои стоп-листы?
Моё, например, вполне открыто, и всё остальное гуглится. Тут мы вроде как не в телеге соли толкаем, чтобы шифроваться.

[Anton Kuzmichev]

А автору вопроса - чисто на подумать: если вы со своим синдромом Даннинга-Крюгера лезет в безопасность, то чего от вас можно ожидать клиентам в остальных сферах?
И именно вы со своим изобретением должны ссылаться на научные статьи, причём не просто ссылаться - лучше запилите на хабре статью про ваше изобретение, откиньтесь на спинку стула и наблюдайте.

[Роман]

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

Фокс Йовович, но что в данном случае помешает злоумышленнику просто отправлять на сервер хэш вместо пароля ?
Возможно я что то не понимаю в данном вопросе.

[xmoonlight]

Роман, ты (как и туча других участников обсуждения данной темы) тоже перепутал зону риска)))
Ты говоришь о безопасной авторизации.
А хеширование - это предотвращение утечки plain text password при mitm на канале и при утечке данных авторизации, хранящихся в БД на сервере.

[Армянское Радио]

Anton Kuzmichev, правильно ли я понимаю, что кроме перехода на личности, содержательных аргументов против того, чтобы не допускать попадание пароля на сервер даже при регистрации пользователя, у вас нет?

[Anton Kuzmichev]

Фокс Йовович, не знаю, как вы, а я совершенно правильно понял, что историю с выяснением личностей начали именно вы:

Но при этом, я бы хотел иметь перечень имен и компаний - для пополнения стоп листа.

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

[Армянское Радио]

Anton Kuzmichev, прочитайте в другом треде мой комментарий о том, что вы смешали в кучу три вектора атаки.

[Армянское Радио]

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

[Роман]

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

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

[Армянское Радио]

Роман
я уже примерно пятый раз повторяю, что это разные векторы атаки.
Утечка пароля при MITM (то о чем утверждаете вы) исключается при использовании HTTPS и его друзей (HSTS, пин сертификата). Я говорю о другой проблеме

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

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

[Роман]

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

[xmoonlight]

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

[Роман]

xmoonlight, с такой точки зрения не рассматривал. Спасибо что дали вполне логичное объяснение.

[Армянское Радио]

Роман, при правильном использовании HTTPS, пароль может утечь только с сервера.

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

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

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

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

В этом - разница.

Все эти меры защиты только снижают вероятность и размер ущерба.

[xmoonlight]

Фокс Йовович,

при правильном использовании HTTPS, пароль может утечь только с сервера.

Не только!) Ещё есть браузер, расширения браузера, память и т.д.

[wisgest]

Все эти меры защиты только снижают вероятность и размер ущерба.

Фокс Йовович, ущерба пользователю на сторонних сервисах. Эти меры предпринимаются из чистого альтруизма?

[Армянское Радио]

Bavashi, LMGTFY

[wisgest]

Ещё раз.

Все эти меры защиты только снижают вероятность и размер ущерба.

Если у пользователя одинаковый пароль на вашем и на чужом сервисе и злоумышленник узнал пароль пользователя на чужом сервисе, то чем «все эти меры» помогут пользователю на вашем?

[xmoonlight]

wisgest, я отвечу..
Если на моём сервисе mitm перехватил пакет регистрации/авторизации пользователя с хешем пароля или у меня "увели" всю БД с паролями, то злоумышленник не сможет проверить другие сервисы с собранной информацией, т.к. в ней нет паролей пользователей в plain text.

Если у пользователя одинаковый пароль на вашем и на чужом сервисе и злоумышленник узнал пароль пользователя на чужом сервисе, то чем «все эти меры» помогут пользователю на вашем?

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

[Пашенька]

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

[Пашенька]

Bavashi, в данном случае ссылаются на данные этого (The Harris Poll study) исследования.

[Пашенька]

Bavashi,

вы привели ссылку на новость.

Согласен, но что вы хотите увидеть? Во что респонденты были одеты или предложили ли им чаю из вежливости?

В приведенной ссылке выше у вас отмечено 71% по исследованию Lawless Research, TeleSign

я говорил об этом
, о чём и свидетельствует инфографика. Просто писатель не сильно уважает числа.

Цель новости - реклама google password manager

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

всего лишь показаны данные соц. опроса из 3.5к

Даже выборка из ста человек уже может быть показательной.