Какой в ​​настоящее время алгоритм одностороннего шифрования является наиболее безопасным?

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

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

Я использую MD5 почти исключительно в течение многих лет, и мне интересно, есть ли что-то еще, что мне нужно сделать. Стоит ли мне обдумывать другой алгоритм?

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


person Teekin    schedule 24.02.2010    source источник
comment
Хеш-функции не являются функциями шифрования. Функции шифрования имеют обратные функции для дешифрования зашифрованного значения, чтобы получить исходное значение. Но хеши нельзя расшифровать. Можно только найти коллизии (входные значения, которые приводят к одному и тому же хэш-значению).   -  person Gumbo    schedule 25.02.2010
comment
Выходные данные любой заданной хеш-функции / алгоритма всегда имеют одинаковую длину. Для MD5 это всегда 128 бит, независимо от длины входных бит / байтов / строки.   -  person Jared Updike    schedule 25.02.2010
comment
Не беспокойтесь о длине поля. Почти во всех случаях угадывание паролей и их хеширование будут намного быстрее, чем перебором коллизии, а 128 бит достаточно большой, чтобы противостоять атакам грубой силы до тепловой смерти Вселенной.   -  person David Thornley    schedule 25.02.2010
comment
Чтобы быть в курсе хэш-функций, посетите eHash Wiki, особенно ehash. iaik.tugraz.at/wiki/The_Hash_Function_Zoo.   -  person outis    schedule 25.02.2010


Ответы (7)


Предупреждение. С тех пор, как этот пост был написан в 2010 году, графические процессоры стали широко использоваться для подбора хэшей паролей. Графические процессоры по умеренной цене могут обрабатывать десять миллиардов MD5 в секунду. Это означает, что даже полностью случайный 8-значный буквенно-цифровой пароль (62 возможных символа) может быть взломан за 6 часов. SHA-1 работает немного медленнее, это займет один день. Пароли ваших пользователей намного слабее и (даже с учетом соления) будут падать со скоростью тысячи паролей в секунду. Хеш-функции разработаны, чтобы быть быстрыми. Вы не хотите этого для паролей. Используйте scrypt, bcrypt или PBKDF-2.

MD5 оказался слабым еще в 1996 году, и больше не должен использоваться в криптографических целях. SHA-1 - часто используемая замена, но есть похожие проблемы. Семейство хэш-функций SHA-2 - это текущая замена SHA-1. Члены SHA-2 по отдельности называются SHA-224, SHA-256, SHA-384 и SHA-512.

На данный момент несколько хэш-функций конкурируют за звание SHA-3. , следующий стандартизированный алгоритм криптографического хеширования. Победитель будет выбран в 2012 году. Ничего из этого пока использовать нельзя!

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

Предупреждение. bcrypt основан на более старом алгоритме двустороннего шифрования Blowfish, для которого сегодня существуют лучшие альтернативы. Я не думаю, что криптографические хеширующие свойства bcrypt полностью понятны. Кто-нибудь поправит меня, если я ошибаюсь; Я никогда не находил надежного источника, который обсуждал бы свойства bcrypt (кроме его медлительности) с криптографической точки зрения.

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

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

