Какой способ лучше защитит пароль?

Question

[Ванька]

Есть такие функции

function pass_hash($pwd) {
	$salt = bin2hex(random_bytes(8));
	return hash_pbkdf2('sha512', $pwd, $salt, 7826, 84).$salt;
}

function pass_verify($pwd, $hash) {
	$salt = substr($hash, -16);
	$hash2 = hash_pbkdf2('sha512', $pwd, $salt, 7826, 84);
	return strcmp(substr($hash, 0, 84), $hash2) === 0;
}

И есть встроенные в php

password_hash()
password_verify()

Лучше ли первые функции защитят пароли при взломе?

Comments

[maxim]

еммм

Answer 1

[FanatPHP]

Первый вариант, разумеется, вообще ни о чём.

Есть три вектора атаки на пароли: перебор по радужным таблицам, брутфорс и подбор по словарю.
От первого защищает соль, от второго алгоритм, от третьего сложность пароля.

У нас здесь речь идет об алгоритме. То есть, о буртфорсе. Что такое брутфорс? Это тупо подстановка случайных сочетаний символов по очереди и проверка, не совпал ли хэш. Чем быстрее вычисляется хэш, тем быстрее раскалывается пароль.
ПОЭТОМУ, ключевой характеристикой хэша для паролей является сложность его вычисления.
Твой ша-пицот-двенадцать выплоненный стопицот раз - это для современной техники как воробей чихнул. А для будущей и подавно.
Поэтому умные люди придумали алгоритмы которые во-первых вычисляют каждый хэш гораздо медленнее, а во вторых адаптируются под растующую скорость процессоров, и говорят тебе когда пора уже усложнять алгоритм. Именно этим и занимаются встроенные функции, и поэтому ты должен использовать именно их.

Answer 2

[Rsa97]

https://www.php.net/manual/ru/function.hash-pbkdf2.php

Предостережение
Метод PBKDF2 может быть использован для хеширования паролей в целях их хранения. Однако стоит помнить, что для этих целей гораздо лучше использовать password_hash() или crypt() с CRYPT_BLOWFISH.

Comments

[Ванька]

Просто там не написано почему

Answer 3

[ThunderCat]

Я понимаю что в гамаке и стоя интереснее, но все же - 2 вопроса: Зачем и нахрена?

Comments

[Ванька]

Там сайт с посещаемостью 100 тыщ в месяц

[ThunderCat]

Ванька, И? Это повод устроить ад и содомию на ровном месте?

Answer 4

[Антон Шаманов]

`password_...` как минимум проще в использовании, а вообще пофиг если фиксировать неудачные попытки входа и блокировать ввод секунд на 5

Comments

[FanatPHP]

Ты путаешь подбор пароля и защиту от хищения паролей из базы. Хэш в первую очередь защищает от второго

[Антон Шаманов]

FanatPHP,

Ты путаешь подбор пароля и защиту от хищения паролей из базы.

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

[FanatPHP]

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

только не на разных машинах, а при каждой генерации хэша

Answer 5

[xmoonlight]

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

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

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

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

Comments

[FanatPHP]

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

[xmoonlight]

FanatPHP, два раза и с разными алгоритмами на фронте и бэке (разумеется, что не одним!).

[АртемЪ]

FanatPHP,

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

Вроде речь о том что хэш потом хэшируется а не пароль.

[АртемЪ]

xmoonlight, А зачем хэшировать хэш? Я как-то не вижу логики. Для чего это?

[Ванька]

Насколько это быстро?

[ThunderCat]

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

[xmoonlight]

АртемЪ, ThunderCat, Ванька, Нужно - да: чтобы увеличить время перебора.
А чтобы не было перекрытий в сторону уменьшения сложности вероятности (и увеличения вероятности к нахождению с помощью коллизий) - нужно использовать разные затратные (в плане скорости) алгоритмы.
И, как уже и упомянул FanatPHP, современные стараются обладать такими свойствами, но всё равно нужно проверять.

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

Хешируется сначала сам пароль, а затем (на сервере) - ещё раз его хеш.

[Vitsliputsli]

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

[xmoonlight]

Vitsliputsli, тем, что пароль будет сложно восстановить как при перехвате запроса, так и при хищении БД сервера.

[ThunderCat]

xmoonlight,

Всегда отправляется только его hash.

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

[Vitsliputsli]

