LINUX.ORG.RU

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

 ,


0

1

Сразу оговорюсь, что я не ахти какой спец по безопасности.

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

Какая принципиальная разница, между

sha1($random_salt . sha1($password))
и, cкажем,
sha1(sha1($username . $email . $time_of_registration) . sha1($password))
? Кто-то считает, что взломщик будет генерить таблицу по такой хренотени, причем сделает это заранее (потому что генерить ее очень долго)? Или есть еще какие-то причины?


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

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

AlexCones ★★★ ()
Ответ на: комментарий от AlexCones

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

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

gaga ()
Ответ на: комментарий от gaga

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

AlexCones ★★★ ()
Ответ на: комментарий от AlexCones

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

gaga ()

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

ms-dos32 ()

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

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

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

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

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

winddos ★★★ ()
Ответ на: комментарий от AlexCones

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

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

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

winddos ★★★ ()
Ответ на: комментарий от winddos

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

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

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

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

gaga ()
Ответ на: комментарий от gaga

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

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

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

winddos ★★★ ()
Ответ на: комментарий от winddos

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

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

AlexCones ★★★ ()
Ответ на: комментарий от AlexCones

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

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от gaga

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

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

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

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от AlexCones

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

winddos ★★★ ()
Ответ на: комментарий от Suntechnic

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

winddos ★★★ ()
Ответ на: комментарий от winddos

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

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

Kalashnikov ★★★ ()
Ответ на: комментарий от winddos

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

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

AlexCones ★★★ ()
Ответ на: комментарий от winddos

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

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

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

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

sergv ()
Ответ на: комментарий от sergv

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

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

winddos ★★★ ()
Ответ на: комментарий от Kalashnikov

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

winddos ★★★ ()
Ответ на: комментарий от winddos

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

blowfish там...

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

sergv ()

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

ansky ★★★★★ ()
Ответ на: комментарий от winddos

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

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

Kalashnikov ★★★ ()
Ответ на: комментарий от Kalashnikov

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

winddos ★★★ ()

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

Seraph ()
Ответ на: комментарий от winddos

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

Kalashnikov ★★★ ()
Ответ на: комментарий от Seraph

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

Kalashnikov ★★★ ()
Ответ на: комментарий от Kalashnikov

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

Seraph ()
Ответ на: комментарий от AlexCones

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Kalashnikov

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

winddos ★★★ ()
Ответ на: комментарий от sergv

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

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

bass ★★★★★ ()
Ответ на: комментарий от bass

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

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

sergv ()
Ответ на: комментарий от ansky

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

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

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

gaga ()
Ответ на: комментарий от Seraph

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

Kalashnikov ★★★ ()
Ответ на: комментарий от Seraph

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

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

ivlad ★★★★★ ()

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

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

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

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

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

sha1($sault, $password)

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

segfault ★★★★★ ()
Ответ на: комментарий от segfault

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

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

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

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

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

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

gaga ()
Ответ на: комментарий от gaga

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

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

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

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

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

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

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

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

segfault ★★★★★ ()
Ответ на: комментарий от segfault

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

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

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

gaga ()
Ответ на: комментарий от gaga

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

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

JFreeM ★★★☆ ()
Ответ на: комментарий от Seraph

если есть код

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

JFreeM ★★★☆ ()
Ответ на: комментарий от gaga

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

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

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

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

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

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

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

Facepalm

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

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

segfault ★★★★★ ()

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

zloelamo ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.