Разница между хешированием пароля и его шифрованием


144

В настоящее время на этот вопрос проголосовало наибольшее количество голосов :

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

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


Хорошо написанная статья о том, почему вы не должны просто хешировать свои секреты / пароли. Вместо этого используйте HMAC. benlog.com/articles/2008/06/19/dont-hash-secrets
Джей Кумар,

Превосходное резюме темы в блоге по безопасности StackExchange: security.blogoverflow.com/2011/11/…
Дэвид Дж. Лишевски,

@JayKumar: Статья, на которую вы ссылаетесь, вводит в заблуждение. Он объединяет соли паролей (которые, как ожидается, будут видны злоумышленникам) с ключами MAC (которые, как ожидается, останутся секретными). Ссылка Дэвида Дж. Лишевского дает гораздо более точное описание.
Rufflewind

Ответы:


227

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

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

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

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


1
Чтобы быть ясным, получите желаемую безопасность с помощью хэша, это должен быть криптографически безопасный алгоритм хеширования с особым свойством, что не только хэш необратим, НО ТАКЖЕ вычислительно непрактично для генерации ЛЮБОЙ другой строки, которая генерирует тот же хеш.
Высокий Джефф

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

5
шелковистый: а как именно вы собираетесь вернуть исходный пароль от вашей паршивой хеш-функции? Я предлагаю вам перечитать комментарий Дэйва
Винко Врсалович

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

1
@ n00b salt нельзя жестко запрограммировать, потому что каждый хешированный элемент должен использовать отдельную соль. Суть в том, что если и UserA, и UserB используют пароль «1234», если вы узнаете пароль UserA, вы не можете сказать, что UserB использовал один и тот же пароль, потому что у них разные соли. Сохранение солей в секрете не критично с точки зрения безопасности, большинство реализаций просто присоединяют соль к передней или задней части двоичного блоба, представляющего хэш.
Скотт Чемберлен

35

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

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

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


13

Зашифрованные и хешированные пароли

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


Извлечено из зашифрованных или хешированных паролей - что лучше?

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

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

Криптографическая хеш-функция (односторонняя)

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


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

8

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


8

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

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

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

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

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

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


4

В идеале вам следует сделать и то, и другое.

Сначала хешируйте пароль для односторонней защиты. Используйте соль для дополнительной безопасности.

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


3
Чем зашифровать? Если бы они взломали вас так сильно, что добрались до базы данных со всеми паролями ваших пользователей (хешированными, зашифрованными или другими), не смогли бы они найти ключ для их расшифровки?
Люк,

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

@ Люк Я не согласен с тобой, мой прежний я. Я видел слишком много SQL-инъекций, которые не скомпрометировали код приложения (или файлы конфигурации), и теперь я считаю, что добавление секрета полезно, будь то в форме шифрования или в форме перца, но он не должен заменять хеширование. Более полный ответ см. Здесь: security.stackexchange.com/a/31846/10863
Люк,

3

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

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

Шифрование

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

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

Если вы хотите узнать, как следует писать хэш-функции, посетите эту страницу .

Есть много алгоритмов для выполнения хеширования.

  1. MD5 - использует хэш-функцию алгоритма дайджеста сообщения 5 (MD5). Длина выходного хеша составляет 128 бит. Алгоритм MD5 был разработан Роном Ривестом в начале 1990-х годов и сегодня не является предпочтительным вариантом.

  2. SHA1 - использует хэш алгоритма безопасности (SHA1), опубликованный в 1995 году. Длина выходного хеша составляет 160 бит. Хотя этот вариант наиболее широко используется, сегодня он не является предпочтительным.

  3. HMACSHA256 , HMACSHA384 , HMACSHA512 - используйте функции SHA-256, SHA-384 и SHA-512 семейства SHA-2. SHA-2 был опубликован в 2001 году. Длина выходного хеш-кода составляет 256, 384 и 512 бит соответственно, как указывают названия хеш-функций.


1

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


-9

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

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


16
Вы явно недостаточно хорошо прочитали принятый ответ. Прочтите внимательно: вы не должны предлагать функцию восстановления пароля . Вы должны предложить функцию сброса пароля . Я управлял многими веб-сайтами в течение многих лет, включая vBulletin, phpBB, e107, IPB, blogspot и даже мою собственную CMS. Как администратору вам НИКОГДА не нужно иметь чей-то предварительно хешированный пароль. Просто нет. И у тебя тоже не должно быть. Если вы не согласны с тем, что я говорю, позвольте мне заверить вас: вы ошибаетесь.
Lakey

3
Извините за то, что был слишком зол. Я просто вижу, что слишком много веб-сайтов хранят пароли в виде простого текста, и это меня расстраивает. В качестве примечания: некоторые сайты, ориентированные на безопасность, любят периодически заставлять пользователей менять свои пароли. Они хотят убедиться, что человек не изменит свой пароль с «Пароль1» на «Пароль2». Таким образом, они сохраняют пароль в виде обычного текста, чтобы впоследствии провести эти сравнения. Это не лучшая практика. В этом случае им нужно выполнить анализ пароля ПЕРВЫМ, создав кучу похожих паролей - каждый из которых будет хешировать - и сохранить только хеши .
Lakey

7
Нет проблем, это заставило меня вернуться и перечитать вопрос, а также провести дополнительные исследования, так что еще не все потеряно :-) Я не уверен, о чем я думал, когда писал этот ответ. ура
Philtron
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.