Слушайте, я тут такую странную вещь вдруг узнал. Вот 2025 год на носу, четверть века прошла. И человек пишет про то, что пароли, которые мы вводим на сайтах при авторизации, посылаются почти всегда в открытом виде, как есть. Я как сущий дилетант почему-то думал, что любая страничка авторизации, в которую я копипастю пароль из менеджера, первым делом его хеширует по хитрой схеме, и посылает всегда и только хеш! И при регистрации - хеш, и при логинах, тем более, хеш, а тут... Скажите, это что, неужто правда? Скрин на англ. но для вас это не проблема, перевод на всякий случай от deepL.
Всё так и есть. В этом нет никакого секрета. В этом легко убедиться, открыв в браузере консоль разработчика (F12), перейти на вкладку "Сеть", жмакнуть отправку формы с паролем и посмотреть как оно уходит на сервер.
@hubbitant я в шоке - это ещё слабо сказано. Тут хочется возопить: но почему? это же жесть какая-то, с такими мощностями даже на слабых смартах - и не хешировать пароли прямо в браузере.
Это так не работает. Либо каждый раз пересылать приватный ключ, который можно также перехватить как пароль, либо хранить приватный ключ на сервере в неизменном виде и тогда перехват хеша будет тоже самое что перехват пароля.
@fa11_1eaf @hubbitant @sasha Хэши используются с солью чтобы по утекшей базе нельзя было быстро через rainbow table поперебирать все пароли там. В исходном посте ещё говорится что пароли идут по сети в плейнтексте, что не совсем правда, потому что HTTPS сейчас почти везде.
@lyyn @fa11_1eaf @hubbitant @sasha https учитывается. Но вот, например, рекламорезка, работающая в слоте vpn, ставит в систему (андроид) свой сертификат. Получается, она работает как mitm? Прогоняет через себя дешифрованный https траффик?
@fa11_1eaf @hubbitant Конечно серверу не нужно знать пароль. Он хранит только хэш. А когда нужно проверить полученный от юзера пароль - сервер делает его хэш и сверяет с сохраненным
потому что хеширование используется для разделения хеша из базы и получаемого сервером пароля на случай, если хеши из базы утекли Потому что когда сервер изначально принимает хеши, то утечка данных по сути содержит пароли, ведь их можно сразу в API использовать Если же сервер принимает сами пароли, а хранит их хеши (соленые, кстати), то в случае утечки злоумышленник не сможет аутентифицироваться через API
@philainel допустим. А почему, например, сервер не может в форме для ввода пароля использовать асимметричное шифрование, переслать для этого открытый ключ в браузер? Просто как дополнительный слой защиты?
обычно передаётся голым текстом, если люди не заморочились, но эти заморочки всё равно клиентские шифры обратимые, иначе как сервер поймёт, какой пароль ввёл юзер, а обратимое значит ненадёжное.
что в целом, при наличии https, небольшая проблема, так как канал шифрованный
@Nostre Ставить такие сертификаты - ССЗБ. Так же для этого случае есть 2ФА авторизация. Желательно не через смс. А вообще политические и социальные проблемы, в общем случае, не решаются технически.
@Nostre шлется как есть. Но это скорее защита от анализа трафика после. Если за вами смотрят в реалтайме то не спасет. И в таком случае это не то что бы техническая задача. А вопрос как до такого дошло государство и что делать.
@far5 @ХаББыватель Страницы регистрации, логина и прочие подобные загружаются по протоколу https, и отправка пароля происходит по этому же протоколу. Весь трафик между сервером и клиентом при этом зашифрован.
При использовании TLS 1.3, что сейчас принято в приличном обществе, ключи для шифрации используются одноразовые, нигде не сохраняющиеся. Так что даже перехватив весь трафик и имея серитификат сервера, расшифровать этот пароль будет практически невозможно.
Поэтому вполне нормально передавать его из браузера "открытым текстом".
ХаББыватель
в ответ на far5 • •Gamliel Fishkin 🮱 нравится это.
far5
в ответ на ХаББыватель • • •я в шоке - это ещё слабо сказано.
Тут хочется возопить: но почему? это же жесть какая-то, с такими мощностями даже на слабых смартах - и не хешировать пароли прямо в браузере.
ХаББыватель
в ответ на far5 • •Gamliel Fishkin 🮱 нравится это.
Sasha
в ответ на far5 • • •ХаББыватель
в ответ на Sasha • •ХаББыватель
в ответ на ХаББыватель • •нравится это
Eugene :emacs: :freebsd: и Gamliel Fishkin 🮱 нравится это.
Sasha
в ответ на ХаББыватель • • •fa11_1eaf
в ответ на ХаББыватель • • •Если утечет хэш -- пароль останется.
Достаточно его немного изменить, чтобы получился совершенно новый хэш (каскадный эффект)
Lyyn ☮️
в ответ на fa11_1eaf • • •fa11_1eaf
в ответ на Lyyn ☮️ • • •far5
в ответ на fa11_1eaf • • •far5
в ответ на Lyyn ☮️ • • •https учитывается. Но вот, например, рекламорезка, работающая в слоте vpn, ставит в систему (андроид) свой сертификат. Получается, она работает как mitm? Прогоняет через себя дешифрованный https траффик?
Lyyn ☮️
в ответ на far5 • • •fa11_1eaf
в ответ на Sasha • • •А зачем серверу знать пароль?
Он может просто сохранить у себя хэш и сверяться в дальнейшем с ним.
Sasha
в ответ на fa11_1eaf • • •john3volt
в ответ на far5 • • •Весь трафик идет через https, то есть зашифрован.
Philainel
в ответ на far5 • • •Потому что когда сервер изначально принимает хеши, то утечка данных по сути содержит пароли, ведь их можно сразу в API использовать
Если же сервер принимает сами пароли, а хранит их хеши (соленые, кстати), то в случае утечки злоумышленник не сможет аутентифицироваться через API
ХаББыватель нравится это.
far5
в ответ на Philainel • • •Philainel
в ответ на far5 • • •Мертвый голубь Стаса
в ответ на far5 • • •да пересылаются на сервер без хеширования. Но вся информация скрыта за ssl.
Поэтому все браузеры сейчас ругаются на формы логина без https
κρ🦥μγ
в ответ на far5 • • •обычно передаётся голым текстом, если люди не заморочились, но эти заморочки всё равно клиентские шифры обратимые, иначе как сервер поймёт, какой пароль ввёл юзер, а обратимое значит ненадёжное.
что в целом, при наличии https, небольшая проблема, так как канал шифрованный
far5
Источник неизвестен • • •дело в том, что государство тоже может выступать в роли mitm. Гуглим, например, "национальный сертификат безопасности Казахстан".
john3volt
Источник неизвестен • • •И для клиента и для сервера все видно как есть.
Так в чем вопрос?
john3volt
Источник неизвестен • • •Голый http считай нигде не используется.
john3volt
в ответ на far5 • • •Так же для этого случае есть 2ФА авторизация. Желательно не через смс.
А вообще политические и социальные проблемы, в общем случае, не решаются технически.
ХаББыватель нравится это.
far5
в ответ на john3volt • • •А такие сертификаты лет через -адцать могут стать обязаловкой.
john3volt
в ответ на far5 • • •А вопрос как до такого дошло государство и что делать.
Михаил
в ответ на far5 • • •@far5 @ХаББыватель Страницы регистрации, логина и прочие подобные загружаются по протоколу https, и отправка пароля происходит по этому же протоколу. Весь трафик между сервером и клиентом при этом зашифрован.
При использовании TLS 1.3, что сейчас принято в приличном обществе, ключи для шифрации используются одноразовые, нигде не сохраняющиеся. Так что даже перехватив весь трафик и имея серитификат сервера, расшифровать этот пароль будет практически невозможно.
Поэтому вполне нормально передавать его из браузера "открытым текстом".