Как долго перебором подсоленной SHA-512 хэша? (соль, предоставляемых)
вот алгоритм на Java:
public String getHash(String password, String salt) throws Exception {
String input = password + salt;
MessageDigest md = MessageDigest.getInstance(SHA-512);
byte[] out = md.digest(input.getBytes());
return HexEncoder.toHex(out);
}
предположим, что соль известна. Я хочу знать время грубой силы, когда пароль является словарным словом, а также когда это не словарное слово.
3 ответов
в вашем случае нарушение хэш-алгоритма эквивалентно обнаружению столкновения в хэш-алгоритме. Это означает, что вам не нужно искать сам пароль (который был бы прообраза), вам просто нужно найти выход хэш-функции, который равен хэшу действительного пароля (таким образом, "столкновение"). Поиск столкновения с помощью день рождения атака принимает O(2^(n/2)) Время, где n-выходная длина хеш-функции в битах.
SHA-2 имеет выходной размер 512 бит, поэтому поиск столкновения займет O (2^256) времени. Учитывая, что нет умных атак на сам алгоритм (в настоящее время никто не известен для семейства хэшей SHA-2), это то, что нужно, чтобы сломать алгоритм.
чтобы почувствовать, что на самом деле означает 2^256: в настоящее время считается, что количество атомов в (целом!!!) Вселенная примерно 10^80, что примерно 2^266. Предполагая 32-байтовый вход (что разумно для ваш случай - 20 байт соли + 12 байт пароля) моя машина принимает ~0,22 s (~2^-2s) для 65536 (=2^16) вычислений. Таким образом, 2^256 вычислений будет сделано в 2^240 * 2^16 вычислений, которые будут принимать
2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years
даже называть это миллионы лет смешно. И это не намного лучше с самым быстрым оборудованием на планете, вычисляющим тысячи хэшей параллельно. Никакая человеческая технология не сможет превратить это число в нечто приемлемое.
Так что забудь грубое принуждение SHA-256 здесь. Следующий вопрос был о словарных словах. Чтобы получить такие слабые пароли радужные таблицы традиционно использовались. Радужная таблица обычно является просто таблицей предварительно вычисленных хэш-значений, идея заключается в том, что если вы смогли предварительно вычислить и сохранить каждый возможный хэш вместе с его входом, то вам потребуется O(1), чтобы найти данный хэш и получить действительный предварительный образ для него. Конечно, это невозможно на практике, так как нет устройства хранения может хранить такие огромные объемы данных. Эта дилемма известна как памяти-время компромисс. Поскольку вы можете хранить только так много значений, типичные радужные таблицы включают некоторую форму хэш-цепочки с промежуточными функциями сокращения (это подробно объясняется в статье Википедии), чтобы сэкономить место, отказавшись от некоторой экономии времени.
энтропия. Типичные варианты паролей обычно имеют низкую энтропию, тогда как полностью случайные значения содержат максимум энтропии.низкая энтропия типичных паролей делает возможным относительно высокую вероятность того, что один из ваших пользователей использует пароль из относительно небольшой базы данных общих паролей. Если вы google для них, вы в конечном итоге найти торрент-ссылки для таких баз данных паролей, часто в категории размера gigabyte. Успех с таким инструментом обычно находится в диапазоне от минут до дней, если злоумышленник не ограничен в каких-либо путь.
вот почему обычно хеширования и соления в одиночку недостаточно, вам также необходимо установить другие механизмы безопасности. Вы должны использовать искусственно замедленный метод энтропии, такой как PBKDF2, описанный в PKCS#5 и вы должны применить срок ожидания для данного пользователя, прежде чем они могут повторить попытку ввода пароля. Хорошая схема, чтобы начать с 0.5 с, а затем удвоить это время для каждой неудачной попытки. В большинстве случаев пользователи этого не замечают и не замечают. терпят неудачу гораздо чаще, чем в среднем три раза. Но это значительно замедлит любого вредоносного аутсайдера, пытающегося атаковать ваше приложение.
Я хочу знать время грубой силы, когда пароль является словарным словом, а также когда это не словарное слово.
словарь паролей
примерная цифра: существует около 1,000,000 английских слов, и если хакер может вычислить около 10,000 SHA-512 хэшей в секунду (обновление: см. комментарий CodesInChaos, эта оценка очень низкая), 1,000,000 / 10,000 = 100 секунд. Так и будет потратьте чуть более минуты, чтобы взломать пароль словаря одного слова для одного пользователя. Если пользователь присоединяет два словарные слова, вы находитесь в районе нескольких дней, но все еще очень возможно, если злоумышленник заботится достаточно. Более того, это становится все труднее.
случайный пароль
если пароль представляет собой действительно случайную последовательность буквенно-цифровых символов, верхний и нижний регистр, то число возможных паролей длины N равно 60^N (осталось 60 символов). На этот раз мы сделаем расчет в другом направлении; мы спросим:какую длину пароля мы могли бы взломать, учитывая определенный промежуток времени? просто используйте эту формулу:
N = Log60(t * 10,000) где t - время, затраченное на вычисление хэшей в секундах (опять же, предполагая 10 000 хэшей в секунду).
1 minute: 3.2
5 minute: 3.6
30 minutes: 4.1
2 hours: 4.4
3 days: 5.2
таким образом, учитывая 3 дня, мы сможем взломать пароль, если он длиной 5 символов.
Это все очень бал-парк, но вы поняли идею. Update: см. комментарий ниже, на самом деле можно взломать гораздо более длинные пароли, чем это.
что здесь происходит?
давайте проясним некоторые заблуждения:
соль не замедляет вычисление хэшей, это просто означает, что они должны взломать пароль каждого пользователя индивидуально и предварительно вычисленные хэш-таблицы (buzz-word:радужные таблицы) сделаны совершенно бесполезный. Если у вас нет предварительно вычисленной хэш-таблицы, и вы взламываете только один хэш-пароль, соление не имеет никакого значения.
SHA-512 не предназначен, чтобы быть трудно грубой силы. Лучшие алгоритмы хэширования, такие как BCrypt, PBKDF2 или SCrypt можно настроить так, чтобы вычислять намного дольше, и средний компьютер может вычислять только 10-20 хэшей в секунду. Читать это отличный ответ о хэширования паролей, Если вы еще этого не сделали.
update: как написано в комментарии CodesInChaos, даже пароли с высокой энтропией (около 10 символов) могут быть bruteforced, если использовать правильное оборудование для вычисления хэшей SHA-512.
примечания к принятому ответу:
принятый ответ от сентября 2014 года неверно и опасно неправильно:
В вашей случай, нарушение хэш-алгоритма эквивалентно нахождению столкновения в хэш-алгоритме. Это означает, что вам не нужно найти сам пароль (который будет прообраза)... Поиск столкновения с помощью атаки на день рождения занимает O (2^n/2) времени, где n-выходная длина хеш-функции в битах.
день рождения атаки абсолютно не имеет значения для взлома данного хэша. И это на самом деле идеальный пример прообраза атака. Эта формула и следующие несколько абзацев приводят к опасно высоким и совершенно бессмысленным значениям для времени атаки. Как показано выше это вполне возможно взломать соленый словарь паролей в течение нескольких минут.
низкая энтропия типичных паролей делает возможным относительно высокую вероятность того, что один из ваших пользователей использует пароль из относительно небольшой базы данных общих паролей...
вот почему обычно хеширования и соления в одиночку недостаточно, вам также необходимо установить другие механизмы безопасности. Вы должны использовать искусственно замедленный метод энтропии, такой как PBKDF2, описанный в PKCS#5...
Да, пожалуйста, используйте алгоритм, который медленно вычисляется,но что такое "энтропия"? Ввод пароля с низкой энтропией через хэш не увеличивает энтропию. Он должен!--9-->сохранить энтропия, но вы не можете сделать пароль мусора лучше с гашишем, он так не работает. слабый пароль поставил через PBKDF2 с еще слабый пароль.
на этот вопрос нет единого ответа, так как слишком много переменных, но SHA2 еще не взломан (см.: время жизни криптографических хэш-функций) Так что это все еще хороший алгоритм для хранения паролей. Польза соли хороша потому что она предотвращает нападение от атака по словарю или радужных таблиц. Важность соли заключается в том, что она должна быть уникальной для каждого пароля. Вы можете использовать такой формат, как [128-битная соль][512-битный хэш пароля], когда хранение хэшированных паролей.
единственный жизнеспособный способ атаки-фактически вычислить хэши для разных возможностей пароля и в конечном итоге найти правильный, сопоставив хэши.
чтобы дать представление о том, сколько хэшей можно сделать за секунду, я думаю, что биткойн-достойный пример. биткоин использует SHA256 и, чтобы сократить его, чем больше хэшей вы генерируете, тем больше биткойнов вы получаете (которые вы можете торговать на реальные деньги) и как такие люди мотивировано использовать GPUs для этой цели. Вы можете видеть в обзоре оборудования что средняя графическая карта, которая стоит всего $ 150, может рассчитать более 200 миллионов хэшей/ С. Чем дольше и сложнее ваш пароль, тем больше времени это займет. Расчет на 200 м / с, чтобы попробовать все возможности для 8 символов буквенно-цифровой (капитал, ниже, цифры) займет около 300 часов. В реальном времени, скорее всего, меньше, если пароль является чем-то подходящим или общим английским слово.
как таковой с любой безопасностью вам нужно посмотреть в контексте. Какова мотивация нападающего? Какие приложения? Наличие хэша со случайной солью для каждого дает довольно хорошую защиту от случаев, когда что-то вроде тысяч паролей скомпрометировано.
одна вещь, которую вы можете сделать, это также добавить дополнительную защиту грубой силы замедление процедура хэширования. Поскольку вы только хэш-пароли один раз, и злоумышленник должен делать это много раз, это работает в вашу пользу. Типичный способ сделать это-взять значение, хэшировать его, взять вывод, хэшировать его снова и так далее для фиксированного количества итераций. Вы можете попробовать что-то вроде 1000 или 10 000 итераций на примере. Это сделает его во много раз медленнее для злоумышленника, чтобы найти каждый пароль.