person molf    schedule 24.02.2010
comment
Чем дольше, тем лучше. Не обязательно верно. Я слышал анекдотические заявления о том, что принуждение пользователей к выбору более длинных паролей иногда заставляет их выбирать пароли с меньшей энтропией, чтобы они могли их запомнить. Лично я могу запомнить случайно сгенерированный пароль из 8 букв, если я использую его ежедневно. Дольше, чем это, и я сам прибегну к придумыванию паролей, и я не знаю, какая у них энтропия. - person Steve Jessop; 25.02.2010
comment
@Steve Атакующие не переходят постепенно от попыток ввода пароля с низкой энтропией к более высоким. Они пробуют словарную атаку, а затем прибегают к грубой силе. Таким образом, ooGoo! Ooooooo876 имеет меньшую энтропию, чем d! NA0sue732bnfuw, но не менее безопасен. - person Lucas; 25.02.2010
comment
Для хеширования паролей MD5 по-прежнему следует рассматривать как разумный вариант (как вы намекнули), при условии, что ваши пароли надежны и вы используете соль (которая применима к любому хешу). Насколько я понимаю, коллизионные атаки в значительной степени не имеют отношения к хешированию паролей. - person MarkR; 25.02.2010
comment
@Lucas: ни ooGoo! Ooooooo876, ни d! NA0sue732bnfuw не имеют энтропии в соответствующем значении, поскольку они являются константами, а не случайными величинами. Чтобы быть педантичным, я должен был сказать, что выбирайте пароли как выходы r.v с меньшей энтропией, а не выбирайте пароли с меньшей энтропией. Схема генерации паролей с низкой энтропией с большей вероятностью сгенерирует пароли, которые попадают в раннюю часть атаки по словарю / грубой силе, предполагая (как и следовало бы в целях безопасности), что злоумышленник имеет некоторое представление о том, как выбираются пароли, и имеет разумно продумал свою атаку. - person Steve Jessop; 25.02.2010
comment
@Steve: злоумышленник понимает ... в этом суть использования более длинного пароля. Существует большая разница между паролем из 8 символов (клавиатура) и паролем из 14-50 символов (возможно, буквенное число + знаки препинания и, возможно, несколько случайных символов). Последний имеет гораздо более высокое пространство. Даже если он, скорее всего, будет состоять из слов, поскольку вы можете их настроить (l33t Speak, sms-style, ...), он все равно дает больше энтропии. - person Matthieu M.; 26.02.2010
comment
+1 за одно слово: salt. Без соли вы подвержены атакам радуги. И я должен отметить, что вам нужна одна соль для каждого пароля, а не одна для всех! - person Matthieu M.; 26.02.2010
comment
Конечно, более длинный пароль может вызвать больше энтропии. Но молф сказал, что чем дольше, тем лучше. Это неверно: пароль, состоящий из 8 случайных буквенно-цифровых символов, лучше, чем пароль, состоящий из двух случайных слов словаря. Если вы затем внесете дополнительную случайность в схему генерации паролей из двух слов, то со временем она станет лучше. Будут ли пользователи на самом деле делать это, когда их заставляют выбирать более длинные пароли, - это вопрос психологии, а не теории информации. Я недостаточно уверен в ответе, чтобы налагать какие-либо ограничения, кроме крошечного минимального размера. - person Steve Jessop; 26.02.2010
comment
Многие пароли пользователей уже довольно простые. Парольные фразы часто так же легко запомнить, но с их длиной. Я утверждаю, что при прочих равных, чем дольше, тем лучше. Но не всегда все равно, и вы совершенно правы, спрашивая, не ослабит ли пароли требуемая минимальная длина. Будьте осторожны при установлении строгих минимальных ограничений и помогите пользователям решить самим. - person molf; 26.02.2010
comment
@molf Я отредактировал предупреждение о том, насколько быстро MD5, SHA-1 и т. д. могут быть использованы грубой силой с использованием графических процессоров, и как это означает, что ни один из них больше не подходит для хранения паролей. Пожалуйста, не стесняйтесь изменять / возвращать / и т. Д. - person derobert; 10.08.2012
comment
почему бы не использовать что-то вроде sha1 (md5 ($ password))? - person Albi Patozi; 11.05.2013

Отличный вопрос! Эта страница будет полезна для чтения. В частности, автор утверждает, что MD5 не подходит для хеширования паролей:

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

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

Затем в статье объясняются некоторые альтернативы и рекомендуется Bcrypt как «правильный выбор» (его слова, а не мой).

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

