Правильное хеширование паролей

Хеширование данных

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

Это определение означает, что с помощью алгоритма хеширования

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

Известными алгоритмами хеширования являются MD5, SHA-1 и SHA-2.

Основные принципы хеширования

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

Одним из самых простых применений хеширования является хранение паролей (считается более защищённым способом, чем хранение паролей в явном виде).

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

Наводим порядок в Active Directory с помощью ЗУП / ЗИКГУ 3.1 (идентификация, отключение и актуализация учетных записей пользователей)

Продолжаем использовать ЗУП 3.1 совместно с LDAP во имя автоматизации работы системного администратора. В этот раз займемся аудитом учетных записей. Обработка производит сопоставление учетной записи с данными сотрудников из ЗУП, причем с учетом недавних событий (для перехода на ЗУП 3.1 чаще всего используется рекомендованный перенос, не включающий уволенных сотрудников) есть возможность использовать объединенные с помощью COM-соединения данные ЗУП 2.5 и ЗУП 3.1. Также в данной обработке есть возможность массовой корректировки, заполнения данных и отключения учетных записей. Перед использованием обработки для душевного спокойствия необходимо сделать резервную копию Active Directory любым удобным способом. Протестировано на ЗУП 3.1.6 — 3.1.8.

5 стартмани

Создание соли для Blowfish алгоритма

/**
 * Generate a random salt in the crypt(3) standard Blowfish format.
 *
 * @param int $cost Cost parameter from 4 to 31.
 *
 * @throws Exception on invalid cost parameter.
 * @return string A Blowfish hash salt for use in PHP's crypt()
 */
function blowfishSalt($cost = 13)
{
    if (!is_numeric($cost) || $cost < 4 || $cost > 31) {
        throw new Exception("cost parameter must be between 4 and 31");
    }
    $rand = array();
    for ($i = 0; $i < 8; $i += 1) {
        $rand[] = pack('S', mt_rand(0, 0xffff));
    }
    $rand[] = substr(microtime(), 2, 6);
    $rand = sha1(implode('', $rand), true);
    $salt = '$2a$' . sprintf('%02d', $cost) . '$';
    $salt .= strtr(substr(base64_encode($rand), 0, 22), array('+' => '.'));
    return $salt;
}

Пример регистрации пользователя с проверкой пароля

Python

import hashlib
import os

users = {} # Простое демо хранилище

# Add a user
username = ‘Brent’ # Имя пользователя
password = ‘mypassword’ # Пароль пользователя

salt = os.urandom(32) # Новая соль для данного пользователя
key = hashlib.pbkdf2_hmac(‘sha256’, password.encode(‘utf-8’), salt, 100000)
users = { # Хранение ключа и соли
‘salt’: salt,
‘key’: key
}

# Попытка проверки 1 (неправильный пароль)
username = ‘Brent’
password = ‘notmypassword’

salt = users # Получение соли
key = users # Получение правильного ключа
new_key = hashlib.pbkdf2_hmac(‘sha256’, password.encode(‘utf-8’), salt, 100000)

assert key != new_key # Ключи не совпадают, следовательно, пароли не совпадают

# Попытка проверки 2 (правильный пароль)
username = ‘Brent’
password = ‘mypassword’

salt = users
key = users
new_key = hashlib.pbkdf2_hmac(‘sha256’, password.encode(‘utf-8’), salt, 100000)

assert key == new_key # Ключи совпадают, следовательно, и пароли совпадают

# Добавление нового пользователя
username = ‘Jarrod’
password = ‘my$ecur3p@$$w0rd’

salt = os.urandom(32) # Новая соль для данного пользователя
key = hashlib.pbkdf2_hmac(‘sha256’, password.encode(‘utf-8’), salt, 100000)
users = {
‘salt’: salt,
‘key’: key
}

# Проверяем правильно ли введен пароль
username = ‘Jarrod’
password = ‘my$ecur3p@$$w0rd’

salt = users
key = users
new_key = hashlib.pbkdf2_hmac(‘sha256’, password.encode(‘utf-8’), salt, 100000)

assert key == new_key # Ключи совпадают, поэтому совпадают пароли и у этого пользователя

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

importhashlib

importos

users={}# Простое демо хранилище

# Add a user

username=’Brent’# Имя пользователя

password=’mypassword’# Пароль пользователя

salt=os.urandom(32)# Новая соль для данного пользователя

