какие-то странные аргументы. почему другие хеширующие алгоритмы могут работать с любой длинной, а тут вот на тебе, ограничение. И да, бывает, я использую длинные пароли. Очень длинные. Очень. В важных местах. В очень важных.
И о каком примере идет речь? об этом: Код (Text): <?php $password = crypt('My1sTpassword'); // salt будет сгенерирована автоматически // Для проверки пароля в качестве salt следует передавать результат работы // crypt() целиком во избежание проблем при использовании различных // алгоритмов (как уже было отмечено выше, стандартный DES-алгоритм // использует 2-символьную salt, а MD5 - 12-символьную. if (crypt($user_input, $password) == $password) { echo "Пароль верен !"; } ?> тогда сразу вопрос что тут будет: 'My1sTpassword', это случайно сгенерированная строка или это пароль пользователя, тот же что находится и в $user_input? так же вопрос про Blowfish откуда оно берется и как используется. Я не хочу показаться не вежливым, но там такие же объяснятили как вы, говорят А, а что дальше отгадай сам.
Можно еще вопрос, в этом примере есть такое: Код (Text): $strength = "08"; ... crypt($info, "$2a$".$strength."$".substr($encdata, 60)) эти strength и "$", это просто так символы или они несут какой то смысл, как "$2a$" например.
$ - это разделитель 2a - алгоритм 08 - вычислительные затраты. Против подбора пароля методом перебора по сути единственная защита - повышать время расчета этого хеша, в реальном приложении оно будет не очень заметно, а вот когда нужно много раз подряд посчитать - будет долго. К слову, виноват, там что-то автор этого коммента наворотил. На самом деле все проще. Создаем пароль: Код (Text): $salt = ""; for ($i = 0; $i < 22; $i++) { $salt .= substr("./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789", mt_rand(0, 63), 1); } $hash = crypt($password, '$2a$08$'.$salt); Проверяем Код (Text): if ($hash === crypt($password, $hash)) { // пароль верен }
Точно? я просто долго думал над этой функцией и въехал, он берет пароль, создает случайную строку, хеширует пароль и потом к полученному хешу прибавляет все ту же случайно сгенерированную строку. Длина хеша фиксированная, строки тоже, т.е. в итоге данная функция возвращает строку в которой хеш+случайная строка. Когда надо проверить, он разделяет хеш от этой случайно сгенерированной строки ну и проверяет.
Если вы посмотрите полученный crypt-ом хеш, то увидите, что первые символы - это и есть соль. По-этому и не нужно хранить соль отдельно. По-этому и пароль проверяется как $hash === crypt($password, $hash) - т.е. хеш используется как соль - crypt берет нужные ему первые символы с солью.
Встречный вопрос, генерация и проверка пароля понятна, а как и можно ли хранить этот хэш для сессии в cookies чтобы пользователь мог остаться на сайте залогиненным и проверка этого хеша производилась каждую загрузку страницы для работы под своим логином?
Можно, хотя как правило кроме этого хеша пароля подмешиваются еще данные (например, ip, user-agent и т.п.) ну и обычный sha/md5 от этого всего - и его храним в куках.
отличный вопрос! мы знаем, то соль защищает от подбора паролей даже в случае кражи таблицы с хешами паролей. но представьте, что авторизационная кука содержит просто копию хеша. тогда злоумышленнику (укравшему хеши) не надо ничего подбирать — он может просто составить куку по известному правилу и получить доступ. любая защита сильна настолько, насколько сильно ее самое слабое звено.
Как я понимаю с куками ситуация должна быть обратная, т.е. в БД куки должны хранится в не зашифрованном виде, а на стороне пользователя в зашифрованном, потому что если он их удалит а потом снова решит поставить, как ты узнаешь исходный код.
cookies хранятся в браузере, а не на сервере и еще вопрос вот по этому коду: $hash после генерации мы добавляем в базу и приставка $2a$08$ тоже должна быть в каждом столбце с паролем записи в базе? И как проверять его потом? Берем имя пользователя, ищем в базе, если есть вытаскиваем хэш и его присваиваем $hash, потом подставляем сюда? ($password естественно это $_POST['to-chto-user-vvel']) if ($hash === crypt($password, $hash)) { // пароль верен } верно?
в смысле, у меня под куки в БД отдельный столб, и в Бд в не хешированном виде, а у пользователя в хешированном виде, когда человек заходит с куками, мы берем из БД хешируем и сравниваем то, что у пользователя.
Ну достаточно один раз выполнить код и вы увидите сами. Да. Кому нужен доступ, если он уже до базы добрался. В случае компрометации алгоритм легко поменять, хотя достаточно секретный ключ приложения сменить.
куки у юзера в браузере, а не у тебя в бд Добавлено спустя 2 минуты 4 секунды: вопрос был про хеш в куках. стоит ли так делать?
Я делаю. Не хеш напрямую, но что-то вроде sha($password_hash . $secret_key . $user_agent . $ip . $timestamp ) . $timestamp По необходимости можно без ip и времени жизни.
ну вот мне кажется стоит обратить на это внимание. а то товарищ зафигарит парольный хеш в куки, и будет думать, что всё правильно сделал.