person Matt Solnit    schedule 24.02.2010
comment
Автор также рекомендует схему хеширования паролей, разработанную для FreeBSD, которая использует MD5 в своей основе, но повторяет хеш-функцию тысячи раз. Аналогичная конструкция на основе SHA-1 доступна в glibc. - person caf; 25.02.2010

Чтобы повысить надежность пароля, вы должны использовать более широкий набор символов. Если у вас 8-10 символов в пароле, его будет довольно сложно взломать. Хотя увеличение длины сделает его более безопасным, только если вы используете числовые / буквенные / другие символы.

SHA1 - это еще один алгоритм хеширования (одностороннего шифрования), он медленнее, но имеет более длинный дайджест. (закодированное сообщение) (160 бит), где MD5 имеет только 128 бит.

Тогда SHA2 еще более безопасен, но использует меньше.

person Tony The Lion    schedule 24.02.2010
comment
Замечу, что более медленная работа на самом деле является преимуществом, когда дело доходит до защиты от атак грубой силы. - person Anon.; 25.02.2010
comment
Это не столько медленнее, сколько сложно сделать быстро даже с помощью специального оборудования / предварительно вычисленных таблиц / математического анализа ... что важно. Обоснование конкурса NIST SHA-3 заключается в том, что текущие крипто-хеш-функции, хотя и все еще медленные, как и раньше, на компьютерах общего назначения, в последнее время были ослаблены по ряду других причин. Особенно MD5 (см. Страницу MD5 Wikipedia). - person Pascal Cuoq; 25.02.2010
comment
Неуместно полагаться на скорость, с которой компьютер может создать хэш. Разница в скорости вычислений MD5 и SHA1 не обеспечит заметной защиты от атак грубой силы. Единственное, что должно иметь значение, - это качество хеша, и это связано с его способностью защищать от вывода входных данных из хеша и его способностью защищать от ложного создания одного и того же хеша с разными входными данными. - person Thomas; 25.02.2010
comment
Еще можно радужную таблицу SHA1. Я переместил большую часть своей новой разработки на SHA-256 - person Xorlev; 25.02.2010
comment
Это не совсем так. | а | ^ l - это уравнение, которое описывает количество возможных значений пароля, где a - алфавит пароля, а l - длина пароля. Более эффективно увеличивать l вместо | a |. - person Paul Nathan; 25.02.2010
comment
@Xorlev: вот для чего нужна соль. Есть веские причины для перехода от SHA-1 к SHA-256, но атаки с использованием радужных таблиц на хешированные пароли не входят в их число. - person Steve Jessop; 25.02.2010
comment
@Steve Jessop, я солю весь свой SHA1, но, учитывая, что радужные таблицы действительно начинают появляться, мне не очень больно использовать SHA-256. Также можно сделать усиление ключей, чтобы увеличить время, необходимое для атак грубой силы. - person Xorlev; 25.02.2010
comment
@Xorlev Вы можете построить радужную таблицу для любого алгоритма хеширования. Практичность построения радужной таблицы зависит от количества возможных входных данных, а не от надежности алгоритма. - person Nick Johnson; 25.02.2010
comment
@Nick Johnson, я в курсе, однако по мере того, как появляется все больше и больше таблиц, я все меньше и меньше хочу использовать SHA-1. - person Xorlev; 25.02.2010
comment
@Xorlev: а какое это имеет значение? С 64 битами соли, как кто-нибудь может иметь радужную таблицу для SHA-1 с правильным значением соли? Они могут начать его генерировать, как только узнают соль для пароля, который хотят взломать, но это ничем не отличается от словарной атаки на SHA-1. Существование радужных таблиц для SHA-1 не представляет для вас угрозы. Существование атак с использованием прообраза на SHA-1 может быть растущей угрозой. - person Steve Jessop; 25.02.2010

соление пароля - всегда дополнительный уровень защиты