key=hashlib.pbkdf2_hmac(‘sha256’,password.encode(‘utf-8’),salt,100000)

usersusername={# Хранение ключа и соли

‘salt’salt,

‘key’key

}

# Попытка проверки 1 (неправильный пароль)

username=’Brent’

password=’notmypassword’

salt=usersusername’salt’# Получение соли

key=usersusername’key’# Получение правильного ключа

new_key=hashlib.pbkdf2_hmac(‘sha256’,password.encode(‘utf-8’),salt,100000)

assertkey!=new_key# Ключи не совпадают, следовательно, пароли не совпадают

# Попытка проверки 2 (правильный пароль)

username=’Brent’

password=’mypassword’

salt=usersusername’salt’

key=usersusername’key’

new_key=hashlib.pbkdf2_hmac(‘sha256’,password.encode(‘utf-8’),salt,100000)

assertkey==new_key# Ключи совпадают, следовательно, и пароли совпадают

# Добавление нового пользователя

username=’Jarrod’

password=’my$ecur3p@$$w0rd’

salt=os.urandom(32)# Новая соль для данного пользователя

key=hashlib.pbkdf2_hmac(‘sha256’,password.encode(‘utf-8’),salt,100000)

usersusername={

‘salt’salt,

‘key’key

}

# Проверяем правильно ли введен пароль

username=’Jarrod’

password=’my$ecur3p@$$w0rd’

salt=usersusername’salt’

key=usersusername’key’

new_key=hashlib.pbkdf2_hmac(‘sha256’,password.encode(‘utf-8’),salt,100000)

assertkey==new_key# Ключи совпадают, поэтому совпадают пароли и у этого пользователя

Таблицы поиска

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

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

c11083b4b0a7743af748c85d343dfee9fbb8b2576c05f3a7f0d632b0926aadfc08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f9045206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd

Шифрование и хеширование

Шифрование — это обратимое преобразование текста в случайный набор символов.

Хеширование — это необратимое преобразование текста в случайный набор символов.

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

Приведу пример шифрования. У нас есть сообщение:

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

Зашифровали. Теперь для расшифровки нужно выполнить обратную операцию, сдвинуть все буквы на 1 символ назад. К слову, этот алгоритм шифрования называется шифр Цезаря (Википедия).

В отличие от шифрования, хеширование не имеет (вернее, не должно иметь) способа «расхешировать» строку обратно:

Хранение паролей в web-приложении

Существует много примеров и материалов, в которых показано как хранить пароли в базе данных.

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

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

Очень распространенная ошибка это быстрые хэши. Например, MD5 — очень быстрый алгоритм хэширования, впрочем как и все SHA алгоритмы. Например, на NVIDIA GeForce 8800 можна генерировать 200 миллионов MD5 хэшей в секунду. Из этого следует, что использование быстрых алгоритмов хеширования, даже с примесью «соли» не эффективно. Обычным перебором можно сравнительно быстро подобрать хеш, а соответственно и пароль пользователя. По этому систему с хранением паролей в виде md5(«password») — можно считать открытой для злоумышленника.

Например, на сервере для вычисления одного хэша используя алгоритм md5, в среднем, требуется 10мксек. Пароль хранится в базе данных, как хеш от введенного значения пользователя(md5(«password»)). Злоумышленник каким то образом получил базу логинов с хешами паролей и пытается расшифровать их. Алгоритм расшифровки самый простой — перебор. Понятно что для вычисления тысячи хешей требуется 10мксек*1000 = 10мсек, для миллиона 10мксек*1000000 = 1сек и т.д. Из этого следует, что чем быстрее алгоритм хеширования, тем быстрее злоумышленник подберет больше количество паролей за меньший промежуток времени. Из вышесказанного сановится ясным, что чем медленее алгоритм вычисления хеш функции, тем надежнее.

Blowfish — криптографический алгоритм, реализующий блочное симметричное шифрование. Потребляет сравнительно большое количество вычислительных ресурсов и в настоящее время считается довольно не плохим алгоримом для шифрования паролей. В PHP реализция доступна простым вызовом crypt(). Подобор весового параметра производится таким образом, что бы атака перебором была достаточно медленная, а вычисление хеша для пользователя незаметным по времени. 200-300 мсек на продакшн сервере вполне достаточно для этого.

