Как найти соль хэша

«Соленое» хеширование паролей: делаем правильно

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

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

Самым лучшим способом защиты паролей является «соленое» хеширование пароля. И в этой статье объясняется, как сделать это должным образом.

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

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

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
hash("waltz") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542

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

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

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

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

1. Пользователь создает учетную запись;
2. Вычисляется хеш-код от пароля и сохраняется в базе данных. Нет никакого смысла в пароле, записанном в обычном текстовом (незашифрованном) формате на жесткий диск;
3. Когда пользователь пытается войти в систему, хеш-код, вычисленный от пароля, который он ввел, сравнивается с хеш-кодом реального пароля (извлеченным из базы данных);
4. Если хеш-коды совпадают, пользователю предоставляется доступ. Если нет – пользователю сообщается, что он ввел неверные данные для входа в учетную запись;
5. Шаги 3 и 4 повторяются каждый раз, когда кто-либо пытается войти в свой аккаунт.

На шаге 4 никогда не сообщайте пользователю, что именно не так: имя пользователя или пароль. Всегда отображайте только общее сообщение, например, «Неверное имя пользователя или пароль». Это не позволит злоумышленникам вычислить верные имена пользователей без знания их паролей.

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

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

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

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

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

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

Атаки по словарю:

Trying apple       : fail
Trying blueberry   : fail
Trying 1234567     : fail
......
Trying letmein     : fail
Trying qwerty      : Success!

Атаки полным перебором:

Trying aaaa        : fail
Trying aaab        : fail
Trying aaac        : fail
Trying aaad        : fail
......			
Trying acdb        : fail
Trying acdc        : Success!

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

Если хеш-коды одинаковые, то предположенная комбинация является паролем. Двумя наиболее распространенными способами угадывания паролей является атаки по словарю и атаки полным перебором.

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

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

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

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

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

Searching: 5f4dcc3b5aa765d61d8327deb882cf99: FOUND: password5
Searching: 6cbe615c106f422d23669b610b564800: not in database
Searching: 630bf032efe4507f2c57b280995925a9: FOUND: letMEin12 
Searching: 386f43fab5d096a7a66d67c8f213e5ec: FOUND: mcd0nalds
Searching: d5ec75d5fe70d428685510fae36492d9: FOUND: p@ssw0rd!

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

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

Если вы хотите больше узнать о том, насколько быстрыми могут быть таблицы поиска, попробуйте взломать следующие sha256 хеш-коды с помощью бесплатного хеш-взломщика от CrackStation.

Эти хеш-коды могут быть взломаны меньше чем за 1 секунду:

c11083b4b0a7743af748c85d343dfee9fbb8b2576c05f3a7f0d632b0926aadfc
08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
d53d8d0632cd64e595b2cc9709bd580e4d323cd65ebbfaa778b3252c761ba1b8

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

Searching for hash(apple) in users' hash list...     : Matches [alice3, 0bob0, charles8]
Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
Searching for hash(letmein) in users' hash list...   : Matches [wilson10, dragonslayerX, joe1984]
Searching for hash(s3cr3t) in users' hash list...    : Matches [bruce19, knuth1337, john87]
Searching for hash(z@29hjja) in users' hash list...  : No users used this password

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

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

Этот вид атак особенно эффективен, потому что зачастую несколько пользователей имеют один и тот же пароль.

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

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

Далее мы рассмотрим технику под названием «соление», которая делает невозможным использование радужных таблиц и таблиц поиска для взлома хеш-кодов.

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hello" + "QxLUF1bgIAdeQX") = 9e209040c863f84a31e719795b2577523954739fe5ed3b58a75cff2127075ed1
hash("hello" + "bv5PehSMfV11Cd") = d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab
hash("hello" + "YYLmfY6IehjZMQ") = a49670c3c18b9e079b9cfaf51634f563dc8ae3070db2c4a8544305df1b60f007

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

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

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

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

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

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

В следующей секции мы рассмотрим распространенные ошибки при реализации соли.

НЕВЕРНЫЙ способ: короткая соль и повторное использование соли

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

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

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

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

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

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

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

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

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

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

В следующей секции мы рассмотрим распространенные ошибки при реализации соли.

НЕВЕРНЫЙ способ: короткая соль и повторное использование соли

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

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

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

Ниже приведены некоторые примеры чокнутых хеш-функций, которые я когда-либо встречал на форумах в Интернете:

• md5(sha1(пароль))
• md5(md5(соль) + md5(пароль))
• sha1(sha1(пароль))
• sha1(str_rot13(пароль + соль))
• md5(sha1(md5(md5(пароль) + sha1(пароль)) + md5(пароль)))
• Не используйте ни одну из них.

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

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

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

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

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

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

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

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

Атаки коллизии – это признак того, что существует вероятность наличия для строки, отличной от пароля пользователя, точно такого же хеш-кода. Однако нахождение коллизий даже в такой слабой хеш-функции как MD5 требует большой вычислительной мощности, поэтому маловероятно, что такие коллизии «нечаянно» произойдут на практике.

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

