Где взять соль?

[usualdesigner]

Реализовал авторизацию, как показано здесь http://yiiframework.ru/doc/blog/ru/prototype.auth. Возник вопрос - где взять это самое значение $salt? Объявить его руками в модели User? Или есть более правильные решения?

[Nafania]

Оно в базе должно быть, для каждого юзера уникальное.

[kmtz]

Nafania , а можете объяснить, в чем фишка хранения индивидуальной соли для каждого хэша? Всегда хранил одну соль для всех в конфиге: для защиты от rainbow таблиц, если вдруг база утечет. А для чего хранить для каждого хэша отдельно?

[xoma]

наличие одной соли для всей базы паролей практически сводит пользу от ее применения к нулю, достаточно получить эту (одну) соль и перебрать все по rainbow таблицам

[kmtz]

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

[usualdesigner]

Оно в базе должно быть, для каждого юзера уникальное.

Дык тоже в каком то зашифрованном виде?

[Nafania]

Оно в базе должно быть, для каждого юзера уникальное.

Дык тоже в каком то зашифрованном виде?

Соль это может быть что угодно, как вам удобнее.

[usualdesigner]

Оно в базе должно быть, для каждого юзера уникальное.

Дык тоже в каком то зашифрованном виде?

Соль это может быть что угодно, как вам удобнее.

Я имею ввиду что при регистрации пользователя нужно соль сгенерить, и сохранить в соответствующее поле БД, а потом при каждой авторизации вытягивать? Такой подход будет верным?

[Nafania]

Я имею ввиду что при регистрации пользователя нужно соль сгенерить, и сохранить в соответствующее поле БД, а потом при каждой авторизации вытягивать? Такой подход будет верным?

Да, так и надо.

[kmtz]

"Доктор, меня игнорируют"
Разжую:
Итак, имеем соль, полученную случайными нажатиями на клавиатуру (op[)(U{FD+@FUHJ()*#)(#@R+vjdvhmcx , например).
При регистрации/изменении пароля заносим хэш от (пароль + соль) в БД: упростим до максимума: md5($somePass.$someSalt)

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

Какие плюсы дает генерация уникальной соли для каждого?? Я ж не троллить, я просто не могу понять, зачем в принципе генерировать уникальную соль...

[Nafania]

Если злоумышленник получить доступ к базе и сырцам, то ему уже не надо ничего остального, кроме этого доступа.

[usualdesigner]

"Доктор, меня игнорируют"
Разжую:
Итак, имеем соль, полученную случайными нажатиями на клавиатуру (op[)(U{FD+@FUHJ()*#)(#@R+vjdvhmcx , например).
При регистрации/изменении пароля заносим хэш от (пароль + соль) в БД: упростим до максимума: md5($somePass.$someSalt)

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

Какие плюсы дает генерация уникальной соли для каждого?? Я ж не троллить, я просто не могу понять, зачем в принципе генерировать уникальную соль...

Думаю, придумывать суперзащиту нет смысла, ибо при необходимости злоумышленнику проще пытать разработчика, чем сидеть и годами брутфорсить.

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

[kmtz]

Если злоумышленник получить доступ к базе и сырцам, то ему уже не надо ничего остального, кроме этого доступа.

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

Думаю, придумывать суперзащиту нет смысла, ибо при необходимости злоумышленнику проще пытать разработчика, чем сидеть и годами брутфорсить.

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

Мое мнение, что именно там ей и место . Но это уже личные предпочтения. Но зачем хранить лишние данные - это для меня загадка .

[Svyatov]

наличие одной соли для всей базы паролей практически сводит пользу от ее применения к нулю, достаточно получить эту (одну) соль и перебрать все по rainbow таблицам

Хранить уникальную соль для каждого юзера вообще абсурд - уведут базу - уведут все соли, толку от них - ноль.

[xoma]

наличие одной соли для всей базы паролей практически сводит пользу от ее применения к нулю, достаточно получить эту (одну) соль и перебрать все по rainbow таблицам

Хранить уникальную соль для каждого юзера вообще абсурд - уведут базу - уведут все соли, толку от них - ноль.

Если увели базу не поможет ни одна соль, ни 100500 солей (хотя не всегда)

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

[Svyatov]

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

Составит труд, потому что помимо знания соли нужно знать еще алгоритм соления

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

[xoma]

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

Составит труд, потому что помимо знания соли нужно знать еще алгоритм соления

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

Ну к примеру для опенсурсных проектов алгоритм соления узнать не составит труда =) Все же когда у приложения меньше узких мест, которые нужно держать за семью замками - тем лучше.
Исходники терять вовсе не обязательно, можно просто подсмотреть =) Ммм...а вот про пересаливание можете рассказать подробнее ?

[xoma]

Вот еще интересная мысль по этому поводу:

Imagine the password database at a large software company in the northwest US. Suppose it contains 30,000 entries, of which 500 have the password bluescreen. Suppose further that a hacker manages to obtain this password, say by reading it in an email from the user to the IT department. If the passwords are unsalted, the hacker can find the hashed value in the database, then simply pattern-match it to gain access to the other 499 accounts.

Salting the passwords ensures that each of the 500 accounts has a unique (salt+password), generating a different hash for each of them, and thereby reducing the breach to a single account. And let's hope, against all probability, that any user naive enough to write a plaintext password in an email message doesn't have access to the undocumented API for the next OS.

http://stackoverflow.com/questions/4208 ... ble-attack

[Svyatov]

Ну к примеру для опенсурсных проектов алгоритм соления узнать не составит труда =) Все же когда у приложения меньше узких мест, которые нужно держать за семью замками - тем лучше.
Исходники терять вовсе не обязательно, можно просто подсмотреть =) Ммм...а вот про пересаливание можете рассказать подробнее ?

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

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

[Stamm]

Полу-офтопик в тему взлома хэшей паролей: http://rmcreative.ru/blog/post/sovremen ... snyy-login