Для более стойкого хеша добавляют соль. Соль — слово, фраза, рандомное значение температуры, динамическое изминение чего либо, которое добавляется произвольно для формирования конечного хеша. Например, md5($password . md5($salt)). Из каждого пароля должен формироваться хеш с уникальной солью. Цель добавлнения соли — увеличения размера словаря для атаки типа перебор по словарю или для радужных таблиц. Соль, которая используется вместе с Blowfish, не объязательно должна быть криптографическо стойкой случайной строкой. Достаточно использовать соль с псевдослучайных чисел, этого достаточно для предотвращения подбора пароля по радужным таблицам.

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

Что вообще делает хороший пароль?

Энтропия . (Не то чтобы я полностью разделял точку зрения Рэндалла.)

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

Пароль энтропия приближена легко. Использование полного диапазона символов ascii (примерно 96 набираемых символов) дает энтропию 6,6 на символ, что при 8 символах для пароля все еще слишком мало (52,679 бит энтропии) для обеспечения безопасности в будущем. Но есть и хорошие новости: более длинные пароли и пароли с символами Юникода действительно увеличивают энтропию пароля и затрудняют его взлом.

На сайте Crypto StackExchange есть более подробное обсуждение энтропии паролей . Хороший поиск в Google также даст много результатов.

Насколько я могу судить, лучший пароль в мире — это Catch-22. Либо он не запоминающийся, либо слишком предсказуемый, либо слишком короткий, либо слишком много символов Юникода (трудно вводить на устройстве Windows / Mobile), слишком длинный и т. Д. Никакой пароль не подходит для наших целей, поэтому мы должны защищать их так, как будто они были в Форт-Ноксе.

Двойное хеширование и прочие заблуждения

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

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

md5(sha1(password))md5(md5(salt) + md5(password))sha1(sha1(password))sha1(str_rot13(password + salt))md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))

Никогда не используйте ничего подобного!

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

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

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

Коллизии хешей

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

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

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

Как нужно хешировать

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

TL; DR

Не делать

Не ограничивайте количество символов, которые пользователи могут вводить для паролей. Это делают только идиоты.
Не ограничивайте длину пароля. Если вашим пользователям нужно предложение с supercalifragilisticexpialidocious в нем, не мешайте им его использовать.
Не удаляйте и не экранируйте HTML и специальные символы в пароле.
Никогда не храните пароль пользователя в виде обычного текста.
Никогда не отправляйте своему пользователю пароль по электронной почте, кроме тех случаев, когда он потерял свой пароль , а вы отправили ему временный.
Никогда и никогда не регистрируйте пароли каким-либо образом.
Никогда не хешируйте пароли с помощью SHA1, MD5 или даже SHA256! Современные взломщики могут превышать 60 и 180 миллиардов хэшей в секунду (соответственно).
Не смешивайте bcrypt и необработанный вывод hash () , используйте либо шестнадцатеричный вывод, либо base64_encode. (Это относится к любому входу, в котором может быть мошенничество , что может серьезно ослабить безопасность.)

Принадлежащий

По возможности используйте scrypt; bcrypt, если не можете.
Используйте PBKDF2, если вы не можете использовать bcrypt или scrypt с хешами SHA2.
Сброс всех паролей при взломе базы данных.
Обеспечьте разумную минимальную длину 8–10 символов, а также потребуйте минимум 1 букву в верхнем регистре, 1 букву в нижнем регистре, число и символ. Это улучшит энтропию пароля, что, в свою очередь, затруднит его взлом. (См. Раздел «Что такое хороший пароль?» Для обсуждения некоторых вопросов.)

Какими свойствами должна обладать хеш-функция

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

Применения в реальной жизни

Чек-суммы. Простой и быстрый способ проверить целостность большого передаваемого файла — посчитать хэш-функцию на стороне отправителя и на стороне получателя и сравнить.
Хэш-таблица. Класс unordered_set из STL можно реализовать так: заведём (n) изначально пустых односвязных списков. Возьмем какую-нибудь хэш-функцию (f) с областью значений ([0, n)). При обработке .insert(x) мы будем добавлять элемент (x) в (f(x))-тый список. При ответе на .find(x) мы будем проверять, лежит ли (x)-тый элемент в (f(x))-том списке. Благодаря «равномерности» хэш-функции, после (k) добавлений ожидаемое количество сравнений будет равно (frac{k}{n}) = (O(1)) при правильном выборе (n).
Мемоизация. В динамическом программировании нам иногда надо работать с состояниями, которые непонятно как кодировать, чтобы «разгладить» в массив. Пример: шахматные позиции. В таком случае нужно писать динамику рекурсивно и хранить подсчитанные значения в хэш-таблице, а для идентификации состояния использовать его хэш.
Проверка на изоморфизм. Если нам нужно проверить, что какие-нибудь сложные структуры (например, деревья) совпадают, то мы можем придумать для них хэш-функцию и сравнивать их хэши аналогично примеру со строками.
Криптография. Правильнее и безопаснее хранить хэши паролей в базе данных вместо самих паролей — хэш-функцию нельзя однозначно восстановить.
Поиск в многомерных пространствах. Детерминированный поиск ближайшей точки среди (m) точек в (n)-мерном пространстве быстро не решается. Однако можно придумать хэш-функцию, присваивающую лежащим рядом элементам одинаковые хэши, и делать поиск только среди элементов с тем же хэшом, что у запроса.

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

