Пароль это то что вводится пользователем. Соль либо является константой в алгоритме, либо генерится случайно при установке/смене пароля и тогда хранится вместе с хэшем.
В случае использования соли при хэшировании пароля, если мы будем устраивать тотальный перебор нам нужно перебрать ровно столько же паролей, сколько и в системе без использования соль. В любом случае это прорва времени.
Внезапно, нам удалось получить доступ к хэшам паролей. Времени на полный перебор у нас мало, но мы-то заранее подготовились. Для того чтобы ускорить процесс мы на досуге строим радужную таблицу для всех возможных паролей, например { MD5('war'), MD5('god'), MD5('sex')}. И теперь нам достаточно проверить какому из хэшей соотвествует наш хэш и спокойно получить доступ. Вариант оценки размера радужных таблиц для разных алфавитов уже был на хабре.
Но оказалось, что создатели системы продвинутые люди и использовали соль при хэшировании пароля. Для каждого конкретного пользователя, соль либо известна и хранится вместе с хэшем, либо ее можно получить из алгоритма зная имя пользователя. И перед нами стоит опять затратная по времени задача перебрать все пароли, но уже с прибавлением этой соли {MD5(salt+'war'),MD5(salt+'god'),MD5(salt+'sex')}. Очевидно, что время и количество вариантов для тотального перебора не изменилось. Но вот наша старая таблица уже не дает нам возможности сэкономить время.
Ничто не мешает нам заранее сделать такие таблицы для солей. Диапазон их допустим 0x00 — 0xFFFF и мы просто штампуем таблицы {MD5(0x00+'war'),MD5(0x00+'god'),MD5(0x00+'sex')}, {MD5(0x01+'war'),MD5(0x01+'god'),MD5(0x01+'sex')},…
Да увеличивается экспоненциально место необходимое для хранения таблиц. Но для коротких размеров солей это уже вполне бюджетное хранилище. И с каждым годом объемы хранилищ все меньше имеют значение.
не содержащую эту соль в качестве части пароля, и такой пароль не примет система
соль не часть пароля.
их генерация для каждого конкретного случая занимает существенно большее время, чем прямой перебор
Генерация таблиц равна по времени полному перебору. Просто в случае соли на генерить для каждой соли опять полностью весь доступный парольный диапазон. Ничто не мешает сделать заранее радужные таблицы для солей заранее. Да растет объем для хранения, но в наше время не это проблема. Возможно и существует у тех кому надо.
Это что, вот помнится была на денди какая-то аля рпг с иероглифами, так мало того, что диалоги надо было вести и в магазинах по надписям закупаться, так еще сейв выглядел как полторы сотни иероглифов.
Так с друзьями каждый раз когда сейвились, на всякий случай по три раза перерисовывали это в тетрадку, чтобы хоть один потом удалось бы загрузить. =)
Неизменится надежность.
Я сидя в середине буду просить код заранее, сразу под сформированную мной «левую» транзакцию. Естественно под видом кода для вашей транзакции.
Стандарт ничего говорит ни про царапины, ни про удары. Только пыль и влага.
Пароль это то что вводится пользователем. Соль либо является константой в алгоритме, либо генерится случайно при установке/смене пароля и тогда хранится вместе с хэшем.
В случае использования соли при хэшировании пароля, если мы будем устраивать тотальный перебор нам нужно перебрать ровно столько же паролей, сколько и в системе без использования соль. В любом случае это прорва времени.
Внезапно, нам удалось получить доступ к хэшам паролей. Времени на полный перебор у нас мало, но мы-то заранее подготовились. Для того чтобы ускорить процесс мы на досуге строим радужную таблицу для всех возможных паролей, например { MD5('war'), MD5('god'), MD5('sex')}. И теперь нам достаточно проверить какому из хэшей соотвествует наш хэш и спокойно получить доступ. Вариант оценки размера радужных таблиц для разных алфавитов уже был на хабре.
Но оказалось, что создатели системы продвинутые люди и использовали соль при хэшировании пароля. Для каждого конкретного пользователя, соль либо известна и хранится вместе с хэшем, либо ее можно получить из алгоритма зная имя пользователя. И перед нами стоит опять затратная по времени задача перебрать все пароли, но уже с прибавлением этой соли {MD5(salt+'war'),MD5(salt+'god'),MD5(salt+'sex')}. Очевидно, что время и количество вариантов для тотального перебора не изменилось. Но вот наша старая таблица уже не дает нам возможности сэкономить время.
Ничто не мешает нам заранее сделать такие таблицы для солей. Диапазон их допустим 0x00 — 0xFFFF и мы просто штампуем таблицы {MD5(0x00+'war'),MD5(0x00+'god'),MD5(0x00+'sex')}, {MD5(0x01+'war'),MD5(0x01+'god'),MD5(0x01+'sex')},…
Да увеличивается экспоненциально место необходимое для хранения таблиц. Но для коротких размеров солей это уже вполне бюджетное хранилище. И с каждым годом объемы хранилищ все меньше имеют значение.
people.redhat.com/drepper/SHA-crypt.txt
соль не часть пароля.
Генерация таблиц равна по времени полному перебору. Просто в случае соли на генерить для каждой соли опять полностью весь доступный парольный диапазон. Ничто не мешает сделать заранее радужные таблицы для солей заранее. Да растет объем для хранения, но в наше время не это проблема. Возможно и существует у тех кому надо.
Например, подбор пароля к архиву.
Да нет такого в GPL. Там есть — если продаешь, то дай возможность тому кому продал получить исходные коды, если он попросит.
Так с друзьями каждый раз когда сейвились, на всякий случай по три раза перерисовывали это в тетрадку, чтобы хоть один потом удалось бы загрузить. =)
Я сидя в середине буду просить код заранее, сразу под сформированную мной «левую» транзакцию. Естественно под видом кода для вашей транзакции.