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

Но, к сожалению, это именно тоже самое.

А вот тут утверждать не буду, возможно. Я не на столько глубоко погружен в тему, готов поверить.
Если так, то жаль, мысль была интересная…
Поделить password на две части тоже никак не повлияет с точки зрения вероятности…? вроде не очень…

Я говорю, что использовать два разных хеша от одного пароля совсем не то же самое, что в два (или в 10) раза больший хеш…

Но, к сожалению, это именно тоже самое.

Алекс, вы заблуждаетесь. У меня складывается ощущение что вы пытаетесь убедить в этом в первую очередь себя. Дело в целом ваше, но мне жаль что вы не хотите понять то что я пытаюсь до вас донести.
С точки зрения криптографии все эти извращения с разными солями, двумя хешами и т.п. — это лишь увеличение длины итогового хеша. Т.е. по сути это видоизменение алгоритма хеширования, которое не решает фундаментальной проблемы.
Рассматривать ситуацию можно с двух сторон:
— с практической — даже обычного одного sha256 хватит с головой чтобы исключить проблемы с колизиями для паролей в какой-нибудь админке какого-нибудь сайта.
— с теоретической — колизии неизбежны для любых хеш функций.

рано или поздно найдется такой password

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

Даже в таком виде принципиальной разницы нет. Это не решает проблему нахождения коллизии в корне, так как рано или поздно найдется такой password который даст коллизию к двум хешам с разными солями.
Если абстрагироваться от солей и прочее, по сути опять получается хеш бОльшей длины, т.е. 512-битный. Повторюсь, чем длиннее хеш, тем он более устойчив к коллизиям, по вполне понятным причинам. Но сама проблема никуда не денется.

Дмитрий, мне кажется Вы не до конца поняли.
Базово мы берем sha256 (createString(password, personalSalt, commonSalt)).
При этом у нас потенциальная проблема с тем, что возможна коллизия при подборе более простого пароля.
Я предлагаю брать хеш два раза используя разную соль, т.е. sha256 (createString(password, personalSalt, anotherCommonSalt)), хранить и проверять оба значения отдельно.
Тогда это не просто более длинный хеш, коллизия может произойти на одном из них, т.е. найдем другой пароль (anotherPassword), но хеш функция от него на второй соли даст принципиально другое значение, нежели мы храним у себя.

Alex, шутка в том что два хеша разных алгоритмов, можно рассматривать как один хеш но всего лишь бОльшей длины.
Т.е. мы сделали md5(string) + sha256(string) — в итоге мы получили 384битный хеш. Да, такой хеш более устойчив к коллизиям, но он по-прежнему уязвим, хоть, конечно, и на порядки меньше.