ВЕРНЫЙ способ: как производить хеширование правильно

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

Основы: Хеширование с солью

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

Соль должна быть сгенерирована при помощи криптографически стойкого генератора псевдослучайных чисел (англ. Cryptographically secure pseudorandom number generator, CSPRNG). Такие генераторы сильно отличаются от обычных генераторов псевдослучайных чисел, наподобие функции rand() в языке C.

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

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

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

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

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

Сохранение пароля:

1. Генерируем длинную случайную соль, используя криптографически стойкий генератор псевдослучайных чисел;
2. Присоединяем соль к паролю и вычисляем хеш-код с помощью стандартной криптографической хеш-функции, например, SHA256;
3. Сохраняем и соль, и хеш-код в записи базы данных пользователей.

Проверка пароля:

1. Извлекаем соль и хеш-код пользователя из базы;
2. Добавляем соль к введенному паролю и вычисляем хеш-код с помощью той же самой функции;
3. Сравниваем хеш-код введенного пароля с хеш-кодом из базы данных. Если они совпадают, пароль верен. В противном случае, пароль введен неправильно.

Внизу этой страницы представлены реализации «соленого» хеширования паролей на PHP, C#, Java и Ruby.

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

Даже если вы вычисляете хеш-код пользовательского пароля, используя JavaScript, вы все равно должны произвести хеширование хеш-кодов на сервере.

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

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

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

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

Хеширование в браузере – это, определенно, хорошая идея, но учитывайте следующие моменты в ваших проектах: Хеширование пароля на стороне клиента не замещает HTTPS (SSL/TLS).

Если соединение между браузером и сервером ненадежно, третья сторона может изменить код JavaScript во время загрузки, чтобы удалить функцию хеширования и получить пароль пользователя:

• Некоторые веб-браузеры не поддерживают JavaScript, и некоторые пользователи отключают JavaScript в своем браузере. Поэтому для максимальной совместимости ваше приложение должно определять, поддерживает ли браузер пользователя JavaScript, и если нет — эмулировать хеширование со стороны клиента на сервере;
• Вам нужно «солить» хеш-коды и на стороне клиента. Напрашивающееся решение – написать клиентский скрипт, запрашивающий у сервера соль пользователя. Не делайте этого, потому что это позволит злоумышленникам проверять действительно ли имя пользователя, не зная пароля.Поскольку вы хешируете и используете соль (хорошую соль) и на сервере, то можно использовать имя пользователя (или адрес электронной почты), конкатенированный со специфичной для сайта строкой (например, именем домена) в качестве соли на клиентской стороне.

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

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

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

Растяжение ключа реализуется при помощи специального типа хеш-функции, нагружающей ЦПУ. Не пытайтесь изобрести свою собственную – простое итеративное хеширование хеш-кода пароля не достаточно, так как оно может быть распараллелено на аппаратным уровне и выполнено так же быстро, как и обычный хеш-код.

Используйте стандартный алгоритм, такой как PBKDF2 или bcrypt. Реализацию алгоритма PBKDF2 на PHP можно найти здесь.

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

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

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

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

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

Если вы волнуетесь насчет вычислительной нагрузки, но все еще хотите использовать растяжение ключа в веб-приложении, рассмотрите выполнение алгоритма растяжения ключа в пользовательском браузере с помощью JavaScript. Stanford JavaScript Crypto Library включает в себя PBKDF2.

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

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

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

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

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

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

Я настоятельно рекомендую этот подход для любого крупномасштабного (более 100 000 пользователей) сервиса. А для любого сервиса, содержащего более чем 1 000 000 пользовательских аккаунтов, я считаю, что это просто обязательно.

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

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

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

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

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

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

Даже опытные разработчики должны быть образованы в сфере безопасности для того, чтобы писать безопасные приложения. Отличным источником для изучения уязвимостей веб-приложений является открытый проект обеспечения безопасности веб-приложений (англ. The Open Web Application Security Project – OWASP). Хорошим введением служит OWASP Top Ten Vulnerability List (список топ-10 уязвимостей от OWASP).

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

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

Найдите надежную организацию (или наймите сотрудников) для проверки вашего кода на постоянной основе. Процесс проверки безопасности нужно начинать на ранней стадии проекта и продолжать на протяжении всей разработки.

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

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

Использовать:

• Исходные коды на PHP, Java, C# или Ruby, приведенные в конце статьи;
• Портативный PHP фреймворк для хеширования паролей от OpenWall;
• Любой современный проверенный криптографический хеш-алгоритм, такой как SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3, и т.д;
• Проверенные алгоритмы растяжения ключа, такие как PBKDF2, bcrypt и scrypt;
• Безопасные версии функции crypt ($2y$, $5$, $6$).

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