xmoonlight,

тем, что пароль будет сложно восстановить как при перехвате запроса, так и при хищении БД сервера.

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

[xmoonlight]

ThunderCat,

Это же пипец какая лажа, кроме того что это никак не защищает пароль от перехвата,

Это защищает пользователя от "утечки" открытого пароля (plain text) через "прослушку" сети и на стороне сервера: при возможной утечки БД.

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

Это намного лучше, чем отправка в plain text! Чтобы было "по-проще ловить" - можно использовать "примесь": рандомную вставку случайных символов в случайные позиции. И это уже будет вообще нереально восстановить, а сервер - спокойно проверит.

[xmoonlight]

Vitsliputsli, Соль нужна всегда, если хеширует клиент (думал, что это и так очевидно!): Вызов-ответ (аутентификация).

[Vitsliputsli]

xmoonlight,

Это защищает пользователя от "утечки" открытого пароля (plain text) через "прослушку" сети и на стороне сервера: при возможной утечки БД.

Пользователю абсолютно фиолетово взломали его узнав его пароль или не зная пароль.

Это намного лучше, чем отправка в plain text! Чтобы было "по-проще ловить" - можно использовать "примесь": рандомную вставку случайных символов в случайные позиции. И это уже будет вообще нереально восстановить, а сервер - спокойно проверит.

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

Соль нужна всегда, если хеширует клиент (думал, что это и так очевидно!)

Если это очевидно, то какую очевидную соль следовало использовать в этом случае?

[xmoonlight]

Vitsliputsli,

1.Пользователю абсолютно фиолетово взломали его узнав его пароль или не зная пароль.

2. Еще раз, никто не собирается восстанавливать первоначальный пароль, это не нужно, т.к. обманываем мы сервер, а сервер работает не с первоначальными паролями.

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

[Vitsliputsli]

xmoonlight,

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

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

[xmoonlight]

Vitsliputsli,

Мне было непонятно каким образом это может защитить пользователя, о чем и спросил, высказав свои соображения.

Объясняю.
1. Захешированный пароль с "солью" сервера никак не удастся переиспользовать, если не знать реальный и при том, что все неуникальные запросы будут отклонены сервером и время действия серверной "соли" будет ограничено.
2. Перехват данных не даст возможности восстановления реального пароля для любого переиспользования.

[АртемЪ]

Vitsliputsli,

чем нам поможет отправка хеша пароля, а не пароля

Тем что никто не будет знать пароль - он дальше компьютера пользователя не уйдет.

тем, что пароль будет сложно восстановить как при перехвате запроса, так и при хищении БД сервера

Не сложно, а невозможно.

Пользователю абсолютно фиолетово взломали его узнав его пароль или не зная пароль.

Разумеется.

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

[Anton Kuzmichev]

АртемЪ xmoonlight Вы вообще себя слышите? Не говоря уже о других.

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

Фраза сектант-стайл, да ещё и жирненьким, просто валяюсь.

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

Чтобы было "по-проще ловить" - можно использовать "примесь": рандомную вставку случайных символов в случайные позиции. И это уже будет вообще нереально восстановить, а сервер - спокойно проверит.

Упал со стула ещё раз. Пришлось отжаться, чтобы 2 раза не вставать ложиться.
Если вы не знали, то изобретать что-то "новое" в области криптографии, не будучи хотя бы математиком - крайне плохая затея, от которой следует воздержаться. В противном случае хакерам будет очень "по-проще".

[Anton Kuzmichev]

Тот, при котором сам пароль никогда не отправляется с фронта на бэк.

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

Чтобы не использовать пароли напрямую, придумали как минимум OAuth.

[АртемЪ]

Anton Kuzmichev,

Почему Вы так упорно не хотите, чтобы пароль был не в хешированном виде

Во первых пароль в хэшированном виде быть не может. Хэш это не вид пароля. Хэш это только хэш.
Во вторых - пароль не должен никуда уходить от пользователя!!!! Это аксиома. Если пароль уходит на сервер это неправильно. На сервере не должно быть пароля!

[Anton Kuzmichev]

АртемЪ, "Б - Безопасность".

Не, ну разве что эти финтифля могут защитить от того, что по дороге пароль не украдут, ладно.
Но тут вам поможет TLS, прикручивайте сертификаты и ходите по HTTPS.
Всё.

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

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

Если пароль уходит на сервер это неправильно.