Источники

https://ru.crypto-news.io/articles/heshirovanie-ego-funkcii-i-svoistva.html
https://zen.yandex.ru/media/info_law_society/shifrovanie-heshirovanie-kodirovanie-dannyh-razlichiia-i-primenenie-5d6168b0c31e4900ad8a4614
https://habr.com/ru/post/93226/
https://KtoNaNovenkogo.ru/voprosy-i-otvety/xesh-chto-eto-takoe-xesh-funkciya.html
https://coderlessons.com/tutorials/akademicheskii/izuchite-kriptografiiu/kriptografiia-khesh-funktsii
https://OptimaKomp.ru/chto-takoe-khesh-summa-fajjla-zachem-i-kak-ejo-zameryat/
https://vellisa.ru/hashtab-kontrolnyie-summyi-fayla
https://algorithmica.org/ru/hashing

Соли @ хешируй

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

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

Нет! Без так называемой «соли» многие пароли можно подобрать за секунду если там использовать просто md5(pass). Не веришь? Читай ниже.

Соль — случайно сгенерированная последовательность символов, которая хранится рядом с хешем. Дан пароль , мы генерируем случайную соль например и получаем хеш от «соль + пароль»: . В базу сохраняется отдельно использованная соль (она для каждого пользователя своя), отдельно хеш.

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

Способ 1

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

Считаем число вариантов.

Если в пароле 12 цифр : число комбинаций = 10^12 = 1000 миллиардов = 100 секунд перебора на 1 видеокарте (1 секунда на 100 карточках параллельно).
Если 6 букв или цифр . Число вариантов = 36^6 (считаем гуглом) = 2 млрд. Хехе, меньше секунды.
Если 6 букв (добавим маленькие и большие буквы) и . Комбинаций 62^6 = 56 млрд. 6 секунд перебора.
Если в пароле 8 букв и цифр . Комбинаций уже 62^8 = 218 триллионов. Это 22000 секунд перебора (в часе 3600 секунд, так что выходит 6 часов) на 1 карточке или 220 секунд на 100 карточках. Ого, не очень-то надежно.
Если в пароле 10 символов + 20 знаков вроде минус, плюс.. то выходит 82^10 комбинаций ~ 10^19 и перебирать их 10^9 секунд на одной карте (11500 дней) или 115 дней на сотне карточек.

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

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

Способ 2

Вот пример такой таблицы: — подбирает пароли без соли до 10 символов .

Заметь что в будущем компьютеры будут мощнее, и значит подбираться пароли будут быстрее. Теперь подумаем как защититься и усложнить жизнь взломщикам:

разрешаем использовать больше видов символов в паролях
добавляем соль. С солью не получится параллельно подбирать все хеши так как у каждого юзера соль своя и каждый хеш надо перебирать отдельно, что сильно замедляет взлом. Также, при добавлении соли даже к простому паролю он по сути становится длинным и сложным и его не будет в радужных таблицах (123456 → Y^juYUHkd%$fdtd123456). Опять же, соль должна быть подлиннее и содержать спецсимволы чтобы было больше комбинаций для перебора. Ну конечно, простые пароли типа 123456 все равно вскроют, так как их при переборе проверяют в первую очередь. А вот сложные придется подбирать долго.
используем вместо md5 более тяжелые для вычисления алгоритмы вроде bcrypt, который сделан так, что его нельзя перебрать быстрее чем за опредеенное время (и ты можешь указать требемый уровень сложности).

С правильным подходом даже простой md5 замучаешься расшифровывать.

Льготы