• Устаревшие хеш-функции, такие как MD5 или SHA1;
• Небезопасные версии функции crypt ($1$, $2$, $2a$, $2x$, $3$);
• Любой алгоритм, который вы сами разработали. Используйте только ту технологию, которая находится в публичном доступе и была хорошо проверена опытными криптографами.

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

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

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

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

Большинство веб-сайтов используют так называемое зацикливание почты (англ. email loop) для аутентификации пользователей, которые забыли пароль. Для этого сгенерируйте случайный одноразовый маркер, тесно связанный с учетной записью. Включите его в ссылку для сброса пароля, отправляемую на адрес электронной почты пользователя.

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

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

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

Почта (SMTP) – это простой протокол, и в Интернете могут существовать вредоносные маршрутизаторы, регистрирующие почтовый траффик. И почтовый аккаунт пользователя (включая ссылку сброса) может подвергаться риску еще долгое время после того, как пароль был изменен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете защитить хеш-коды от замены во время атаки SQL-инъекцией, подключаясь к базе данных с помощью двух пользователей с разными правами доступа. Один – для кода «создать аккаунт», а другой – для кода «вход в систему». Код «создать аккаунт» должен иметь возможность читать и писать в таблицу пользователей, а код «вход в систему» должен только читать.

Хеш-функции, такие как MD5, SHA1, и SHA2 используют структуру Меркла-Дамгарда, которая делает их уязвимыми для так называемых атак дополнением длины. Это значит, что при данном хеш-коде H(X), злоумышленник может найти значение H(pad(X) + Y), для любой другой строки Y, не зная значения X. pad(X) – это функция дополнения, используемая при хешировании.

Это значит, что имея хеш-код H(ключ + сообщение), злоумышленник может вычислить H(pad(ключ + сообщение) + добавление) при неизвестном значении ключа.

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

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

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

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

Почему код для хеширования, приведенный в этой статье, сравнивает хеш-коды за время «неизменной длины» («length-constant» time)?

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

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

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

Например, стандартный алгоритм сравнения строк «xyzabc» и «abcxyz» немедленно обнаружит, что первые символы отличаются, и не потрудится проверить оставшуюся часть строки. С другой стороны, при сравнении строк «aaaaaaaaaaB» и «aaaaaaaaaaZ«, алгоритм сравнения просматривает последовательность символов «a» прежде, чем определит, что строки неодинаковы.

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

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

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

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

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

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

Ответ на предыдущий вопрос объясняет, зачем нужна функция SlowEquals, здесь же поясняется, как на самом деле работает код:

private static boolean slowEquals(byte[] a, byte[] b)
{
    int diff = a.length ^ b.length;
    for(int i = 0; i < a.length && i < b.length; i++)
    diff |= a[i] ^ b[i];
    return diff == 0;
}

Для проверки целых чисел на равенство в коде используется оператор исключающее «ИЛИ» – «^» вместо оператора «==«. Почему объясняется ниже.

Результат операции исключающее «ИЛИ» над двумя целыми числами будет равен нулю, тогда и только тогда, когда они одинаковые, так как оператор работает следующим образом: 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1.Если мы применим эти правила ко всем битам в сравниваемых числах, результат будет равен нулю, только если все биты совпадают.

Итак, в первой строке, если переменная a.length равна b.length, то значение переменной diff будет равно нулю, а если нет, diff будет отлична от нуля. Далее сравниваем биты, используя исключающее «ИЛИ», и применяем побитовое «ИЛИ» к результату предыдущей операции и переменной diff.

Таким образом, переменная diff будет отличаться от нуля, если биты отличаются. Так как побитовое «ИЛИ» никогда не сбрасывает биты, переменная diff будет равна нулю в конце цикла только в единственном случае – если, она была установлена в ноль перед началом цикла сравнения a.length и b.length, и все биты в двух массивах совпадают (ни один результат операции исключающее «ИЛИ» не принял значение, отличное от нуля).

Причина, по которой нам нужно использовать исключающее «ИЛИ» вместо оператора «==» для сравнения целых чисел, заключается в том, что обычно «==» переводится/компилируется/интерпретируется как ветвление.

Например, на C код «diff &= a == b» может скомпилироваться в следующие ассемблерные инструкции x86:

MOV EAX, [A]
CMP [B], EAX
JZ equal
JMP done
equal:
AND [VALID], 1
done:
AND [VALID], 0

Из-за ветвления, код выполняется за разное количество времени, в зависимости от равенства чисел и внутреннего состояния предсказателя ветвлений в ЦПУ.

Код C «diff |= a ^ b» будет скомпилирован примерно в следующий ассемблерный код, время выполнения которого не зависит от равенства чисел:

MOV EAX, [A]
XOR EAX, [B]
OR [DIFF], EAX

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

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

Приведенные ниже примеры кода:

Образец кода на PHP
Образец кода на Java
Образец кода на ASP.NET (C#)
Образец кода на Ruby (on Rails)