Мне жаль все те гуглы и яндексы, которые не дошли до такой простой истины, до которой дошли вы.
Хотя вру, всё же дошли. Предложили всему миру своё провайдерство в OAuth2, которым я и стараюсь пользоваться на других сервисах, если они такое предлагают.
Но так или иначе и как бы то ни было, время от времен приходится вводить пароль в самом гугле, чтобы он отправился на сервер для проверки. И мне страшно, честно!)

На сервере не должно быть пароля!

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

[АртемЪ]

Bavashi, Anton Kuzmichev, Приношу извинения. Я тут явно затупил и написал чушь.

Хэш отправляют потому что это безопасно.

Это написал я, и это чушь.
Видимо заработался, на автомате ответил не вьехав в тему.
Хэш на сервер не отправляют, отправляют пароль. Хэш хранят на сервере.

[xmoonlight]

Bavashi, Первичная проблема: не отдавать паролю в открытом виде уйти с клиента.
Не раскрывать его никому.
А проблема перехваченного хеша для аутентификации - это уже проблема логики и алгоритма аутентификации. Например, если challenge привязан к IP юзера и к его учётке, то даже с верным паролем ничего не выйдет. А если там ещё проверка на уникальные запросы - то вообще никак.
Вопрос про подмену сессии с сервером - это уже 3-тья проблема!)

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

Anton Kuzmichev, вы смешиваете в кучу три атаки.
1) кража владельцем сервера пароля пользователя для использования его в своих целях
2) кража пароля третьей стороной в процессе MITM
3) онлайн-брутфорс пароля

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

От второго мы используем HTTPS, без этого никак

Третье - это просто детская атака, достаточно настроить fail2ban.

[xmoonlight]

Bavashi, О какой конкретно уязвимости ты говоришь?

[xmoonlight]

Bavashi,

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

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

[galaxy]

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

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

Если вы не доверяете серверу, че ж вы доверяете его соли? Он может выдать и короткую/слабую, и всем клиентам одну.
А вообще поздравляю, вы изобрели генератор паролей аля LastPass.

[Vitsliputsli]

xmoonlight, если вы закончили с метафизикой, то может объясните что все-таки имеете ввиду?

что серверу мы вроде как это подсунем тот же хеш, что и поймали

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

А я говорил про то, чтобы сам пароль был захешированным.

это должно значить что-то иное чем в выше указанном предложении? Если "сам пароль" захеширован, то мы имеем хеш этого пароля, который могут перехватить... И? Постарайтесь объяснить, что вы имеете ввиду, из этих обрывочных фраз ничего непонятно, и вы это прекрасно понимаете. "Солить хеш очевидно" - допустим, но чем солить, как солить? Это отнюдь не очевидно, и есть много вариантов. На что уже и без меня обратили внимание выше.

ps Что за привычка в любом вопросе делать серьезный вид и представать неким гуру, а кругом все идиоты. Если вас не понимают, объясните подробнее, а не бросайтесь короткими ничего не значащими фразами. Все мы можем ошибаться, и именно поэтому мы задаем вопросы, а не чтобы потешить свое чсв. Хеширование подразумевает хеширование, а не многофакторную аутентификацию, нельзя здесь выезжать на фразе "это очевидно". Очевидно тебе, не очевидно другому, именно поэтому составляют словари предметной области при разработке проектов, к чему себя считать умнее или выше этого?

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

galaxy, Все три ваших "факта" будет видно при аудите безопасности - и короткую соль, и одинаковую соль, и слабую функцию.

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

[Anton Kuzmichev]

xmoonlight,

Первичная проблема: не отдавать паролю в открытом виде уйти с клиента.
Не раскрывать его никому.

Более вопиющую самоуверенность, чем в области безопасности, ещё поискать.

Вам кто сказал, что это проблема? Вы кто, что заявили, что это проблема? И ещё раз, кто вы есть, что можно доверять вашему решению и свой пароль ему соответственно?

Было бы это проблемой - решалось бы соответствующими протоколами, и вообще браузером на стороне клиента.

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

Не устану повторять, что вы занимаетесь абсолютной ерундой. Но вы уверены настолько, насколько даже Даннинг вместе с Крюгером не были. Раскройте же секрет, кто вы и где работаете. Люди обязаны знать искпердов в области безопасности и сервисы, которые такие люди делают.

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

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