Чтобы понять разницу между взломом одного пароля и их набора, рассмотрим один файл паролей, содержащий сотни имен пользователей и хешированных паролей. Без соли злоумышленник может вычислить хэш (попытка ), а затем проверить, появляется ли этот хеш где-нибудь в файле. Вероятность совпадения, то есть взлома одного из паролей с помощью этой попытки, увеличивается с увеличением количества паролей в файле. Если присутствуют соли, злоумышленник должен будет вычислить хэш (соль , попытка ), сравнить с записью A, затем хэш (соль , попытка ), сравнить с записью B и скоро. Это предотвращает «повторное использование» хэшей при попытках взлома нескольких паролей.

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

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

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

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

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

Как проверяется пароль

Для проверки пароля (например, в онлайновых сервисах или при входе в локальную учётную запись Windows, Linux или macOS) по заданному алгоритму подсчитывается его хэш, который система сравнивает с контрольной строкой. Рассмотрим для примера файл /etc/shadow, в котором хранятся пароли к ОС Linux.

В описаниях формата /etc/shadow часто можно встретить упоминание, что в файле хранятся «зашифрованные пароли». Как вы уже знаете, это не так: на самом деле в файле /etc/shadow хранятся хеши паролей, соль и некоторая дополнительная информация, включая информацию о том, каким образом должен вычисляться хэш. Хэши паролей хранятся хранятся в виде $type$salt$hashed, где значение переменной type указывает на тип хеш-функции из следующего списка:

$1$ — MD5
$2a$ — Blowfish
$2y$ — Blowfish
$5$ — SHA-256
$6$ — SHA-512

В примере ниже приводится начало строки из файла /etc/shadow (у неё есть продолжение, в котором содержится сервисная информация — такая, как время последней смены пароля, оставшийся срок действия пароля и т.п.)

root:$6$Zwg4GkPw$5ggbsXCbCzjT3i8O7DGUqXH8vQiPqCySGLWSPDVR4ionV3AIkG0rqjeosDZGwpCQmsH6oP.6jqz6Zr.oA2DbA/

Здесь «root» — имя пользователя, $6$ указывает на то, что используется алгоритм хеширования SHA-512, «Zwg4GkPw» — соль, а строка, начинающаяся с «$5ggbs» — соответственно, хэш от пароля. В качестве эксперимента вы можете попробовать восстановить этот пароль или самостоятельно сгенерировать его командой mkpasswd -m sha-512 PASSWORD

Обратите внимание: если отредактировать файл /etc/shadow (для этого нужен доступ root), то пароль любого пользователя можно сменить, зайдя от его имени. А можно ли сделать так же, например, для зашифрованного архива или документа?

Актуальные способы взлома паролей

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

Взлом паролей на основе словаря

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

Хобби или близкие люди
Легко запоминаемый пароль

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

Брутфорс (перебор пароля / грубая сила)

Атака перебором подбирает все возможные популярные комбинации логин / пароль. Пользователи еще не разучились использовать простые распространенные пароли и поэтому этот способ считается довольно эффективным.

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

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

Гибридная атака брутфорс

Гибридная атака представляет собой комбинацию брутфорс атаки и словаря на основе увлечений и имен близкий людей пользователя.

Например, пользователи часто добавляют набор цифр в конце своих учетных данных, таких как год окончания или год рождения (например, lena1992 или dima2013). Таким образом, хакеры используют атаку по словарю для генерации фраз, а затем проводят атаку методом перебора последних цифр.

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

Атаки по радужному таблицам

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

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

Этот способ часто используется при взломе пароля WiFi-сетей и операционной системы.

Хеширование данных

Наводим порядок в Active Directory с помощью ЗУП / ЗИКГУ 3.1 (идентификация, отключение и актуализация учетных записей пользователей)

Создание соли для Blowfish алгоритма

Пример регистрации пользователя с проверкой пароля

Таблицы поиска

Шифрование и хеширование

Популярные

Хранение паролей в web-приложении

Что вообще делает хороший пароль?

Двойное хеширование и прочие заблуждения

Коллизии хешей

Как нужно хешировать

TL; DR

Не делать

Принадлежащий

Какими свойствами должна обладать хеш-функция

Применения в реальной жизни

Соли @ хешируй

Способ 1

Способ 2

Льготы

Как проверяется пароль

Актуальные способы взлома паролей

Взлом паролей на основе словаря

Брутфорс (перебор пароля / грубая сила)

Гибридная атака брутфорс

Атаки по радужному таблицам