Предположим, вы создали учетную запись на сайте VerySecureWebsite.com. Вы вводите свой адрес электронной почты и пароль и настраиваете свою учетную запись. Спустя некоторое время вы получаете электронное письмо, в котором сообщается, что, по иронии судьбы, веб-сайт был взломан, а имена пользователей и пароли каждого пользователя, хранившиеся в открытом виде, теперь выставлены на продажу на темная паутина . Когда вы начинаете менять пароли на всех своих учетных записях (ты пользуешься только одной, чудовище), ты задаешься вопросом: «Разве это не плохая идея? Разве мой пароль не должен быть в каком-то секретном коде, чтобы хакеры не могли его прочитать?”
Вы правы. Любое веб-приложение или сервис, использующий систему входа в систему по имени пользователя и паролю, должно хранить пароли своих пользователей с использованием соленого хеша, возможно, даже медленного соленого хеша, возможно, с перцем. Если это начинает больше походить на завтрак, чем на криптографию, не волнуйтесь: в отличие от вашего пароля (надеюсь), безопасное хранение паролей не так уж и сложно взломать.
Читайте также: Почему ограничения паролей на веб-сайтах не обеспечивают вашу безопасность
Открытый текст и базовое шифрование
| Имя пользователя | Введенный пароль | Сохранено form |
|---|---|---|
| UnwittingUser | WeakPassword | WeakPassword |
Хранить пароли в открытом виде в базе данных, подключенной к Интернету, — довольно плохая идея: если база данных будет взломана, любой, кто повторно использовал один из этих паролей, теперь окажется под угрозой. И все же тревожное количество веб-сайтов все еще делают это , вероятно, потому, что обновления безопасности больше предназначены для клиентов, чем для компании. Если вы хотите проверить, делает ли это сайт, попробуйте выбрать опцию «забыли пароль». Если они прос
Contents
Открытый текст и базовое шифрование
оса, он будет сохранен в виде открытого текста.| Имя пользователя | Введенный пароль | Зашифровано ключом AES-128: WeakKey |
|---|---|---|
| UnwittingUser | WeakPassword | 38MkoXVXoKe01uAOROBLpQ== |
Шифрование может показаться надежным способом хранения паролей, но на самом деле это всего лишь шаг вперед по сравнению с открытым текстом. Зашифрованный пароль обычно можно расшифровать с помощью ключа, и если хакеры смогут его найти или угадать, шифрование бесполезно.
Хеширование >шифрование
| Имя пользователя | Введенный пароль | Строка для хеширования | Хешируется с помощью SHA-256 |
|---|---|---|---|
| UnwittingUser | WeakPassword | WeakPassword | 252E2406732308F9A7 B378ED94E78467D14 077D19C8282443FCD 3D6190FCABFA |
Хеш-функция — это, по сути, одностороннее шифрование: вы преобразуете открытый текстовый пароль в секретный код, но нет ключа для его обратного преобразования, а это означает, что вы никогда не сможете получить действительный пароль из хешированной версии.
Вот как большинство безопасных веб-сайтов управляют своими паролями:
- Пользователь создает учетную запись
- Пароль пользователя обрабатывается хэш-функцией и сохраняется в базе данных.
- Каждый раз, когда пользователь входит в систему, база данных хеширует введенный им пароль и проверяет, соответствует ли введенный хэш хэшу, который имеется в файле.
- Если да, пользователь может войти в систему.
При использовании хэша приложение/сайт никогда и нигде не хранит ваш настоящий пароль, и хакер, взломавший его, получит только список букв и цифр, которые невозможно расшифровать. В зависимости от того, насколько силен алгоритм, взломать эти хеши может быть довольно сложно.
Однако хеши не защищены от взлома. Все, что нужно сделать злоумышленнику, — это запустить словарь потенциальных паролей через хэш-функцию, а затем сравнить эти хэши с хэшами в базе данных. Когда два хеша совпадают, хакер может просто посмотреть, какой пароль сгенерировал этот хэш.
Чтобы сэкономить время и вычислительную мощность, многие злоумышленники просто используют таблицу поиска (или «радужную таблицу», компактную версию таблиц поиска), заранее созданную таблицу, полную потенциальных пар
Хеширование >шифрование
бовать хеширование слова открытого текста , а затем использовать таблицу поиска по хешу самостоятельно; это не так уж сложно. По сути, если ваш пароль вообще распространен, хэш этого пароля, вероятно, уже находится в справочной таблице. Это отличная причина не использовать общие пароли .Читайте также: Создайте надежный пароль, используя эти советы и инструменты
Соленые хеши >хеши
| Имя пользователя | Введенный пароль | Строка для хеширования | Хешируется с помощью SHA-256, salt = XcyKn42, добавлено |
|---|---|---|---|
| UnwittingUser | WeakPassword | XcyKn42WeakPassword | 13EB660FF7FBD29A728FC5 92297D78DF19AFF8797363 15FBF1F1C4B7123BD10C |
В отличие от слизней, соль делает хэши сильнее. Поскольку весь хэш изменяется, даже если изменяется хотя бы одна буква слова открытого текста, все, что сайту нужно сделать, чтобы сорвать справочные таблицы, — это добавить дополнительный открытый текст к паролю передего хешированием. Злоумышленник сможет прочитать соль в виде открытого текста, поскольку она хранится в базе данных, но ему придется пересчитывать все возможные комбинации потенциальных паролей и солей.
Конечно, соленые хеши все равно можно взломать. Хакеры могут просто добавить соль к паролю, который они угадывают, хэшировать комбинацию и ждать появления совпадений – стандартная атака по словарю. Поскольку современные графические процессоры могут делать миллиарды предположений в секунду, это вовсе не невозможно, но это делает процесс намного более раздражающим. В противном случае атаки методом грубой силы будут медленными, но очень эффективными.
Как сделать хеши еще сильнее: другие тактики
| Имя пользователя | Введенный пароль | Строка для хеширования | Хешируется с помощью Bcrypt, salt = XcyKn42, с добавлением, 12 раундов |
|---|---|---|---|
| UnwittingUser | WeakPassword | XcyKn42WeakPassword | $2y$12$6OleutQBO2iPoNvg pyDndOU26Lqt9Y34f6PLEOx mCELP5GoswrJT. |
Алгоритмы медленного хеширования, такие как PBKDF2 или bcrypt, используют технику, известную как «растягивание ключа», для замедления атак по словарю и перебора. По сути, это включает в себя настройку хэш-функции на итерацию определенное количество раз (хотя это немного сложнее, чем просто запускать одно и то же снова и снова), так что для достижения правильного хеш-функции вам придется использовать много вычислений. власть. Если сайт делает все это, его безопасность довольно хорошая.
| Имя пользователя | Введенный пароль | Строка для хеширования | Хешируется с помощью Bcrypt, salt = XcyKn42, добавлено, 12 раундов, pepper = |4|\/|@p3pp3r, добавлено |
|---|---|---|---|
| UnwittingUser | WeakPassword | XcyKn42WeakPassword|4|\/|@p3pp3r | $2y$12$njmWr5UMydCzdCE44ElW/<бр>OIfYp2PH9sgonCAtyVY.OVKSpmoSaZlu |
Для дополнительной безопасности вы также можете «поперчить» свои хэши, которые, надеюсь, уже посолены. Перец, как и соль, представляет собой набор значений, прикрепленных к паролю до его хеширования. Однако, в отличие от соли, существует только одно значение перца, и оно хранится в секрете, отдельно от солей и хэшей. Он добавляет еще один уровень безопасности к соленому хэшу, но если злоумышленнику удастся его найти, он уже бесполезен, поскольку злоумышленник может просто использовать его для вычисления новых таблиц поиска.
Не делайте хеш из своего хеша
Защита паролей достигла больших успехов, как и искусство взлома этой защиты. К сожалению, люди по-прежнему плохо управляют паролями, а базы данных не повышают безопасность
Соленые хеши >хеши
. В общем, предположим, что всякий раз, когда вы создаете учетную запись, пароль хранится с относительно слабой безопасностью. Если ваш пароль является общим или словарным словом, то риск его взлома довольно высок. Делайте свои пароли длинными, смешивая буквы, цифры и символы, и вы поможете хеш-функциям работать максимально эффективно.Авторы изображений: Хэш-функция
