it-swarm-ru.tech

Является ли time () хорошей солью?

Я смотрю на код, который сам не написал. Код пытается хэшировать пароль с SHA512 и использует только time() в качестве соли. Является ли time() просто солью для этого или этот код безопасен?

Спасибо за ответы и комментарии. Я подведу итоги здесь для новых читателей:

  • соль должна отличаться для каждого пользователя, поэтому, если 2 пользователя регистрируются одновременно, их соли не будут уникальными. Это проблема, но не большая.
  • но соль не должна быть связана с пользователем, поэтому time () не является хорошей солью.
  • "Используйте случайную, равномерно распределенную, соль с высокой энтропией." - Это глоток, так какой код может генерировать соль random, evenly distributed, high entropy?

Хорошо, так как насчет того, чтобы заменить time () случайной строкой длиной 32 символа. Случайная строка может быть сгенерирована из цикла 32 раза для набора символов алфавита. Это звучит хорошо?

56
zmol

Краткий ответ:

Нет, time() не очень хорошая соль.

Длинный ответ:

скопировано из моего ответа на Генерация соли и программное обеспечение с открытым исходным кодом

Что такое соль?

Соль - это случайный набор байтов фиксированной длины, который добавляется на вход алгоритма хеширования.


Почему соление (или посев) полезно?

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

  1. Соление значительно увеличивает сложность/стоимость заранее вычисленных атак (включая Радужные таблицы )
  2. Salting гарантирует, что один и тот же пароль не приведет к тому же хешу. Это гарантирует, что вы не сможете определить, имеют ли два пользователя один и тот же пароль. И , что еще более важно , вы не можете определить, использует ли один и тот же человек один и тот же пароль в разных системах.
  3. Соление увеличивает сложность паролей, тем самым значительно снижая эффективность обоих Словарь - а также День рождения нападает,. (Это верно только в том случае, если соль хранится отдельно от хеша).
  4. Правильное засоление значительно увеличивает потребность в хранилище для предварительных вычислений, вплоть до того момента, когда они более не практичны. (8-символьные буквенно-цифровые пароли с учетом регистра с 16-битной солью, хэшированные до 128-битного значения, будут занимать чуть меньше 2exabytes без сокращения Rainbow).


Нет необходимости в секрете соли.

Соль - это не секретный ключ, а соль "работает", делая хеш-функцию специфичной для каждого экземпляра. Для хеш-функции с соленым хэшем не существует одной хеш-функции, а одна для каждого возможного значения соли. Это не позволяет атакующему атаковать N хешированные пароли менее чем N раз стоимость атаки одного пароля. Это точка соли.
"Секретная соль" - это не соль, она называется "ключом", и это означает, что вы больше не вычисляете хеш, а Код аутентификации сообщения (MAC) , Вычисление MAC - дело сложное (гораздо сложнее, чем просто сложить ключ и значение в хэш-функцию), и это совсем другой вопрос.

Соль должна быть случайной для каждого экземпляра, в котором она используется. Это гарантирует, что атакующий должен атаковать каждый соленый хеш отдельно.
Если вы полагаетесь на то, что ваша соль (или алгоритм соления) является секретной, вы вводите области Безопасность через неизвестность (не будет работать). Скорее всего, вы не получаете дополнительной защиты от соляной тайны; Вы просто получаете теплое нечеткое чувство безопасности. Таким образом, вместо того, чтобы сделать вашу систему более безопасной, она просто отвлекает вас от реальности.


Итак, почему соль должна быть случайной?

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

Соблазнительно попытаться извлечь соль из некоторых данных, которые "предположительно уникальны", таких как идентификатор пользователя, но такие схемы часто терпят неудачу из-за некоторых неприятных деталей:

  1. Если вы используете , например, идентификатор пользователя , некоторые плохие парни, атакующие отдельные системы, могут просто объединить свои ресурсы и создать предварительно вычисленные таблицы для идентификаторов пользователей от 1 до 50. . Идентификатор пользователя уникален для всей системы , но не для всего мира .

  2. То же самое относится к имени пользователя : для каждой системы Unix существует один "корень", но в мире много корней. Радужный стол для "корня" стоил бы усилий, поскольку его можно применять к миллионам систем. Хуже того, есть также много "бобов", и у многих нет обучения сисадминам: их пароли могут быть довольно слабыми.

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

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


В заключение:

Используйте случайную, равномерно распределенную соль с высокой энтропией. Используйте новую соль всякий раз, когда вы создаете новый пароль или меняете пароль. Храните соль вместе с хешированным паролем. Пользуйтесь большими солями (не менее 10 байт, предпочтительно 16 или более).

Соль не превращает плохой пароль в хороший пароль. Это просто гарантирует, что злоумышленник по крайней мере заплатит цену атаки по словарю за каждый неверный пароль, который он взламывает.


Полезные источники:
stackoverflow.com: Неслучайная соль для хэшей паролей
Брюс Шнайер: Практическая криптография (книга)
Matasano Security: Достаточно с радужными таблицами
senix.org: Использованная соль Unix crypt с 1976 г.
owasp.org : Зачем добавлять соль
openwall.com : Соли

Отказ от ответственности:
Я не эксперт по безопасности. (Хотя этот ответ был рассмотрен Томас Порнин )
Если кто-то из специалистов по безопасности найдет что-то не так, пожалуйста, прокомментируйте или отредактируйте этот вики-ответ.


Что касается того, что кажется хорошим источником для вашей случайной соли
Также читайте: Какое самое безопасное начальное число для генерации случайных чисел?
В отсутствие выделенных аппаратных случайных генераторов лучшим способом получения случайных данных является обращение к операционной системе (в Linux это называется /dev/random или /dev/urandom [у обоих есть свои преимущества и проблемы, выберите свой яд) ]; в Windows вызовите CryptGenRandom())

Если по какой-то причине у вас нет доступа к вышеупомянутым случайным источникам, в PHP вы можете использовать следующую функцию:
Из источника phpass v0.

<?php
/**
 * Generate pseudo random bits
 * @copyright: public domain
 * @link http://www.openwall.com/phpass/
 * @param int $length number of bits to generate
 * @return string A string with the hexadecimal number
 * @note don't try to improve this, you will likely just ruin it
 */
function random_bits($entropy) {
    $entropy /= 8;
    $state = uniqid();
    $str = '';
    for ($i = 0; $i < $entropy; $i += 16) {
        $state = md5(microtime().$state);
        $str .= md5($state, true);
    }
    $str = unpack('H*', substr($str, 0, $entropy));
    // for some weird reason, on some machines 32 bits binary data comes out as 65! hex characters!?
    // so, added the substr
    return substr(str_pad($str[1], $entropy*2, '0'), 0, $entropy*2);
}
?>
83
Jacco

Этот пост может отклониться от вашего первоначального вопроса, но я надеюсь, что вы найдете его полезным;

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

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

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

В реальном мире хранение соли в базе данных (случайное или нет), вероятно, менее безопасно, чем использование постоянной соли и ее скрытие от глаз пользователя в файле, недоступном через веб-браузер. Трудно угадать уникальную соль с высокой энтропией, но если вы разрешили вход в систему с любого сервера на MySql и установили пароль на "пароль", это на самом деле не имеет значения! Покажите, как легко взломать базу данных по сравнению с получением действительного имени входа на ваш сервер - что, возможно, труднее сделать дискретно, так как вы можете установить fail2ban и множество других средств наблюдения за векторами атаки в зависимости от вашей настройки.

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

Другая альтернативная рекомендация экспертов по безопасности - хранить имя пользователя в отдельной базе данных (и в идеале с другой технологией) для пароля и ссылаться между ними, используя UUID. Например. использовать как MySQL, так и SQLite. Это означает, что обе базы данных должны быть взломаны (а также, поэтому, чтобы перейти к отдельной кроличьей норе ради примера, не следует хранить данные пользователя и номера кредитных карт в одной базе данных, поскольку одна из них бесполезна без другой).

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

Убедитесь, что вы применяете надежные пароли и имена пользователей, чтобы атаки по словарю не сработали; Мне известны словари для всех 6-буквенно-цифровых комбинаций записей имени пользователя и пароля для MD5, и я подозреваю, что есть больше, чем это доступно для всех видов алгоритмов. С появлением недорогих облачных и CPGPU-вычислений размер и сложность доступных словарей будет стремительно расти.

В конечном счете, самый безопасный способ - никогда не генерировать соль программным способом, а требовать, чтобы пользователь вводил ее вместе со своим именем пользователя и паролем через ссылку SSL (поэтому ее нельзя было отследить), но никогда не сохранял ее. Это подход, принятый компаниями-эмитентами кредитных карт; то есть 3-значный ключ безопасности CSV на вашей кредитной карте, который вы должны вводить каждый раз при покупке через Интернет, поскольку он никогда не должен храниться в какой-либо базе данных. Если вы действительно хотите создать соль, отправьте ее им отдельно (например, через сообщение SMS или по электронной почте) и по-прежнему заставляйте их вводить ее каждый раз вручную. При таком подходе, хотя и более безопасном, вам необходимо сопоставить сложность с тем, не перестанут ли пользователи просто использовать сайт, поскольку вы сделали его слишком сложным для него.

Все вышеперечисленное по-прежнему основывается на том факте, что у вас также есть защита от перехвата сеансов, межсайтовых сценариев и т.д. И т.д. Самый сильный в мире алгоритм паролей не имеет значения, если все, что мне нужно сделать, - это вычислить действительный PHPSESSID для залогиненный пользователь и взломать его!

Я не эксперт по безопасности, но прочитал об этом столько, сколько я могу. Тот факт, что на эту тему так много книг, показывает, насколько велик ответ на ваш вопрос.

Несколько действительно хороших книг, которые вы могли бы попробовать, которые я нашел бесценными;

Уязвимости веб-приложений: обнаружение, использование, предотвращение - ISBN-13: 978-1-59749-209-6

Предотвращение веб-атак с помощью Apache - ISBN-13: 978-0-321-32128-2

2
Matt

Обновлено

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

  • Отличается для каждого пользователя
  • достаточно длинный (по крайней мере 8 буквенно-цифровых символов), чтобы сделать объединение соли и (потенциально слабого) пароля слишком длинным для атаки методом перебора.

Значения time() на самом деле недостаточно длинные, так как они имеют 10 символов, но только цифры.

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

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

2
Michael Borgwardt

Да.
Похоже, что метка времени Unix, хранящаяся в пользовательской базе данных как поле "Элемент с тех пор", будет солидной солью.

Тем не менее, солевой вопрос является наиболее незначительным. Есть гораздо более важные вещи, на которые вы должны обратить внимание:

  1. Скорее всего, ни пароль, ни соль, ни алгоритм хеширования не будут самой слабой частью вашего сайта. Некоторая инъекция хромого файла или XSS или CSRF, безусловно, есть. Так что, не делайте из этого слишком большого дела.
    Говорить об истинной случайной строке длиной 32 символа в типичном веб-приложении - все равно, что говорить о 32-дюймовой бронированной двери в деревянном сарае.

  2. Говоря о паролях, самая важная вещь - это сложность пароля. При слабом Пароль ни соль, ни алгоритм хеширования, даже супергениальный, невероятно сложный, могут помочь. Больно просить пользователей использовать сложный пароль, но без него все остальное становится м.
    Итак, вашей первой заботой должна быть сложность пароля. Требуется 12-16 символов другого регистра, включая цифры и знаки препинания.

  3. Что касается соли, Я не вижу пользы в использовании времени, так как вы должны хранить его вместе с другими пользовательскими данными. Лучше использовать электронную почту - она ​​достаточно случайная, и она у вас уже есть. Не забудьте перефразировать пароль, если пользователь меняет свою электронную почту. похоже, что Unix Timstamp будет достойной солью, не нужно использовать электронную почту или что-то еще.

Update
Как я вижу, многие люди до сих пор не могут понять суть.
Как тот парень из комментариев, говоря

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

Они заслуживают, без сомнения. Но со слабым паролем миссия. является. невозможно.

Если ваш пароль слабый, то соль не защитит его.

Хотя соль не так уж и важна, чтобы потратить 10-килобайтный текст на тему.

1
Your Common Sense

Нет, время () не очень хорошая соль

Лучше не изобретать колесо, когда дело доходит до аутентификации, но ответить на ваш вопрос no . Проблема со временем ():

  • Это предсказуемо и соотносится с потенциально обнаруживаемыми вещами. Эти проблемы облегчают перекрестное сопоставление различных хешированных результатов.
  • Возможных значений не очень много. Поскольку старшие биты не меняются, это еще более узкая соль, чем кажется на первый взгляд.
  • Использование повторяет предыдущие ошибки. Если это приложение было первым , которое использовало time () как соль, по крайней мере, это потребует новой атаки.
1
DigitalRoss

Нет! Никогда не используйте текущее время в качестве соли. Вы можете использовать что-то вроде 'SecureRandom' в Java для генерации случайной соли, которая является безопасной. Всегда используйте непредсказуемое случайное число в качестве соли.
Использование времени в качестве соли поможет вам удалить коллизии только до определенной степени (поскольку два пользователя могут одновременно использовать одни и те же пароли), но при этом сделать пароли восстанавливаемыми.

0
Ashwin

дата, когда участник присоединяется к форуму/веб-сайту, обычно имеет открытый доступ, что соответствует времени (), что делает вашу соль бесполезной.

0
Mr Coder

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

0
Eugene Mayevski 'Allied Bits