Зачем использовать blowfish для паролей?

Я немного запутался в хранении паролей. Допустим, у меня есть база данных с таблицей учетных записей пользователей. И это место, где я храню пароли. В настоящее время я использую соленый ша1.

Я читал, что функции на основе Blowfish лучше, чем sha1, потому что им нужно больше времени для обработки запроса.

Есть ли причина, почему бы не использовать соленый sha1 и просто ограничить количество попыток входа в систему до некоторого разумного числа (например, 50 раз в час) в качестве «брандмауэра» для атак грубой силы?

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


passwords hash blowfish
person Tomek    schedule 30.10.2012    source источник
comment
@paddy Simple SHA-2 бит предназначен для хеширования паролей, это быстро. Если вы хотите использовать SHA-2, вам необходимо использовать PBKDF-SHA-2 или алгоритмы шифрования на основе SHA-2. BCrypt (который OP ошибочно назвал Blowfish) разработан для хеширования паролей и работает медленно. Даже при использовании эквивалентного коэффициента работы bcrypt лучше, чем алгоритмы на основе SHA-2.   -  person CodesInChaos    schedule 01.11.2012

Ответы (3)


arrow_upward
5
arrow_downward

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

Имея стандартный графический процессор, вы можете рассчитывать примерно 3 гига хеш-значений на во-вторых, вы можете подобрать полный английский словарь с 5'000'000 слов менее чем за 2 миллисекунды. Даже если SHA-1 является безопасной хеш-функцией, это делает его непригодным для хеширования паролей.

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

Ваша точка зрения об ограничении попыток входа в систему имеет смысл, но хеширование должно защищать пароли в случае, если злоумышленник имеет доступ к базе данных (SQL-инъекция). Конечно, вы можете ограничить попытки входа в систему, но это не имеет ничего общего с хешированием, вы даже можете хранить пароли в открытом виде в этом сценарии.

person martinstoeckli    schedule 31.10.2012
comment
Это именно тот ответ, который я искал;) Потому что я был сбит с толку, почему алгоритм хеширования на стороне сервера лучше, когда он медленнее ... не думал о доступе к базе данных каким-либо другим способом (например, sqli). Я всегда запускаю все формы ввода через регулярное выражение, но вы никогда не знаете ...; p Теперь у меня есть другой вопрос. (я еще не углублялся в вашу статью) Если bcrypt - это хеш-алгоритм ... всегда ли результат функции bcrypt равен длине? (например, sha1 или md5). И мне нужно искать bcrypt для php. (php имеет только 'crypt' и 'hash' функции ... но я не уверен, как они работают. А как насчет столкновений в bcrypt - person Tomek; 31.10.2012
comment
@Tomek - вывод BCrypt всегда представляет собой строку длиной 60 символов (включая соль и коэффициент стоимости). Взгляните на предоставленную ссылку, вы найдете руководство, а также информацию о реализации PHP (поясняется crypt, рекомендуется PHPass), и вы можете поиграть с SQL-инъекцией. Кстати, вы всегда должны избегать ввода пользователя, прежде чем добавлять его в SQL (с mysqli_real_escape_string()), регулярное выражение подходит только для проверки ввода пользователя. - person martinstoeckli; 31.10.2012
comment
Но что, если символы, которые «нужно экранировать», вообще запрещены? Прочитал вашу статью. И вот теперь у меня вопрос, почему соль хранится незащищенной. Например; если кто-то взломал базу данных и получил хэш и соль, он может использовать грубую силу, используя словарь и добавляя / добавляя соль к каждому слову из словаря - person Tomek; 31.10.2012
comment
@Tomek - в этом случае, допустим, вы подтвердили адрес электронной почты, вам не нужно избегать ввода пользователя, но это не повредит, если вы это сделаете. Обычно экранирование всех строковых значений - это хорошо, лучше избежать ненужного случая, чем забыть его. - person martinstoeckli; 31.10.2012
comment
Ты прав. Я изучил код PHP-части вашей страницы и обнаружил ошибку в объекте «словарь» для массивов. Вы используете isset (), чтобы проверить, есть ли array_key_exists. Это неверно, так как $ a ['null'] = NULL; isset ($ a ['null']) вернет FALSE, когда array_key_exists ('null', $ a) вернет TRUE (поскольку ключ массива действительно существует) - person Tomek; 31.10.2012
comment
@Tomek - я вижу, что вы внимательно прочитали страницу, спасибо за комментарий! В данном случае это особенность :-), если вы посмотрите комментарий к setValue(), он гласит: Значение null удалит ключ. Согласно множеству статей в Интернете, функция array_key_exists() может работать очень медленно. - person martinstoeckli; 31.10.2012
comment
да. но в этом разница между unset (array [key]) и array [key] = null. для массивов поведение сборщика мусора кажется другим ... Вернемся к криптографии: правильно ли я понимаю концепцию соли и перца? Когда я использую blowfish, функция занимает 22 символа соли ... эта «соль», которую я даю функции, - это просто соль или соль + перец? ;) так что мне нужно смешать (например, длинную соль из 15 знаков с длинным перцем из 7 знаков), прежде чем использовать bcrypt? - person Tomek; 31.10.2012
comment
@Tomek - Нет, соль - это просто соль и обычно будет добавляться самой функцией BCrypt (она создает случайную строку из 22 символов). Соль видна в полученном хеш-значении и будет сохранена в базе данных. Перец никогда не должен попадать в базу данных, вы можете добавить его к паролю перед хешированием, чтобы он запутался. - person martinstoeckli; 31.10.2012
comment
@Tomek - только что завершил реализацию Bcrypt с необязательным перцем, чтобы показать использование. - person martinstoeckli; 31.10.2012
comment
Кстати. Я заметил, что вы используете функцию в своем bcrypt. Я поместил это в класс. Кстати. Использование die для вывода сообщения об ошибке - это метод old_school из не объектно-ориентированного php. Попробуйте использовать исключения. Что-то вроде этого. Если (! $ Something) генерирует новое исключение. ;) что помогает в больших проектах. - person Tomek; 31.10.2012
comment
@Tomek - Спасибо за ваши предложения. Хорошо создать класс из функций, они на самом деле где класс в первую очередь. Затем я решил сделать отдельные функции, потому что хочу представить свои примеры как можно более простыми и легкими для понимания. Сделать из него класс легко, но представление класса поднимет планку для некоторых разработчиков. Я намерен прислушаться к вашему совету с unset(). - person martinstoeckli; 01.11.2012
comment
В качестве примечания: предстоящая версия php будет включать простой в использовании API хеширования паролей на основе bcrypt. - person CodesInChaos; 01.11.2012
comment
@CodesInChaos - Да, это были хорошие новости, это будет частью PHP 5.5. - person martinstoeckli; 01.11.2012

