Хеширование против шифрования: как ваш пароль хранится на сервере



Хеширование против шифрования: как ваш пароль хранится на сервере

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

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

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

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

Открытый текст и простое шифрование

UsernameEntered PasswordStored formUnwittingUserWeakPasswordWeakPassword

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

UsernameEntered PasswordEncrypted с ключом AES-128: WeakKeyUnwittingUserWeakPassword38MkoXVXoKe01uAOROBLpQ ==

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

Хеширование и шифрование

UsernameEntered PasswordString будет hashedHashed с SHA-256UnwittingUserWeakPasswordWeakPassword252E2406732308F9A7
B378ED94E78467D14
077D19C8282443FCD
3D6190FCABFA

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

Именно так большинство защищенных веб-сайтов управляют своими паролями:

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

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

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

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

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

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

Связанные: создание надежного пароля с помощью этих советов и инструментов

Соленые хэши и хэши

UsernameEntered PasswordString быть hashedHashed с SHA-256,
соль = XcyKn42, prependedUnwittingUserWeakPasswordXcyKn42WeakPassword13EB660FF7FBD29A728FC5
92297D78DF19AFF8797363
15FBF1F1C4B7123BD10C < р0> в отличие от слизней, соль делает хешей сильнее.Так как целые изменения хэша, даже если только одна буквы открытого текста слова изменилось, все на сайте нужно сделать, чтобы расстроить справочные таблицы, это добавить некоторый дополнительный открытый текст пароля перед его хэшируется. Злоумышленник сможет прочитать исходный текст соли, так как она хранится в базе данных, но это заставляет их пересчитывать все возможные комбинации потенциальных паролей и солей.

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

Создание хэша и усиление: другие тактики

UsernameEntered PasswordString быть hashedHashed с Bcrypt,
salt = XcyKn42, с добавлением,
12 раундов UnwittingUserWeakPasswordXcyKn42WeakPassword $ 2y $ 12 $ 6OleutQBO2iPoNvg
pyDndOU26Lqt9Y34f6PLEOx, псевдоним

То есть; как «растяжение ключа» для замедления словарных и грубых атак.По сути, это включает в себя настройку хеш-функции для итерации определенного количества раз (хотя это немного сложнее, чем просто повторять одно и то же), так что для получения правильного хеша вам придется использовать много вычислений. мощность. Если сайт делает все это, его безопасность довольно хорошая. < Имя_пользователя>. Введите PasswordString для хеширования. Хэшируется с помощью Bcrypt,
salt = XcyKn42, с добавлением префикса,
12 раундов,
pepper = | 4 | / | @ p3pp3r; — которые, надеюсь, уже соленые. Перец, как соль, представляет собой набор значений, прикрепленных к паролю до его хэширования. В отличие от соли, однако, есть только одна ценность перца, и она держится в секрете, отдельно от солей и хэшей. Это добавляет еще один уровень безопасности к соленому хешу, но если злоумышленнику удастся его найти, он больше не очень полезен, поскольку злоумышленник может просто использовать его для вычисления новых справочных таблиц.

Не создавайте хеш вашего хэша

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

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

Хеширование против шифрования: как ваш пароль хранится на сервере
Метки:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *