Как пароль солит справку против нападения таблицы радуги?
Есть так много ответов для PHP и MySQL, но вот код для PHP и Oracle для предотвращения SQL-инъекций, а также регулярное использование драйверов oci8:
$conn = oci_connect($username, $password, $connection_string);
$stmt = oci_parse($conn, 'UPDATE table SET field = :xx WHERE ID = 123');
oci_bind_by_name($stmt, ':xx', $fieldval);
oci_execute($stmt);
9 ответов
Общедоступная соль будет не , делают атаки с подбором по словарю тяжелее при взламывании единого пароля. Как Вы указали, у взломщика есть доступ и к хешированному паролю и к соли, поэтому при выполнении атаки с подбором по словарю, она может просто использовать известную соль при попытке взломать пароль.
соль общественности А делает две вещи: делает его более трудоемким для взламывания большого списка паролей и делает неосуществимым использовать таблицу радуги.
Для понимания первого вообразите файл единого пароля, который содержит сотни имен пользователей и паролей. Без соли я мог вычислить "md5 (попытка [0])", и затем просканировать через файл, чтобы видеть, рубит ли это шоу где-нибудь. Если соли присутствуют, то я должен вычислить "md5 (соль. попытка [0])", выдерживают сравнение с записью A, тогда "md5 (соль [b]. попытка [0])", выдерживают сравнение с записью B, и т.д. Теперь, у меня есть в 110 раз больше работы, чтобы сделать, где n количество имен пользователей и паролей, содержавшихся в файле.
Для понимания второго необходимо понять, какова таблица радуги. Таблица радуги является большим списком предварительно вычисленных хешей для наиболее часто используемых паролей. Вообразите снова файл паролей без солей. Все, что я должен сделать, проходят каждую строку файла, вытаскивают хешированный пароль и ищут его в таблице радуги. Я никогда не должен вычислять единственный хеш. Если поиск будет значительно быстрее, чем хеш-функция (который это, вероятно), это значительно ускорит взламывание файла.
, Но если бы файл паролей посолился, то таблица радуги должна была бы содержать "соль. пароль" предварительно хешируется. Если соль достаточно случайна, это очень маловероятно. У меня, вероятно, будут вещи как "привет" и "foobar" и "стандартное расположение букв на клавиатуре" в моем списке наиболее часто используемых, предварительно хешированных паролей (таблица радуги), но я не собираюсь иметь вещи как "jX95psDZhello" или "LPgB0sdgxfoobar" или предварительно вычисленный "dZVUABJtqwerty". Это сделало бы таблицу радуги предельно большой.
Так, соль уменьшает взломщика назад до one-computation-per-row-per-attempt, который, когда вместе с достаточно долгим, достаточно случайным паролем, (вообще говоря), невскрываем.
Идея с солью состоит в том, чтобы сделать его намного тяжелее для предположения с "в лоб", чем нормальный символьно-ориентированный пароль. Таблицы радуги часто создаются с набором специального символа в памяти и не всегда включают весь возможные комбинации (хотя они могут).
, Таким образом, хорошее соленое значение было бы случайным 128-разрядным или более длинным целым числом. Это - то, что делает сбой нападений таблицы радуги. При помощи различного соленого значения для каждого сохраненного пароля Вы также удостоверяетесь, что таблица радуги создала для одного конкретного соленого значения (как мог иметь место, если Вы - популярная система с единственным соленым значением), не предоставляет Вам доступ ко всем паролям сразу.
Другие ответы, кажется, не обращаются к Вашим неверным толкованиям темы, таким образом, здесь идет:
Два различного использования соли
я видел, что много учебных руководств предполагают что соль, которая будет использоваться в качестве следующего:
$hash = md5($salt.$password)[...]
другое использование, которое я видел, находится в моей системе Linux. В/etc/shadow хешированные пароли на самом деле снабжены солью.
всегда необходимо снабдить соль паролем, потому что для проверки то, что пользователь, вводимый против базы данных пароля, необходимо объединить вход с солью, хешируйте его и сравните его с сохраненным хешем.
безопасность хеша
Теперь кто-то с таблицей радуги мог инвертировать хеш и придумать вход "foobar".
[...]
, так как обратный хеш te5SBM.7C25fFDu6bIRbX, как известно, содержит "нечто".
не возможно инвертировать хеш как таковой (в теории, по крайней мере). Хеш "нечто" и хеш "saltfoo" имеют ничто вместе. Изменение даже одного бита во входе криптографической хеш-функции должно полностью изменить вывод.
Это означает, что Вы не можете создать таблицу радуги с общими паролями и затем более поздним "обновлением" это с небольшим количеством соли. Необходимо принять соль во внимание с начала.
Это - целая причина того, почему Вам нужна таблица радуги во-первых. Поскольку Вы не можете добраться до пароля от хеша, Вы предварительно вычисляете все хеши наиболее вероятных используемых паролей и затем сравниваете Ваши хеши с их хешами.
Качество соли
, Но говорит
$salt=foo
, "нечто" было бы чрезвычайно плохой выбор соли. Обычно Вы использовали бы случайное значение, закодированное в ASCII.
кроме того, каждый пароль имеет свою собственную соль, отличающуюся (надо надеяться), от всех других солей в системе. Это означает, что взломщик должен напасть на каждый пароль индивидуально вместо того, чтобы иметь надежду, которая один из хешей соответствует одному из значений в ее базе данных.
нападение
, Если хакер так или иначе смог достать этот файл, я не вижу, какая цель соленые подачи,
нападение таблицы радуги А всегда потребности /etc/passwd (или независимо от того, что база данных пароля используется), или иначе как Вы сравнили бы хеши в таблице радуги к хешам фактических паролей?
Что касается цели: скажем, взломщик хочет создать таблицу радуги для 100 000 наиболее часто используемых английских слов, и типичные пароли (думайте "секрет"). Без соли она должна была бы предварительно вычислить 100 000 хешей. Даже с традиционной солью UNIX 2 символов (каждый - один из 64 вариантов: [a–zA–Z0–9./]), она должна была бы вычислить и сохранить 4,096,000,000 хешей... настоящее улучшение.
Еще один большой вопрос, со многими очень вдумчивыми ответами - +1 к ТАК!
Одна маленькая точка, которую я не видел упомянутый явно, - то, что путем добавления случайной соли к каждому паролю Вы фактически гарантируете, что два пользователи, которые, оказалось, выбрали тот же пароль, произведут различные хеши.
, Почему это важно?
Воображают базу данных пароля в крупной компании-разработчике программного обеспечения в северо-западных США. Предположим, что это содержит 30 000 записей, из которых 500 имеют пароль bluescreen . Предположим далее, что хакеру удается получить этот пароль, сказать путем чтения его в электронном письме от пользователя в отдел ИТ. Если пароли являются несолеными, хакер может найти, что хешированное значение в базе данных, то просто соответствие шаблона это получает доступ к другим 499 учетным записям.
Соление паролей гарантирует, что каждая из 500 учетных записей имеет уникальное (salt+password), генерируя различный хеш для каждого из них, и таким образом уменьшая нарушение до единственной учетной записи. И давайте надеяться против всей вероятности, что у любого пользователя, достаточно наивного для записи незашифрованного пароля в электронном письме, нет доступа к недокументированному API для следующей ОС.
Причина соль может сделать сбой нападения таблицы радуги, состоит в том, что для n-битов соли, таблица радуги должна быть 2^n времена, больше, чем размер таблицы без соли.
Ваш пример использования 'нечто', поскольку соль могла сделать миллион раз таблицы радуги 16 больше.
Данный пример Carl 128-разрядной соли, это делает времена таблицы 2^128 больше - теперь это является большим - или помещенный иначе, сколько времени, прежде чем у кого-то будет портативное устройство хранения данных, настолько большое?
Одна цель посолить состоит в том, чтобы победить предварительно вычисленные хэш-таблицы. Если у кого-то есть список миллионов предварительно вычисленных хешей, они не собираются быть способными искать $foo$te5SBM.7C25fFDu6bIRbX1 за 1$ в их таблице даже при том, что они знают хеш и соль. У них все еще будет к грубой силе он.
Другая цель, поскольку Carl S упоминания должен сделать скота, вызывающего список хешей более дорогой. (дайте им всем различные соли)
Обе из этих целей все еще выполняются, даже если соли общедоступны.
Большинство методов повреждения основанного на хеше шифрования полагается на атаки перебором. Нападение радуги является по существу более эффективной атакой с подбором по словарю, оно разработано для использования низкой стоимости цифрового устройства хранения данных, чтобы включить создание карты существенного подмножества возможных паролей к хешам и упростить обратное отображение. Этот вид нападения работает, потому что много паролей имеют тенденцию быть или довольно короткими или использовать один из нескольких шаблонов основанных на слове форматов.
Такие нападения неэффективны в случае, где пароли содержат намного больше символов и не соответствуют основанным на общем слове форматам. Пользователь с сильным паролем для запуска с не будет уязвим для этого стиля нападения. К сожалению, многие люди не выбирают хорошие пароли. Но существует компромисс, можно улучшить пароль пользователя путем добавления случайного спама к нему. Таким образом, теперь вместо "hunter2" их пароль мог стать эффективно "hunter2908! fld2R75 {R7/; 508PEzoz^U430", который является намного более сильным паролем. Однако, потому что теперь необходимо сохранить этот дополнительный компонент пароля, это уменьшает эффективность более сильного составного пароля. Как оказалось, существует все еще чистая прибыль к такой схеме с тех пор теперь, каждый пароль, даже слабые, больше не уязвим для того же предварительно вычисленного хеша / таблица радуги. Вместо этого каждая запись хэша пароля уязвима только для уникальной хэш-таблицы.
Говорят, что у Вас есть сайт, который имеет требования к силе слабого пароля. Если Вы не используете соли пароля во всех своих хешах, уязвимы для предварительно вычисленных хэш-таблиц, у кого-то с доступом к Вашим хешам таким образом был бы доступ к паролям для большого процента Ваших пользователей (однако много используемых уязвимых паролей, которые будут существенным процентом). Если бы Вы используете постоянную соль пароля, тогда предварительно вычислил хэш-таблицы, больше не ценны, таким образом, кто-то должен был бы провести время для вычисления пользовательской хэш-таблицы для той соли, они могли сделать так инкрементно, хотя, вычислительные таблицы, которые покрывают еще большие перестановки пространства задач. Самые уязвимые пароли (например, простые основанные на слове пароли, очень короткие алфавитно-цифровые пароли) были бы взломаны в часах или днях, менее уязвимые пароли будут взломаны после нескольких недель или месяцев. Со временем взломщик получил бы доступ к паролям для когда-либо растущего процента Ваших пользователей. При использовании уникальной соли для каждого пароля тогда, потребовались бы дни или месяцы для получения доступа к каждому из тех уязвимых паролей.
, Как Вы видите, когда Вы не повышаетесь ни от какой соли до постоянной соли к уникальной соли, Вы налагаете несколько увеличений порядков величины усилия взломать уязвимые пароли на каждом шаге. Без соли самые слабые из паролей Ваших пользователей тривиально доступны с постоянной солью, те слабые пароли доступны для решительного взломщика с уникальной солью, стоимость доступа к паролям повышена настолько высоко, что только самый решительный взломщик мог получить доступ к крошечному подмножеству уязвимых паролей, и затем только за большой счет.
, Который является точно ситуацией, чтобы быть в. Вы никогда не можете полностью защищать пользователей от плохого выбора пароля, но можно повысить стоимость заключения компромисса паролей пользователей к уровню, который делает заключение компромисса даже паролем одного пользователя предельно дорогой.
Насколько я знаю, соль предназначается для создания атак с подбором по словарю тяжелее.
Это - известное то, что многие люди будут использовать общие слова для паролей вместо на вид случайных строк.
Так, хакер мог использовать это в его интересах вместо того, чтобы использовать просто грубую силу. Он не будет искать пароли как aaa, aab, aac..., но вместо этого использовать слова и общие пароли (как лорд кольцевых имен!;))
Поэтому, если моим паролем является Legolas, хакер мог бы попробовать это и предположить его с "небольшое количество" попытки. Однако, если мы солим пароль, и это становится fooLegolas, хеш будет отличаться, таким образом, атака с подбором по словарю будет неудачна.
Hope, которая помогает!
Я предполагаю, что Вы используете PHP---md5 () функция, и $ предшествовал переменным---тогда, можно попытаться смотреть это ПРАКТИЧЕСКОЕ РУКОВОДСТВО Пароля Тени статьи Особенно 11-й абзац.
кроме того, Вы боитесь использования алгоритмов выборки сообщений, можно попробовать реальные алгоритмы шифра, такие как те предоставленные модуль mcrypt или больше более сильных алгоритмов выборки сообщений, таких как те, которые обеспечивают модуль mhash (sha1, sha256, и другие).
я думаю, что более сильный алгоритм выборки сообщений - необходимость. Известно, что MD5 и SHA1 имеют проблемы коллизии.