У тебя соль в bcrypt - это 128 бит = 16 байт = ceil(16*4/3) = 22 символа в base64 перед этими 22 символами соли идет заголовок $2a$11$ - здесь 2a - версия алгоритма, 11 - количество раундов далее твой пароль, вместе с солью и числом раундов передается в собственно алгоритм bcrypt - и на выходе получается хеш в 192 бита = 24 байта = 31 символ в base64 - вот этот хвост добавляется к 29 битов параметризации - и на выходе получается 60-символьная строка Так что в bcrypt то все нормально Что ненормально - это задавать такие вопросы. Если это вот все неочевидно - то лезть в bcrypt довольно опасно- можно организовать дырень на ровном месте. Особенно в фиг знает чью имплементацию
на счет хз чьей имплементации - это тупо топ 1 наверное по скачиваниям на нугет а вопрос возник так то, у чатгопоты спросил детали до того как лезть в этот чат и погуглил, инфа говорит о том что беспокоиться о том что соль лежит вместе с хешем (является частью его значения) это ок и типа в случае бикрипта хранить хеш рядом с солью это ок. решил спросить тут
Да, соль раскрывать безопасно. Соль, которую нельзя раскрывать (и нужно отдельно хранить от хеша) - ее обычно специально обозначают секретной (secret salt) или перцем (pepper). Основная задача соли - усложнить взлом при массовом сливе (утекло N хешей - если у каждого разная соль, то для взлома нужно N таблиц предпросчитать вместо одной) Популярность не гарантирует корректность/отсутствие багов/гонок. Лет шесть назад смотрел 4 самых популярных реализации scrypt под дотнет - так все с багами были
Чем людям pbkdf2 не угодил, имплементацию которого можно ещё и безвозмездно стырить с исходников asp net core identity
(он, например, используется в iCloud)
Не требует много памяти, следовательно относительно дёшево перебирать. Про практическую безопасность ничего не скажу. Мы как-то сразу с SHA-1 переехали на bcrypt и сидим =)
Ну поставь ты рандомизированное число итераций 20к-25к и моль рандомную для каждого хэша
Как связана память и дешевизна перебора?
Хз где там дешевизна, каждый последующий шаг зависит от результатов предыдущего, итераций дофига
С параллелизуемостью. Большое требования к памяти портят типовое соотношение между ядрами и ОЗУ, не позволяют эффективно использовать data-parallel системы типа GPU.
Обсуждают сегодня