Так ли нужна случайная соль?

sha1(sha1($username . $email . $time_of_registration) . sha1($password))

Как минимум вам потребуются две лишние выборки из базы.

В 99% слуаче эти значения хранятся в одной таблице - 1 запрос.

Ну и чтоб два раза не вставать: насколько вообще актуально использовать хэши вроде SHA, оптимизированные по скорости? Ведь брутфорс по ним идет очень быстро, в отличие от, скажем, bcrypt? Или все же достаточно медленно, чтобы не заморачиваться и не тратить ресурсы на bcrypt?

Захотят взломать чей то аккаунт - взломают, как бы вы его не шифровали. Метод социальной инженерии никто не отменял. Грамотно настраивайте политики безопасности для root`а и все будет хорошо.

это понятно, я чисто теоретически интересуюсь с т.з. информационной безопасности

Забудь про базу LinkedIn.
тебя уже отследили

да там вообще соли нет, че о них говорить

Какая принципиальная разница, между
При этом считается, что чем больше соль содержит энтропии, тем менее вероятно провести успешную атаку по такой таблице.

Ты совершенно прав.

Ну и ещё, может email юзер сменит или дату регистрации надо будет поменять, что потом с паролем делать?
Хранить те с которыми засолен пароль дополнительно?

Именно поэтому юзают соль, которая хранится как добавок к паролю и не будет меняться без смены пароля.

PS:
1 - sha1 не безопасен, его юзать уже по сути нельзя. Лучше перейти на хардкор типа sha512 :)
2 - В добавок к соли лучше использовать многократное хеширование, это значительно усложняет задачу подбора.
Скажем если нагрузка не критична, то можно 50к раз обрабатывать, а такой ты даже пачкой видюх хрен подберешь :)

Метод социальной инженерии никто не отменял.

Методом социальной инженерии мало кто владеет, да и не все поведутся.

Скажем подсунуть человеку троянца довольно сложно, а от остальных ситуаций спасет привязка сессий к IP, SSL и невозможность использования не стойких паролей (cracklib).

Ну и ещё, может email юзер сменит или дату регистрации надо будет поменять, что потом с паролем делать?

Точно, об этом я не подумал. Вопрос тогда снимается.

Скажем если нагрузка не критична, то можно 50к раз обрабатывать, а такой ты даже пачкой видюх хрен подберешь :)

Проще уж тогда bcrypt, да и безопасней будет.

Проще уж тогда bcrypt, да и безопасней будет.

Вообще выбор алгоритма на твоё усмотрение.

Но желательно чтобы процедура хеширования требовала много ресурсов, так много как ты можешь себе позволить в своем сервисе.
Тогда подбирать будет очень сложно, что является огромным плюсом.

и невозможность использования не стойких паролей (cracklib)

Я бы убивал, за сайты, которые указывают, какой пароль мне использовать.

... и операционные системы и программы. Тем более что это только снижает безопасность уменьшая поле ключей.

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

А вот чисто теоретически ты должен это учитывать. Любую сложность можно выразить в деньгах и как только она становится дороже социнженерии (в общем смысле вплоть до терморектальных методов анализа) ты можешь хоть мульен раз пройтись самым сложным алгоритмом - безопасность выше не станет.

Помнишь анекдот про чукчу который собирается убегать при виде медведа, а геолог спрашивает - «Ты что собираешься бежать быстрее медведя?». «Зачем?» - Отвечает чукча - «Главное бежать быстрее тебя.»

Так и тут - не надо делать систему которая будет невзламывема вообще. Достаточно чтобы ее взлом был дороже другого способа получить доступ.

Это чисто теоретически.

Убивал бы пользователей, которые используют один пароль на нескольких ресурсах.
А потом идут к сапорту и ноют что у них баланс слил злой негодяй.

Плюсую.
Надо чтобы взлом был дороже, чем взлом конкурентов :)

может email юзер сменит

Это надо бужет подтвердить паролем же. Значит можно хэш заново сгенерировать.

Убивал бы пользователей, которые используют один пароль на нескольких ресурсах.

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

Вообще выбор алгоритма на твоё усмотрение.

Во! Можно я спрошу!

Вот есть /etc/master.passwd из OpenBSD. Стоит задача перевести сервер на Debian. Тупой перенос BF-хэшей дает несовпадение хэша на Debian с оригиналом с вероятностью 1/3. Видимо, алгоритм хэширования таки немного разный.

Есть-ли какой-то не очень ресурсоемкий способ подбора BF-паролей? Очень не хочется заниматься предварительным снифингом паролей в течение месяца-двух...

Есть-ли какой-то не очень ресурсоемкий способ подбора BF-паролей?

Понятия не имею как именно хешируются пароли в OpenBSD, но я думаю проще как то похитрить с дебианом, чем брутить пароли :)

А если админ захочет юзеру мыло сменить?
В общем один геморой.

Понятия не имею как именно хешируются пароли в OpenBSD

blowfish там...

И хитрить безтолку - pam_unix2 выдает слишком часто другие хэши...

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

А это ещё зачем? Без ведома пользователя менять его критичные данные?

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

Вот чтобы не создавать гемора под соль выделяют отдельное поле.

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

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

Напрягать? В самом простом варианте там всего одна лишняя конкатенация. Или ты хэшами предпочитаешь не напрягать?

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

Всё правильно. Не будь таких сообщений - злоумышленники могли бы и по словарю запросто сбрутить.

Сюрприз кулхацкерам это 50к раз обрабатывать хешек с помощью sha512. :)

есть /etc/master.passwd из OpenBSD. Стоит задача перевести сервер на Debian

По-моему, самое удобное в свете смены платформ - миграция в ldap.
Вот если надо знать пароли юзеров, то оно конечно можно и поснифить, но лучше волевой сброс и замена.

...но лучше волевой сброс и замена.

Проходил уже на более мелком сервачке - вони было! ...

Достаточно id польозователя в хэш добавить. А так соль получится просто функцией от id. Да и вообще хранимая соль - не соль.

Да и вообще хранимая соль - не соль.

Как соль может быть не хранимой? Как ты потом ее выковырнешь ее при проверке хэша? Если она как-то генерится неявно (вроде sha1($user_id)), то один хрен она хранится, просто чуть менее явно. Если она берется не из базы, то он тоже хранится, просто не в базе.

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

Я предпочитаю один раз хешировать пароль и на этом все.

Привет, сотрудник linkedin. :)

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

Не за чем. Ее лучше хранить в файлике, недоступном серверу БД.

При этом считается, что чем больше соль содержит энтропии, тем менее вероятно провести успешную атаку по такой таблице.

Пардон, энтропия константы - ноль. Видимо, имелось в виду, что эта соль не должна составлять ни с каким паролем какой-либо «стандартный» пароль.

sha1(sha1($username . $email . $time_of_registration) . sha1($password))

sha1($sault, $password)

Ничем не хуже. Кстати, не забываем, что sha1, как и md5 уже пора на пенсию.

Не за чем. Ее лучше хранить в файлике, недоступном серверу БД.

Мне кажется, это бессмысленно - слишком много телодвижений с сомнительным результатом. Тогда уж лучше все данные пользователей (логин, пароль, соль) хранить на отдельном сервере, недоступном с сервера БД.

Пардон, энтропия константы - ноль. Видимо, имелось в виду, что эта соль не должна составлять ни с каким паролем какой-либо «стандартный» пароль.

Имелась в виду энтропия при генерации соли, т.е. чтобы она была максимально похожа на случайную. Для случайной соли невозможно рассчитать радужную таблицу заранее, в то время как если заранее известен алгоритм и все данные, по которым генерится соль (в моем примере это имя пользователя, емейл и время регистрации), теоретически можно заранее рассчитать таблицы. Другое дело, что на практике осуществить это маловероятно, потому что потребует огромных временных и вычислительных затрат. Собственно, мой вопрос и состоял в том, насколько стоит запариваться по этому поводу.

Ничем не хуже. Кстати, не забываем, что sha1, как и md5 уже пора на пенсию.

Зависит от задачи. Эти хеши просто оптимизированы по скорости, что не очень хорошо для нашей цели, но очень хорошо для всех остальных.

Тогда уж лучше все данные пользователей (логин, пароль, соль) хранить на отдельном сервере, недоступном с сервера БД.

Вот это уж действительно ничем не лучше. А защитить соль от SQL-инъекций и отвала PHP - весьма полезная цель, тем более, что логин и пароль от SQL сервера все равно читается из подобного файлика.

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

Если мне при генерации выпадет, к примеру, соль «qwerty», то энтропия, которая была у генератора, ее выдавшего, меня никак не спасет. Еще раз повторяю: когда речь идет о константе, об энтропии говорить бессмысленно.

Собственно, мой вопрос и состоял в том, насколько стоит запариваться по этому поводу.

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

Эти хеши просто оптимизированы по скорости

Есть масса простейших алгоритмов контрольных сумм, куда более ориентированных на скорость, но не стойких к намеренному поиску коллизий.

Если мне при генерации выпадет, к примеру, соль «qwerty», то энтропия, которая была у генератора, ее выдавшего, меня никак не спасет. Еще раз повторяю: когда речь идет о константе, об энтропии говорить бессмысленно.

Спасет. Потому что во-первых, реальная соль будет что-то вроде sha1('qwerty'), а во-вторых радужная таблица на практике не строится для взлома одного пароля, она генерится для всей базы причем генерится заранее. И ее нельзя сгенерировать, не зная алгоритма и исходных данных для вычисления соли. Для случайной соли нельзя сгенерить таблицу.

Энтропия имеется в виду по _всей_ базе, не одно значение для одного пароля. Т.е. если у тебя берется полностью случайная соль для каждого пароля, энтропия максимальна, если вычисляется на основе, например, времени, она условно «средняя», если она константна, то она «ноль», и в таком случае таблицу построить не сложнее, чем вообще без соли (константу для этого надо знать, конечно).

брутфорс по ним идет очень быстро

да ну? радужные таблицы составлены для обычны альфанамерик строк до 8 символов. Далее, соль обычно хардкодится в исходниках, таким образом сгенерить радужные таблицы на (8 + n) символов становится сложнее - надо еще достать соль. А обычные радужные таблицы беспомощны в случае соли.
Т.е. в целом соль - безусловно нужна. И более того, очень легко сделать, чтобы конкретное значение соли не хранилось в исходниках. Таким образом соль будет у тех кто имеет доступ к продакшн серверам, а круг таких людей весьма ограничен.

если есть код

ну попробуй достань код из приватной VPN сетки.

не зная алгоритма

man правило Керхкгоффса.

Потому что во-первых, реальная соль будет что-то вроде sha1('qwerty')

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

она генерится для всей базы причем генерится заранее.

Для всего одной базы ее вряд ли станут генерить.

Т.е. если у тебя берется полностью случайная соль для каждого пароля

Facepalm

и в таком случае таблицу построить не сложнее, чем вообще без соли

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

Самый простой ответ: чтоб у пользователя выбравшего пароль qwerty или sex было больше шансов уцелеть при выносе базы.

прочитай пост внимательней