Согласен, возникла некоторая путаница. В справке, которую я цитировал, говорится об отсутствии параметра $salt вообще, а без него функция crypt() по алгоритму bcrypt работать не будет.
Тем не менее, как заметил пользователь RubtsovAV, если соль не задавать (не параметр функции crypt(), а именно соль в строке $2a$cost$salt), то по-умолчанию будет использоваться строка, состоящая из знаков $. Так что не указывать соль, как предлагает Lockal, нельзя.
Ну вот вы хотя бы открывали статью в вики про bcrypt?
Хотя бы открывал. И там ничего не сказано о том, что bcrypt сам генерирует соль. Напротив, там указан такой формат вызова функции:
bcrypt(cost, salt, key, input), где input, при использовании стандартной функции crypt() в различных ОС равен константе «OrpheanBeholderScryDoubt».
salt An optional salt string to base the hashing on. If not provided, the behaviour is defined by the algorithm implementation and can lead to unexpected results.
И зачем же Вам в Вашем приложении нужен код, который приводит к непредсказуемому результату?!
Ну я и не призываю Гос. органы использовать этот шифр для сокрытия военных секретов, так же как я не призываю банки и платежные системы использовать этот шифр. Но для того, чтобы некто Вася смог спрятать свои файлы на компьютере, или чтобы какое-то web-приложение шифровало трафик от клиента к серверу, этого шифра более, чем достаточно. И потом, не так уж он и малоизвестен.
Ага, у меня это был PHP-скрипт, процессор: core i3. Так что о реализациях на компилируемых языках с применением GPU и говорить не приходится — 200-500 млн. вполне реальная цифра.
Вы не так понимаете. Суть соли не в том, что ее никто не знает. Напротив, соль не следует прятать. Соль нужна для того, чтобы сделать невозможным применение заранее сгенерированных радужных таблиц, а также для того, чтобы максимально усложнить жизнь хакеру, если он решит сбрутить пароли пользователей.
Скорее наоборот. Хакеров в большинстве случаев будут интересовать все пользователи, вернее, как можно больше пользователей. Зачем? Потому что есть большая вероятность того, что пароли, украденные с какого-либо сайта, подойдут к email-ам, указанным пользователя на том же сайте. А это спам, это связанные аккаунты в социальных сетях, в которых, опять же, спам.
А вот ситуацию, при которой с сайта крадут базу данных, чтобы найти пароль какого-то одного пользователя, мне как-то сложно представить — цель не оправдывает средства.
Пример про 7 дней у меня чисто гипотетический, с реальным временем ничего общего не имеет и ни на какие конкретные функции не ориентирован.
Если хакера интересует один конкретный пользователь, то, естественно, выигрыша нет. И если в системе предполагается лишь один пользователь, то соль можно хранить хоть в конфиге, хоть в самом коде (хотя это и не гибко).
Ну а если у вас в системе предполагается много пользователей, то хоть тут-то Вы видите преимущества разной соли для каждого пользователя?
и что дальше? вы радужную таблицу сами будете генерировать? хм, сомневаюсь
Почему сомневаетесь? На моем скромном ноутбуке, скриптом на PHP у меня генерируется примерно 1,7 млн. MD5-хэшей в секунду. Так что сгенерировать радужные таблицы по словарю или перебором коротких паролей с любой солью — задача не такая уж и невыполнимая.
все сводится к: узнать алгоритм применения соли + сам пароль, так?
Нет, не так. По-умолчанию всегда считаем, что алгоритм известен.
и что?
Т.е., по-Вашему, нет разницы, применить ли один раз брутфорс и тем самым получить пароли всех пользователей сразу, или для каждого пользователя запускать брутфорс заново? По-моему, очевидно, что во втором случае хакер потеряет времени больше во столько раз, сколько в базе пользователей!
Т.е. если у нас одна соль на всех, и хакер может генерировать радужную таблицу для словаря и недлинных алфавитно-цифровых паролей за 7 дней, то именно 7 дней у него уйдет на взлом всех пользователей. Если же соль для каждого пользователя разная, то 7 дней (ну чуть меньше) у хакера уйдет на взлом одного пользователя! А если пользователей 1000, то на из взлом потребуется уже 7000 дней, т.е. почти 20 лет!
А если еще и использовать действительно медленный алгоритм для получения хэша пароля, чтобы в секунду хакер мог генерировать не миллионы значений, а сотни или даже десятки, то и одного пользователя таким образом взломать будет за приемлемое время невозможно.
Ну соль для каждого пользователя и вводится как раз на тот случай, чтобы даже имея полный доступ ко всему, настоящие пароли пользователей было получить невозможно, ну или, по крайней мере, очень сложно.
1. Нет соли — используем уже готовые радужные таблицы.
2. Есть одна на всех соль — генерируем одну радужную таблицу и «ломаем» по ней всех пользователей.
3. Есть отдельная соль для каждого пользователя — отдельно брутфорсим каждого пользователя.
Ну я же так и написал: «В реальности нужно использовать что-либо более проверенное и признанное».
Какой смысл использовать шифр Anubis — я не знаю. Возможно, кто-нибудь найдет ему применение, почему бы и нет?
Зато я знаю, что для меня был смысл писать эту реализацию — опыт, расширение кругозора. В частности, пока все сам не сделал, я не совсем понимал, что значит CBC и зачем он нужен, что можно сделать с последним блоком, зачем нужен какой-то вектор инициализации, и т.п.
Можно ожидать, что он защищен не менее, чем Rijndael, т.к. является его разновидностью, оптимизированной для более простого и быстрого аппаратного исполнения. В конце концов, создан Anubis не студентом Петей на «лабах» по Защите информации. Шифр претендовал на участие в NESSIE, он детально описан и изучался как претендент. Отклонен он был лишь потому, что является близнецом Rijndael, не имеющим перед последним сколь-нибудь значимых преимуществ.
Хотя, конечно, в реальности нужно использовать что-либо более проверенное и признанное. Например, AES. Тем более, что в PHP это делается очень просто, используя функции расширения Mcrypt.
Тем не менее, как заметил пользователь RubtsovAV, если соль не задавать (не параметр функции crypt(), а именно соль в строке $2a$cost$salt), то по-умолчанию будет использоваться строка, состоящая из знаков $. Так что не указывать соль, как предлагает Lockal, нельзя.
Хотя бы открывал. И там ничего не сказано о том, что bcrypt сам генерирует соль. Напротив, там указан такой формат вызова функции:
bcrypt(cost, salt, key, input), где input, при использовании стандартной функции crypt() в различных ОС равен константе «OrpheanBeholderScryDoubt».Как видим, параметр salt очень даже присутствует.
И зачем же Вам в Вашем приложении нужен код, который приводит к непредсказуемому результату?!
Посмотрите вот этот комментарий: habrahabr.ru/post/145648/#comment_4894759 и дискуссию, возникшую на его основе.
А вот ситуацию, при которой с сайта крадут базу данных, чтобы найти пароль какого-то одного пользователя, мне как-то сложно представить — цель не оправдывает средства.
Если хакера интересует один конкретный пользователь, то, естественно, выигрыша нет. И если в системе предполагается лишь один пользователь, то соль можно хранить хоть в конфиге, хоть в самом коде (хотя это и не гибко).
Ну а если у вас в системе предполагается много пользователей, то хоть тут-то Вы видите преимущества разной соли для каждого пользователя?
Нет, не так. По-умолчанию всегда считаем, что алгоритм известен.
Т.е., по-Вашему, нет разницы, применить ли один раз брутфорс и тем самым получить пароли всех пользователей сразу, или для каждого пользователя запускать брутфорс заново? По-моему, очевидно, что во втором случае хакер потеряет времени больше во столько раз, сколько в базе пользователей!
Т.е. если у нас одна соль на всех, и хакер может генерировать радужную таблицу для словаря и недлинных алфавитно-цифровых паролей за 7 дней, то именно 7 дней у него уйдет на взлом всех пользователей. Если же соль для каждого пользователя разная, то 7 дней (ну чуть меньше) у хакера уйдет на взлом одного пользователя! А если пользователей 1000, то на из взлом потребуется уже 7000 дней, т.е. почти 20 лет!
А если еще и использовать действительно медленный алгоритм для получения хэша пароля, чтобы в секунду хакер мог генерировать не миллионы значений, а сотни или даже десятки, то и одного пользователя таким образом взломать будет за приемлемое время невозможно.
1. Нет соли — используем уже готовые радужные таблицы.
2. Есть одна на всех соль — генерируем одну радужную таблицу и «ломаем» по ней всех пользователей.
3. Есть отдельная соль для каждого пользователя — отдельно брутфорсим каждого пользователя.
Какой смысл использовать шифр Anubis — я не знаю. Возможно, кто-нибудь найдет ему применение, почему бы и нет?
Зато я знаю, что для меня был смысл писать эту реализацию — опыт, расширение кругозора. В частности, пока все сам не сделал, я не совсем понимал, что значит CBC и зачем он нужен, что можно сделать с последним блоком, зачем нужен какой-то вектор инициализации, и т.п.
Хотя, конечно, в реальности нужно использовать что-либо более проверенное и признанное. Например, AES. Тем более, что в PHP это делается очень просто, используя функции расширения Mcrypt.