Являются ли соли бесполезными для безопасности, если злоумышленник знает их?

Допустим, у меня есть таблица пользователей, настроенная так:

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY,
    `name` TEXT,
    `hashed_password` TEXT,
    `salt` TEXT
)

Когда создается пользователь, случайно сгенерированная соль создается и сохраняется в базе данных вместе с результатами чего-то вроде get_hash(salt + plaintext_password).

Мне интересно, что если злоумышленник получит эти данные, сможет ли он использовать их для взлома паролей пользователей? Если да, то как это можно предотвратить?

10 голосов | спросил MiffTheFox 8 J000000Wednesday09 2009, 18:26:12

7 ответов


0

Нет, они не бесполезны.

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

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

ответил LukeH 8 J000000Wednesday09 2009, 18:28:50
0

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

ответил mfx 8 J000000Wednesday09 2009, 18:34:41
0

Знание соли позволяет проводить атаку грубой силой, но это не делает ее бесполезной. Соль не позволяет атакующему использовать уже созданную радужную таблицу (которую вы можете найти в Интернете).

Лучший способ предотвратить перебор - просто использовать длинные и сложные пароли.

ответил Zifre 8 J000000Wednesday09 2009, 18:31:01
0

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

ответил Mitch Wheat 8 J000000Wednesday09 2009, 18:28:43
0

Это должно дать вам представление о том, как это работает.

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

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

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

Тем не менее, они могут начать создавать свою собственную таблицу поиска с нуля, используя вашу соль, и в конечном итоге они смогут отменить пароли поиска.

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

ответил Kelly 8 J000000Wednesday09 2009, 18:43:36
0

Нет, это не бесполезно.

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

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

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

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

ответил Joel Coehoorn 8 J000000Wednesday09 2009, 18:35:55
0

Если предположить, что алгоритмы перебора MD5, SHA1, SHA256 и GPU грубой силой имеют пропускную способность более 1 млрд. попыток в секунду, а SHA512 - около 300 М /с. Если вы используете один из этих алгоритмов, это замедлит хакера, который использовал радужную таблицу (менее вероятно), но не замедлит хакера, который использовал атаку методом перебора (более вероятно). Это определенно не защитит вас, это просто добавит немного защиты от устаревшего радужного стола (для этого алгоритма). Немного лучше, чем ничего.

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

Посмотрите на это   статья и в заключение:

  

Если вы пользователь:

     

Убедитесь, что все ваши пароли состоят из 12 или более символов, в идеале намного больше. Я рекомендую использовать парольные фразы, которые не только намного легче запомнить, чем пароли (если не тип), но и смехотворно защищают от перебора просто из-за их длины.

     

Если вы разработчик:

     

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

     

Автор: Джефф Этвуд

ответил Nicolas Labrot 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 13 Sep 2013 20:53:17 +0400 2013, 20:53:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132