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

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

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

Функции хеширования паролей — это криптографические хеш-функции с некоторыми дополнительными свойствами.

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

Сопротивление столкновениям означает, что невозможно найти любые два разных входа, которые приводят к одному и тому же результату. т.е. невозможно найти любую пару сообщений $м \neq м'$ такой, что $Ч(м)=Ч(м')$.

Сопротивление прообразу означает, что невозможно найти какие-либо входные данные, которые хэшируют заранее заданный выход. т.е. при любом выводе $у$, трудно найти сообщение $м$ такой, что $Ч(м)=у$.

Сопротивление второму прообразу означает, что невозможно найти какой-либо второй вход, который имеет тот же выход, что и указанный вход. т.е. дано сообщение $м$, невозможно найти другое сообщение $м'\neq м$ такой, что $Ч(м)=Ч(м')$.

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

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

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

Но этого не произойдет. Скажи, что есть $2^{64}$ возможные пароли и $2^{256}$ возможные хэши. Если вы угадываете пароль и он имеет правильный хэш, то вероятность $1 - 2^{-192}$ что вы действительно угадали правильный пароль.

Проще говоря, алгоритм хеширования пароля $pH$ берет соль $соль$ и ввел пароль $pwd$ и вычисляет $h' = pH(соль,pwd)$ и проверить $ч$ с хешем текущего сохраненного пароля $ч$, $h \overset{?}{=} ч'$.

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

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

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

• Учитывая хэш-значение $ч$ найти и ввести такие $м$ что $ч = хэш(м)$. Общая стоимость этой атаки составляет $\mathcal{O}(2^n)$ за $n$-битные хеш-функции (хеширование пароля или криптографические хэш-функции)

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

но как это работает для предотвращения взаимозаменяемого использования конфликтующих паролей?

Вы не можете предотвратить это, оно существует принцип сортировки. Скорее, алгоритм хеширования паролей по своей конструкции защищен от него, даже если вы использовали просто MD5. MD5 по-прежнему защищен от атак с предварительным образом, у вас будет ~ 128-битная устойчивость к предварительному образу. Конечно, нужно использовать современные алгоритмы хэширования, такие как Argon2.

другими словами, являются ли эти приемы причиной того, что неверный пас не пускает вас, или он все равно не работает?

Вот как это работает, это всегда будет работать. Имейте в виду, что у вас будет вероятность $\dfrac{1}{2^{128}}$ для случайного одиночного пароля, который соответствует хэшу вашего пароля (при условии 128-битного вывода). Если вероятность события $\geq \dfrac{1}{2^{100}}$ мы просто говорим, что это-не-случится.

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

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