$salt = 'asfasdfasdf0a8sdflkjasdfapsdufp';
$hashed = md5( $userPassword . $salt );
person David Morrow    schedule 24.02.2010
comment
Важно, чтобы каждый раз при установке пароля генерировалась свежая соль, а не фиксированное значение. - person caf; 25.02.2010
comment
@caf: Разве это не привело бы к тому, что вычисление заняло бы больше времени, если бы оно всегда было одинаковым, что увеличило бы время, необходимое для его грубой силы? - Если соль каждый раз различается, ее необходимо сохранить в той же строке, что и пароль для механизма входа в систему, чтобы иметь возможность сравнивать хешированную попытку с реальным паролем. - person Teekin; 25.02.2010
comment
Если соль всегда одна и та же, злоумышленник может: а) подобрать все ваши пароли параллельно (каждый тестовый хэш можно сравнить со всеми вашими хешами паролей); и б) вычислить хэши до того, как увидеть вашу базу данных. Да, соль должна храниться вместе с хешем - именно это и делают хэши паролей в стиле UNIX. - person caf; 26.02.2010
comment
На самом деле, хотя лучше каждый раз использовать другую соль, оказывается, что даже использование фиксированной соли полезно, если не все системы в мире используют одну и ту же фиксированную соль. Дело в том, чтобы предотвратить заранее вычисленные таблицы, такие как радужные таблицы, часто используемые для взлома паролей Windows. Так что, если ваша соль не такая, как у всех, она все равно полезна. См. Также Википедию о солении. - person Paul; 22.09.2011
comment
Основная проблема с отказом от использования соли заключается в том, что если у 10 пользователей одинаковый пароль, то $ hashed для всех 10 будет одинаковым. Итак, вы только что взломали 10 учетных записей (при условии, что вы можете видеть, что находится в базе данных). - person Alexis Wilke; 03.01.2013

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

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

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

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


1 Тот факт, что MD5 "сломан", не означает, что вы можете просто отменить его, когда захотите.

person Seth    schedule 24.02.2010
comment
Однако для большинства веб-сайтов цель хеширования паролей состоит в том, чтобы сделать неудобным для кого-то, имеющим доступ к базе данных, чтение пароля, а не для обеспечения безопасности. - это может быть все, чего достигают большинство сайтов, но цель должна состоять в том, чтобы сделать непрактичным изменение любого из сохраненных паролей ваших пользователей - и это вполне достижимо. - person Nick Johnson; 25.02.2010
comment
Согласен, я очень старался объяснить своим коллегам, почему недостатки MD5 не должны препятствовать его использованию для хеширования паролей. Излишне говорить, что использование соли и минимальной надежности пароля по-прежнему рекомендуется - person MarkR; 25.02.2010
comment
Я согласен с тем, что если у вас есть вся база данных, им не нужны пароли пользователей для доступа к вашей системе, но, поскольку многие люди повторно используют свои пароли, все еще плохая идея игнорировать важность сильного хеш-алгоритма + соль . - person FercoCQ; 24.01.2019
comment
Верно. И (почти 9 лет спустя) я думаю, что пора уходить от простых MD5 и паролей в целом. Скромное имя пользователя и пароль по-прежнему приносит много пользы, но я с нетерпением жду того дня, когда биометрия и простые в использовании второстепенные факторы станут практичным и безопасным способом аутентификации. - person Seth; 24.01.2019

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

По нашим оценкам, на современном оборудовании (2009 г.), если на вычисление производного ключа потрачено 5 секунд, стоимость аппаратной атаки методом грубой силы на scrypt примерно в 4000 раз превышает стоимость аналогичной атаки на bcrypt (чтобы найти то же самое пароль), и в 20000 раз превосходит аналогичную атаку против PBKDF2.

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

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

person Ants Aasma    schedule 24.02.2010

В настоящее время NIST проводит конкурс на выбор нового алгоритма хеширования, как и при выборе алгоритма шифрования AES. Так что ответ на этот вопрос, скорее всего, будет другим через пару лет.

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

person Jeffrey L Whitledge    schedule 24.02.2010