arrow_upward
1
arrow_downward

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

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

Если вам действительно требуется двустороннее шифрование по какой-либо причине, помимо Blowfish, AES-256 (Rijndael) или Twofish в настоящее время также достаточно безопасны. для обработки конфиденциальных данных. Не забывайте, что вы можете использовать несколько алгоритмов для хранения зашифрованных данных.

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

Короче

  • Используйте одностороннее хеширование для хранения паролей, разрешите пользователям сбрасывать их по электронной почте.
  • Не бойтесь использовать несколько методов для хранения зашифрованных данных
  • Если вам необходимо использовать схему шифрования / дешифрования, храните свои ключи в безопасности и используйте только проверенные алгоритмы.
  • Предотвращение атак методом грубой силы - это хороший образ мышления, но он только замедлит кого-то или побудит его искать другие точки входа.

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

Источник: Википедия, http://eprint.iacr.org/2005/010.

person abestic9    schedule 30.10.2012
comment
Я полагаю, что OP имел в виду BCrypt с функцией на основе Blowfish, а не саму функцию шифрования. Как и SHA-1, функция SHA-256 слишком быстрая для хеширования паролей и позволяет легко подбирать пароли. - person martinstoeckli; 31.10.2012

arrow_upward
0
arrow_downward

Есть ли причина, почему бы не использовать соленый sha1 и просто ограничить количество попыток входа в систему до некоторого разумного числа (например, 50 раз в час) в качестве «брандмауэра» для атак грубой силы?

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

Почему небезопасно "просто" блокировать попытки входа в систему?

Ну, помимо того факта, что вам нужно блокировать КАЖДЫЙ возможный вход, например:

  • ssh
  • веб-сервисы (ваше веб-приложение, phpmyadmin, openpanel и т. д.)
  • ftp
  • многое другое

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

Может быть, кто-то еще сможет пролить свет на обсуждение Blowfish и SHA, хотя я сомневаюсь, что эта часть представляет собой сложный отформатированный вопрос.

person Hedde van der Heide    schedule 30.10.2012