Что такое соль в хешировании
В криптографии , А соль представляет случайные данные, используемые в качестве дополнительного входа к односторонней функции , что хэши данные , A пароль или ключевая фраза . Соли используются для защиты паролей при хранении. Исторически в системе хранилась только криптографическая хеш-функция пароля, но со временем были разработаны дополнительные меры безопасности для защиты от идентифицируемых повторяющихся или общих паролей (поскольку их хэши идентичны). Соление - одна из таких защит.
Для каждого пароля случайным образом генерируется новая соль. Обычно соль и пароль (или его версия после растяжения ключа ) объединяются и передаются в криптографическую хеш-функцию , а выходное хеш-значение (но не исходный пароль) сохраняется вместе с солью в базе данных. Хеширование допускает последующую аутентификацию без сохранения и, следовательно, риска раскрытия пароля в виде открытого текста, если хранилище данных аутентификации будет скомпрометировано. Обратите внимание, что из-за этого соли не нужно шифровать или хранить отдельно от самого хешированного пароля, потому что даже если злоумышленник имеет доступ к базе данных с хеш-значениями и солями, правильное использование указанных солей будет препятствовать общему использованию. атаки.
Соли защищают от атак, которые используют предварительно вычисленные таблицы (например, радужные таблицы ), поскольку они могут сделать размер таблицы, необходимый для успешной атаки, чрезмерно большим, не обременяя пользователей. Поскольку соли отличаются друг от друга, они также защищают избыточные (например, часто используемые, повторно используемые) пароли, поскольку для разных экземпляров одного и того же пароля создаются разные хэши с солью.
Криптографические соли широко используются во многих современных компьютерных системах, от учетных данных системы Unix до безопасности в Интернете .
СОДЕРЖАНИЕ
Пример использования
Вот неполный пример значения соли для хранения паролей. В этой первой таблице есть две комбинации имени пользователя и пароля. Пароль не сохраняется.
| Имя пользователя | Пароль |
|---|---|
| user1 | пароль123 |
| user2 | пароль123 |
Значение соли генерируется случайным образом и может иметь любую длину; в этом случае значение соли составляет 8 байтов . Значение соли добавляется к паролю в виде открытого текста, а затем результат хешируется, что называется хешированным значением. Сохраняются как значение соли, так и хеш-значение.
| Имя пользователя | Солевое значение | Строка для хеширования | Хешированное значение = SHA256 (пароль + значение соли) |
|---|---|---|---|
| user1 | E1F53135E559C253 | password123 E1F53135E559C253 | 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8 |
| user2 | 84B03D034B409D4E | password123 84B03D034B409D4E | B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A |
Как показано в приведенной выше таблице, разные значения соли будут создавать совершенно разные хешированные значения, даже если пароли в виде открытого текста совершенно одинаковы. Кроме того, словарные атаки в некоторой степени смягчаются, поскольку злоумышленник не может практически предварительно вычислить хэши . Однако соль не может защитить обычные или легко угадываемые пароли.
Без соли хеш-значение одинаково для всех пользователей, у которых есть заданный пароль, что упрощает хакерам угадывание пароля по хешированному значению:
| Имя пользователя | Строка для хеширования | Хешированное значение = SHA256 |
|---|---|---|
| user1 | пароль123 | 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A |
| user2 | пароль123 | 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A |
Распространенные ошибки
Повторное использование соли
Использование одной и той же соли для всех паролей опасно, потому что предварительно вычисленная таблица, которая просто учитывает соль, сделает соль бесполезной.
Создание предварительно вычисленных таблиц для баз данных с уникальными солями для каждого пароля нецелесообразно из-за вычислительных затрат на это. Но если для всех записей используется обычная соль, создание такой таблицы (которая учитывает соль) становится жизнеспособной и, возможно, успешной атакой.
Поскольку повторное использование соли может привести к тому, что пользователи с одним и тем же паролем будут иметь один и тот же хэш, взлом одного хеша может привести к взлому и других паролей.
Короткая соль
Если соль слишком короткая, злоумышленник может предварительно вычислить таблицу всех возможных солей, добавленную к каждому вероятному паролю. Использование длинной соли гарантирует, что такой стол будет чрезмерно большим.
Преимущества
Чтобы понять разницу между взломом одного пароля и их набора, рассмотрим файл с пользователями и их хешированными паролями. Скажем, файл несоленый. Затем злоумышленник может выбрать строку, назвать ее попыткой [0], а затем вычислить хэш (попытка [0]). Пользователь, чей хэш хранится в файле, является хешем (попытка [0]), может иметь или не иметь попытки ввода пароля [0]. Однако, даже если попытка [0] не является фактическим паролем пользователя, она будет принята, как если бы это было так, потому что система может проверять пароли, только вычисляя хэш введенного пароля и сравнивая его с хешем, хранящимся в файле. Таким образом, при каждом совпадении пароль пользователя взламывается, и вероятность совпадения возрастает с увеличением количества паролей в файле. Напротив, если используются соли, злоумышленник должен будет вычислить хэш (попытка [0] || salt [a]), сравнить с записью A, затем хеш (попытка [0] || salt [b]), сравнить с запись B и т. д. Это предотвращает любую одну попытку взлома нескольких паролей (только если исключено повторное использование соли).
Соли также борются с использованием предварительно вычисленных таблиц для взлома паролей. Такая таблица может просто сопоставлять общие пароли с их хэшами или может делать что-то более сложное, например сохранять начальную и конечную точки набора предварительно вычисленных цепочек хешей . В любом случае солирование может защитить от использования предварительно вычисленных таблиц, удлиняя хэши и заставляя их извлекать из более крупных наборов символов, что снижает вероятность того, что таблица покрывает результирующие хэши. В частности, предварительно вычисленная таблица должна охватывать строку [salt + hash], а не просто [hash].
Современная система теневых паролей , в которой хэши паролей и другие данные безопасности хранятся в закрытом файле, несколько смягчает эти проблемы. Однако они остаются актуальными в многосерверных установках, в которых используются централизованные системы управления паролями для передачи паролей или хэшей паролей в несколько систем. В таких установках учетная запись root в каждой отдельной системе может рассматриваться как менее надежная, чем администраторы централизованной системы паролей, поэтому по-прежнему целесообразно обеспечить безопасность алгоритма хеширования паролей, включая создание уникальных значений соли. адекватный.
Другое (меньшее) преимущество соли заключается в следующем: два пользователя могут выбрать ту же строку, что и их пароль, или один и тот же пользователь может использовать один и тот же пароль на двух машинах. Без соли этот пароль будет храниться в той же строке хеша в файле паролей. Это раскрыло бы тот факт, что две учетные записи имеют один и тот же пароль, что позволит любому, кто знает один из паролей учетной записи, получить доступ к другой учетной записи. Добавляя в пароли два случайных символа, даже если две учетные записи используют один и тот же пароль, никто не может обнаружить это, просто прочитав хеши.
Реализации Unix
1970–1980 годы
Ранние версии Unix использовали файл паролей /etc/passwd для хранения хешей паролей с солью (паролей с префиксом из двух символов случайных солей). В этих более старых версиях Unix соль также хранилась в файле passwd (в виде открытого текста) вместе с хешем пароля с солью. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы программные инструменты с привилегиями пользователя могли находить имена пользователей и другую информацию. Поэтому безопасность паролей защищена только односторонними функциями (шифрованием или хешированием), используемыми для этой цели. Ранние реализации Unix ограничивали пароли до восьми символов и использовали 12-битную соль, что позволяло использовать 4096 возможных значений соли. Это был подходящий баланс для затрат 1970-х годов на вычисления и хранение.
1980-е годы -
Система теневых паролей используется для ограничения доступа к хешам и соли. Соль составляет восемь символов, хеш - 86 символов, а длина пароля не ограничена.
Реализации веб-приложений
Безопасность веб-приложений: Что можно, а что нельзя делать при шифровании с использованием соли.
Безопасность веб-приложений: Что можно, а что нельзя делать при шифровании с использованием соли
Обзор:
Вопрос безопасности баз данных стал более насущным по мере того, как базы данных становились более открытыми. Шифрование является одним из пяти основных факторов безопасности данных.
Небезопасной практикой является хранение такой важной информации, как пароль, номер кредитной карты в базе данных в незашифрованном виде. Эта статья охватывает различные возможности шифрования.
Даже в если вы зашифровали вашу информацию, это совершенно не значит, что она находится в полной безопасности. В этой статье рассматриваются действия со стороны злоумышленника.
Приложения, не использующие хеши:
Во время изучения веб-приложения я дошел до этого места программы. Программа использовала javascript для шифрования пароля пользователя перед отправкой. В качестве соли использовался текущий ID сессии.
Итак, на сервере:
На сервере программа не сможет проверить значение пароля по причине использования соли и случайного ID сессии. И поскольку MD5 является нереверсивной хеш-функцией, пароль не сможет быть проверен до тех пор, пока пароли хранятся в виде текста в базе данных.
В качестве соли для шифрования пароля перед отправкой используется случайно сгенерированный ID сессии. Это значит, что серверные базы данных не будут зашифрованы.
Иногда такого рода программы выдают много информации.
Пункт №1: Всегда шифруйте вашу базу данных паролей.
- Алгоритм, используемый для хеширования, должен иметь какие-то изъяны. Хеши должны быть реверсивными
- Использование брут-форс атаки для перебора хешей с помощью словаря или радужных таблиц.
- Или у вас просто UPDATE привилегии. Тогда просто замените значения хешей паролей на известные вам.
Функция: md5(“входные данные”); Hash(“входные данные”); Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d8327d eb882cf99”
Функция: System.Security.Cryptogr aphy Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d8327d eb882cf99”
Функция:java.secur ity.MessageDigest Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d 8327deb882cf99”
Функция: Crypt() По-умолчанию DES вывод: 13 Символов Пример: “sih2hDu1acVcA”
Шифрование, хеширование и засоление - все связанные методы, но у каждого из этих процессов есть свойства, которые дают им различные цели..
Короче говоря, Шифрование включает в себя кодирование данных, чтобы к ним могли получить доступ только те, у кого есть ключ. Это защищает его от посторонних лиц.
Криптографическое хеширование включает в себя вычисления, которые нельзя отменить. Эти функции имеют некоторые специальные свойства, которые делают их полезными для цифровых подписей и других форм аутентификации..
Соль включает в себя добавление случайных данных перед их передачей через криптографическую хеш-функцию. Он в основном используется для обеспечения безопасности паролей во время хранения, но также может использоваться с другими типами данных.
Что такое шифрование?
Проще говоря, Шифрование - это процесс использования кода для предотвращения доступа других сторон к информации.. Когда данные зашифрованы, доступ к ним могут получить только те, у кого есть ключ. Пока используется достаточно сложная система, и она используется правильно, злоумышленники не смогут увидеть данные.
Данные шифруются с помощью алгоритмов шифрования, которые также известны как шифры. Одно из наиболее важных различий между шифрованием и хэшированием (о котором мы поговорим позже) заключается в том, что шифрование предназначено для использования в обоих направлениях. Это означает, что после того, как что-то было зашифровано ключом, оно также может быть расшифровано.
Это делает шифрование полезным в ряде ситуаций, например, для безопасного хранения или передачи информации.. Как только данные зашифрованы должным образом, они считаются безопасными и доступны только тем, у кого есть ключ. Наиболее известным типом является шифрование с симметричным ключом, которое включает использование одного и того же ключа в процессах шифрования и дешифрования..
Смотрите также: Общие типы шифрования объяснены
Общие алгоритмы шифрования
Шифрование в действии
FeiUVFnIpb9d0cbXP / Ybrw ==
Этот зашифрованный текст можно расшифровать только ключом «1234». Если бы мы использовали более сложный ключ и держали его в секрете, мы могли бы считать данные защищенными от злоумышленников..
Что такое хеширование?
Неважно, является ли ваш вклад Война и мир или просто две буквы, результат хеш-функции всегда будет одинаковой длины. Хэш-функции имеют несколько различных свойств, которые делают их полезными:
- Они односторонние функции - Это означает, что не существует практического способа выяснить, какой исходный ввод был из заданного хеш-значения.
- Маловероятно, что два входа имеют одинаковое хеш-значение - Несмотря на то, что два разных входа могут давать одно и то же значение хеш-функции, шансы на это настолько малы, что мы не будем об этом беспокоиться. Для практических целей хеш-значения можно считать уникальными.
- Один и тот же вход всегда дает один и тот же результат - Каждый раз, когда вы помещаете одну и ту же информацию в данную хеш-функцию, она всегда будет выдавать один и тот же результат.
- Даже малейшее изменение дает совершенно другой результат - Если даже один символ изменяется, значение хеша будет сильно отличаться.
Для чего используются хэши?
Хэш-функции могут иметь некоторые интересные свойства, но что мы можем на самом деле делать с ними? Возможность выплевывать уникальный вывод фиксированного размера для входных данных любой длины может показаться не более чем непонятным приемом сторонних разработчиков, но хэш-функции на самом деле имеют ряд применений..
Криптографические хеш-функции также могут использоваться как обычные хеш-функции. В этих сценариях они могут выступать в качестве контрольных сумм для проверки целостности данных, в качестве алгоритмов снятия отпечатков, которые устраняют дублирующиеся данные, или для создания хеш-таблиц для индексации данных..
Общие криптографические хеш-функции
- MD5 - Это хеш-функция, впервые опубликованная в 1991 году Роном Ривестом. В настоящее время он считается небезопасным и не должен использоваться в криптографических целях. Несмотря на это, он все еще может быть использован для проверки целостности данных.
- SHA-1 - Безопасный алгоритм хеширования 1 используется с 1995 года, но не считается безопасным с 2005 года, когда имел место ряд успешных атак на столкновения. Теперь рекомендуется использовать либо SHA-2, либо SHA-3..
- SHA-2 - Это семейство хеш-функций, которые являются преемниками SHA-1. Эти функции содержат многочисленные улучшения, которые делают их безопасными в самых разных приложениях. Несмотря на это, SHA-256 и SHA-512 уязвимы для атак с удлинением длины, поэтому в определенных ситуациях лучше всего реализовать SHA-3..
- SHA-3 - SHA-3 - самый новый член семейства Secure Hash Algorithm, но он построен совсем не так, как его предшественники. На данном этапе он еще не заменил SHA-2, а просто предоставляет криптографам еще один вариант, который может обеспечить повышенную безопасность в определенных ситуациях..
- RIPEMD - RIPEMD - это еще одно семейство функций, разработанное академическим сообществом. Он основан на многих идеях MD4 (предшественника MD5) и не ограничен никакими патентами. RIPEMD-160 все еще считается относительно безопасным, но он не получил широкого распространения.
- джакузи - Whirlpool - это хеш-функция из семейства квадратных блоков. Он основан на модификации AES и не подпадает под действие каких-либо патентов. Он считается безопасным, но несколько медленнее, чем некоторые из его альтернатив, что привело к ограниченному принятию.
Хеширование в действии
Теперь, когда вы понимаете, что такое хэш-функции, пришло время применить их на практике. Если мы поместим тот же текст «Давайте есть”В онлайн-калькулятор SHA-256, он дает нам:
5c79ab8b36c4c0f8566cee2c8e47135f2536d4f715a22c99fa099a04edbbb6f2
Если мы изменим хотя бы один символ на одну позицию, это резко изменит весь хэш. Опечатка типа «Встретил есть»Дает совершенно другой результат:
4be9316a71efc7c152f4856261efb3836d09f611726783bd1fef085bc81b1342
В отличие от шифрования, мы не можем поместить это значение хеша через функцию в обратном направлении, чтобы получить наш ввод еще раз. Хотя эти хэш-функции нельзя использовать так же, как шифрование, их свойства делают их важной частью цифровых подписей и многих других приложений..
Хеш-функции и пароли
Хэш-функции имеют еще одно распространенное применение, которое мы еще не обсуждали. Они также являются ключевым компонентом хранить наши пароли в безопасности во время хранения.
Вероятно, у вас есть десятки онлайн-аккаунтов с паролями. Для каждой из этих учетных записей ваш пароль должен храниться где-то. Как проверить ваш логин, если на сайте не было собственной копии вашего пароля??
Такие компании, как Facebook или Google, хранят миллиарды паролей пользователей. Если эти компании хранят пароли в виде открытого текста, то любой злоумышленник, который сможет проникнуть в базу паролей, сможет получить доступ к каждой учетной записи, которую они найдут..
Это было бы серьезной катастрофой для безопасности, как для компании, так и для ее пользователей. Если каждый пароль был раскрыт злоумышленникам, то все их учетные записи и пользовательские данные были бы в опасности.
Лучший способ предотвратить это не хранить сами пароли, а вместо этого использовать хеш-значения для паролей. Как мы обсуждали в предыдущем разделе, криптографические хеш-функции работают в одном направлении, создавая выходные данные фиксированного размера, которые невозможно реверсировать.
Если организация хранит хеш пароля вместо самого пароля, она может проверить, совпадают ли эти два хеша, когда пользователь входит в систему. Пользователи вводят свои пароли, которые затем хешируются. Затем этот хеш сравнивается с хешем пароля, который хранится в базе данных. Если два хэша совпадают, то введен правильный пароль и пользователю предоставлен доступ.
Эта настройка означает, что пароль никогда не должен храниться. Если злоумышленник проникнет в базу данных, он найдет только хеши паролей, а не пароли..
Хотя хеширование паролей для хранилища не мешает злоумышленникам использовать хеши для определения паролей, это значительно усложняет их работу и отнимает много времени. Это поднимает нашу последнюю тему, соление.
Что такое соление?
Соление по существу добавление случайных данных перед их передачей через хеш-функцию, и они чаще всего используются с паролями.
Лучший способ объяснить использование солей - это обсудить, зачем они нам нужны. Вы могли подумать, что хранение хэшей паролей решило бы все наши проблемы, но, к сожалению, все немного сложнее, чем это..
Слабые пароли
У многих людей действительно плохие пароли, может быть, вы тоже. Проблема в том, что люди склонны мыслить предсказуемо и выбирать пароли, которые легко запомнить. Эти пароли уязвимы для атак по словарю, которые каждую секунду просматривают тысячи или миллионы наиболее распространенных комбинаций паролей, пытаясь найти правильный пароль для учетной записи..
Если вместо этого хранятся хэши паролей, все немного по-другому. Когда злоумышленник сталкивается с базой данных хэшей паролей, он может использовать либо хеш-таблицы или радуга столы искать подходящие хэши, которые они могут использовать, чтобы узнать пароли.
Хеш-таблица - это предварительно вычисленный список хэшей для общих паролей, который хранится в базе данных. Они требуют больше работы заблаговременно, но после того, как таблица заполнена, поиск хешей в таблице происходит намного быстрее, чем вычисление хеша для каждого возможного пароля. Еще одним преимуществом является то, что эти таблицы могут использоваться повторно.
Радужные таблицы аналогичны хеш-таблицам, за исключением того, что они занимают меньше места за счет большей вычислительной мощности.
Оба этих метода атаки становятся гораздо более практичными, если используются слабые пароли. Если у пользователя общий пароль, то, скорее всего, хеш для пароля будет в хеш-таблице или радужной таблице. Если это так, то злоумышленник может получить доступ к паролю пользователя только в течение времени..
Пользователи могут помочь предотвратить эти атаки, выбрав более длинные и сложные пароли, которые с меньшей вероятностью будут храниться в таблицах. На практике это происходит не так часто, как следовало бы, потому что пользователи, как правило, выбирают пароли, которые легко запомнить. Как простое правило, злоумышленникам часто легко найти вещи, которые легко запомнить.
Соли предлагают еще один способ обойти эту проблему. Добавляя случайную строку данных к паролю перед его хэшированием, это существенно усложняет его, что снижает вероятность успеха этих атак..
Как засолка работает на практике
Например, предположим, у вас есть учетная запись электронной почты и ваш пароль «1234». Когда мы используем онлайн-калькулятор SHA-256, в качестве значения хеш-функции мы получаем следующее:
03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4
Этот хэш будет храниться в базе данных для вашей учетной записи. Когда вы вводите свой пароль «1234”, Он хэшируется, а затем значение сравнивается с сохраненным значением. Поскольку эти два значения одинаковы, вам будет предоставлен доступ.
Если злоумышленник проникнет в базу данных, он получит доступ к этому значению, а также ко всем другим хэшам паролей, которые были там. Затем злоумышленник примет это хеш-значение и найдет его в своей предварительно вычисленной хеш-таблице или радужной таблице. поскольку «1234”Является одним из самых распространенных паролей, они быстро найдут соответствующий хеш.
Хеш-таблица скажет им, что:
03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4
Злоумышленник узнает, что ваш пароль «1234». Затем они могут использовать этот пароль для входа в свою учетную запись.
Как видите, для злоумышленника это не было большой работой. Чтобы усложнить задачу, мы добавляем соль случайных данных в пароль перед его хэшированием. Соление помогает значительно снизить шансы хеш-таблиц и радужных таблиц на получение положительного результата..
Давайте возьмем 16-символьную соль случайных данных:
H82BV63KG9SBD93B
Мы добавляем его к нашему простому паролю «1234" вот так:
1234H82BV63KG9SBD93B
Только теперь, когда мы его солили, мы выполняем ту же хеш-функцию, что и раньше, которая возвращает:
Конечно, это хеш-значение не длиннее и не сложнее, чем предыдущее, но это не главное. Хотя они оба одинаковой длины,1234H82BV63KG9SBD93B”Является гораздо менее распространенным паролем, поэтому гораздо менее вероятно, что его хеш будет храниться в хеш-таблице.
Чем менее вероятно, что пароль будет храниться в хэш-таблице, тем меньше вероятность успеха атаки. Вот как добавление солей помогает повысить безопасность паролей.
Взломать целые базы данных
Когда у злоумышленника есть доступ ко всей базе данных хэшей паролей, ему не нужно проверять каждый хеш с каждой записью. Вместо этого они могут искать во всей базе данных совпадения, которые совпадают с их хэш-таблицей.. Если база данных достаточно велика, злоумышленник может поставить под угрозу огромное количество учетных записей, даже если они имеют только пять процентов успеха.
Если перед хэшированием паролям присваиваются уникальные соли, то это значительно усложняет процесс. Если соли достаточно длинные, шансы на успех становятся намного ниже, что потребовало бы Хеш-таблицы и радужные таблицы должны быть слишком большими, чтобы можно было найти совпадающие хэши.
Другое преимущество солей возникает, когда несколько пользователей в одной и той же базе данных имеют один и тот же пароль или если один и тот же пароль для нескольких учетных записей у одного пользователя. Если хэши паролей не передаются заранее, злоумышленники могут сравнить хэши и определить, что любые учетные записи с одинаковым хэш-значением также имеют один и тот же пароль.
Это облегчает хакерам поиск наиболее распространенных хеш-значений, которые дадут им наибольшее вознаграждение. Если пароли предварительно засолены, то значения хеш-функции будут отличаться, даже если используются те же пароли.
Потенциальные недостатки соли
Соление теряет свою эффективность, если оно сделано неправильно. Две наиболее распространенные проблемы возникают, когда соли слишком короткие, или если они не уникальны для каждого пароля. Короткие соли по-прежнему уязвимы для атак радужного стола, потому что они не делают получающийся хэш достаточно редким.
Если соли используются повторно для каждого хешированного пароля, и соль обнаруживается, это значительно упрощает определение каждого пароля в базе данных. Использование той же соли также означает, что любой с тем же паролем будет иметь тот же хеш.
Общие алгоритмы посола
Не рекомендуется использовать обычные функции хеширования для хранения паролей. Вместо этого был разработан ряд функций со специальными функциями, которые помогают повысить безопасность. К ним относятся Argon2, scrypt, bcrypt и PBKDF2.
Argon2 стал победителем конкурса хэширования паролей 2015 года. Он все еще относительно нов в отношении алгоритмов, но быстро стал одной из самых надежных функций для хэширования паролей..
Несмотря на свою молодость, до сих пор он держался в ряде исследовательских работ, которые исследовали его на наличие слабых мест. Argon2 более гибок, чем другие алгоритмы хеширования паролей, и может быть реализован различными способами.
Произносится «склеп”, Это второй самый молодой алгоритм хеширования паролей, который широко используется. Разработанный в 2009 году, Scrypt использует большой, но регулируемый объем памяти в своих вычислениях. Его регулируемая природа означает, что он все еще может быть устойчивым к атакам, даже если вычислительная мощность растет со временем.
bcrypt был разработан в 1999 году и основан на шифре Blowfish. Это был один из наиболее часто используемых алгоритмов, используемых в хешировании паролей в течение многих лет, но теперь он более уязвим к программируемым полевым массивам шлюзов (FPGA). Вот почему Argon2 часто предпочтительнее в новых реализациях.
Эта функция получения ключа была разработана для замены PBKDF1, который имел более короткую и менее безопасную длину ключа. Рекомендации NIST от 2017 года по-прежнему рекомендуют PKFD2 для хэширования паролей, но Argon2 решает некоторые из его проблем безопасности и может быть лучшим вариантом во многих ситуациях..
Шифрование, перемешивание и посол: резюме
Теперь, когда мы ознакомились с деталями шифрования, хэширования и соления, пришло время быстро вернуться к рассмотрению ключевых различий, чтобы они впитались. Хотя каждый из этих процессов связан, каждый из них служит своей цели.
Шифрование - это процесс кодирования информации для ее защиты.. Когда данные зашифрованы, они могут быть расшифрованы и доступны только тем, у кого есть правильный ключ. Алгоритмы шифрования являются обратимыми, что дает нам возможность держать наши данные подальше от злоумышленников, но при этом иметь доступ к ним, когда они нам нужны. Он широко используется для обеспечения нашей безопасности в Интернете, выполняя важную роль во многих наших протоколах безопасности, которые обеспечивают безопасность наших данных при их хранении и передаче..
Определенные типы криптографических хеш-функций также используются для хранения наших паролей. Хранение хэша пароля вместо самого пароля обеспечивает дополнительный уровень безопасности. Это означает, что если злоумышленник получает доступ к базе данных, он не может сразу получить доступ к паролям.
Несмотря на то, что хэширование паролей делает жизнь хакеров более сложной, ее все же можно обойти. Это где соление приходит. Соление добавляет дополнительные данные к паролям до их хэширования, что делает атаки более трудоемкими и ресурсоемкими. Если соли и пароли используются правильно, они делают хеш-таблицы и радужные таблицы непрактичным средством атаки.
Вместе шифрование, хеширование и засоление являются важными аспектами обеспечения нашей безопасности в Интернете. Если бы этих процессов не было, злоумышленники получили бы доступ ко всем вашим учетным записям и данным, оставив вас в безопасности в Интернете..
Для использования практически любого ресурса в сети интернет необходим пароль: электронная почта, социальные сети или интернет-банк. В этой статье рассмотрим: как создать надежный пароль? За какое время злоумышленник может подобрать необходимую комбинацию цифр и букв для входа в вашу учетную запись? Расскажем про хеш-функции, а также добавим немного «соли» в наши пароли.
Для начала разберемся с базовыми понятиями.
Пароль — условное слово или набор знаков, предназначенных для подтверждения личности или полномочий.
Стойкость пароля — это количество времени, которое необходимо потратить на угадывание или подбор пароля каким-либо методом. Проще говоря — сколько злоумышленник потратит времени на подборку вашего пароля (например, методом простого перебора).
Надежность пароля – набор символов, который легко запомнить, но трудно подобрать.
Рассмотрим таблицу с количеством возможных вариантов паролей при разных условиях
Чтобы понять, как это работает. Давайте решим задачу.
Злоумышленник может угадывать 1000 паролей в секунду. Сотрудник подразделения меняет пароль раз в 90 дней. Какой минимальной длины должен быть пароль (содержащий верхний/нижний регистр, спецсимволы и цифры), чтобы злоумышленник его не взломал?
Считаем: сколько может угадать паролей злоумышленник за 90 дней.
90 (дни) * 24 (часы) * 60 (минуты) * 60 (секунды) * 1000 (кол-во паролей в секунду) = 7 776 000 000 до истечения срока действия пароля. Из нашей таблицы видно, если использовать все возможные условия, то пароля из 6 символов будет достаточно, до того момента как злоумышленник взломает пароль.
Так каким же должен быть пароль? (Немного о создании)
Пароли могут создаваться автоматически (с использованием генераторов/специализированных программ) или же самим пользователем. И все мы понимаем, что последний вариант самый распространённый. Мы придумываем пароли руководствуясь набором рекомендаций при создании учетной записи сайта или программы. Этими же шаблонами могут воспользоваться и злоумышленники. Кроме того, списки популярных паролей доступны в открытом виде. Списки включают в себя многочисленные словари различных языков, базы данных открытого текста и хешированные пароли от аккаунтов социальных сетей, а также другие общие пароли.
Что такое хешированные пароли? Рассмотрим подробнее.
Сами хешированные пароли не являются уникальными, когда задается одно и то же входное значение, всегда получится одинаковое выходное значение. Если Рома и Наташа выберут NewTechAudit2020 в качестве пароля, то и их хеш будет одинаковым:
Задача на подумать, сложные ли у ребят пароли?
Злоумышленник может попробовать атаку по словарю — используя заготовленный список слов, заранее вычисленным хешем, сравнивая хеши из украденной таблицы с украденных хешем в своем списке. Если совпадение по хешу найдено, то пароль найден и может быть использован.
Как словарные атаки, так и атаки перебором требуют вычисления хеша в реальном времени. А хорошая хэш-функция пароля работает относительно медленно, это приводит к тому, что в совокупности взлом занимает много времени. Чтобы обойти эту проблему, злоумышленник может воспользоваться радужной таблицей. Радужная таблица — это предварительно вычисленная база данных хешей. Словари и случайные строки запускаются через выбранную хеш-функцию, а отображение ввода/хеша сохраняется в таблице. Затем злоумышленник может просто выполнить обратный поиск пароля, используя хеши из украденной базы данных паролей.
Атаки радужными таблицами быстры, потому что не нужно тратить время на вычисление каких-либо хешей. Компромисс в скорости заключается в огромном количестве памяти, необходимой для размещения радужной таблицы. Можно также сказать, что атака с использованием радужной таблицей — это предварительно вычисленная атака словаря или перебором.
Основное различие между атакой с использованием радужной таблицы, атакой с помощью словаря и атакой перебором заключается в предварительном вычислении.
Поскольку время и память во время взлома ограничены, злоумышленник, разрабатывающий и вычисляющий радужную таблицу, может сначала обработать наиболее часто используемые пароли. Большие базы данных общих паролей создаются с использованием частотного анализа паролей, собранных из различных публично просочившихся инцидентов распространения технических данных пользователей.
Чтобы уменьшить риски, которые может создать радужная таблица или атака с помощью словаря, мы, как не странно это звучит, солим пароли.
Соль в данном случае — это криптографически сильное случайное значение фиксированной длины, которое добавляется ко входу хэш-функций для создания уникальных хэшей для каждого входа, независимо от того, что вход не является уникальным. Соль делает хэш-функцию недетерминированной, что хорошо, поскольку мы не хотим раскрывать дубликаты паролей через наше хэширование.
Допустим, у нас есть пароль NewTechAudit2020 и соль l0veaaaud1t. Мы можем использовать соль одним из следующих образов: добавлением соли справа — NewTechAudit2020l0veaaaud1t или добавлением соли слева — l0veaaaud1tNewTechAudit2020. Как только соль будет добавлена, мы сможем затем захешировать ее. Давайте посмотрим на это на примере с использованием следующего кода Python:
import hashlib salt = “l0veaaaud1t” password = “NewTechAudit2020” salt_password = salt + password password_salt = password +salt hash_1 = hashlib.sha256(salt_password.encode()).hexdigest() hash_2 = hashlib.sha256(password_salt.encode()).hexdigest() hash_1: e2d71ae71fcbaa8b5c525b5e9449a13a6d0d33dcdf80461be63c3d7cb7f87ff7 hash_2: ef344582eb7e3224141ea661c9d063b5dd199e49f4805ef451782a90dd271c1fДопустим, мы решили всегда добавлять соль к паролям. Если два пользователя используют один и тот же пароль, мы просто создаем более длинные пароли, которые не будут уникальными в нашей базе данных. Оба соленых пароля будут хешироваться до одного и того же значения. Но если мы выберем другую соль для того же пароля, мы получим два уникальных и более длинных пароля, которые хешируют другое значение. Давайте представим это на примере:
Наташа и Рома используют один и тот же пароль NewTechAudit2020. Для Наташи мы будем использовать соль h1m3gaw0rld, а для Ромы мы будем использовать d0kak1nggg в качестве соли.
Разные пользователи, один и тот же пароль, разные соли и в итоге разные хеши. Если бы кто-то посмотрел на полный список хешированных паролей, то никто не смог бы сказать, что Наташа и Рома используют один и тот же пароль. Каждая уникальная соль расширяет исходный пароль и преобразует его в уникальный пароль.
На практике: соль хранится в открытом тексте в базе данных вместе с хешем и именем пользователя, чтобы при входе пользователя в систему находилось его имя, добавлялась соль к предоставленному паролю. Захешировать его, а затем проверять — соответствует ли сохраненный хеш вычисленному хешу.
Итак, каким же идеальный пароль должен быть?
К сожалению, идеального пароля не существует и всегда существует вероятность его подбора. Но мы предлагаем использовать простые рекомендации по выбору надежных паролей.
Читайте также: