Что лучше md5 или sha256
Что такое контрольная сумма файла
К онтрольная сумма — это последовательность цифр и букв, используемая для проверки данных на наличие ошибок. Если Вам известна контрольная сумма исходного файла, Вы можете использовать специальную утилиту чтобы убедиться, что Ваша копия идентична.
Объяснение контрольных сумм
Чтобы получить контрольную сумму, Вы запускаете программу, которая обрабатывает этот файл алгоритмом. Типичные алгоритмы, используемые для этого, включают MD5, SHA-1, SHA-256 и SHA-512.
Алгоритм использует криптографическую хеш-функцию, которая принимает входные данные и создает строку (последовательность цифр и букв) фиксированной длины. Входным файлом может быть небольшой файл размером 1 МБ или большой файл размером 4 ГБ, но в любом случае Вы получите контрольную сумму такой же длины. Контрольные суммы также могут называться «хешами».
Небольшие изменения в файле приводят к иному виду контрольных сумм. Например, два разных текстовых файла, которые почти одинаковы, но у одного есть восклицательный знак, а у другого — точка будут иметь разные контрольные суммы. Разница в один символ в файле дает другую контрольную сумму.
Когда контрольные суммы полезны
Вы можете использовать контрольные суммы для проверки файлов и других данных на наличие ошибок, возникающих во время передачи или хранения. Например, файл мог быть неправильно загружен из-за проблем с сетью или проблемы с жестким диском могли вызвать повреждение файла на диске.
Если Вы знаете контрольную сумму исходного файла, Вы можете запустить для нее утилиту хеширования. Если полученная контрольная сумма совпадает, Вы знаете, что файл у Вас идентичен.
Компьютеры используют методы контрольной суммы для проверки данных на наличие проблем в фоновом режиме, но Вы также можете сделать это самостоятельно. Например, дистрибутивы Linux часто предоставляют контрольные суммы, чтобы Вы могли проверить правильно загруженный ISO-образ Linux, прежде чем записывать его на диск или помещать на USB-накопитель. Вы также можете использовать контрольные суммы для проверки целостности любого другого типа файла, от приложений до документов и носителей. Вам просто нужно знать контрольную сумму исходного файла.
В чем разница между хешами MD5, SHA-1 и SHA-256
Контрольные суммы — это полезный способ убедиться, что в файле нет ошибок. Если ошибка возникает из-за проблем с загрузкой или проблем с жестким диском, результирующая контрольная сумма будет другой, даже если это небольшая ошибка.
Однако эти криптографические хеш-функции несовершенны. Исследователи безопасности обнаружили «коллизии» с функциями MD5 и SHA-1. Другими словами, они обнаружили два разных файла, которые производят один и тот же хэш MD5 или SHA-1.
Это вряд ли произойдет случайно, но злоумышленник может использовать эту технику, чтобы замаскировать вредоносный файл. Вот почему не следует полагаться на суммы MD5 или SHA-1 для проверки подлинности файла — только для проверки на наличие повреждений.
Сообщений о конфликте SHA-256 пока не поступало, поэтому приложения теперь создают суммы SHA-256 вместо сумм MD5 и SHA-1. SHA-256 — более сильный и безопасный алгоритм.
Различные алгоритмы контрольной суммы дают разные результаты. Файл будет иметь разные контрольные суммы MD5, SHA-1 и SHA–256. Если Вам известна только сумма MD5 исходного файла, Вы должны вычислить сумму MD5 своей копии, чтобы проверить, совпадает ли она.
Как рассчитать контрольную сумму
Если Вы знаете контрольную сумму исходного файла и хотите проверить ее на своем компьютере, Вы можете легко это сделать. Windows, macOS и Linux имеют встроенные утилиты для генерации контрольных сумм. Вам не нужны сторонние утилиты.
В Windows команда PowerShell Get-FileHash вычисляет контрольную сумму файла. Чтобы использовать ее, сначала откройте PowerShell. В Windows 10 щелкните правой кнопкой мыши кнопку «Пуск» и выберите «Windows PowerShell». Вы также можете запустить его, выполнив поиск в меню «Пуск» по запросу «PowerShell» и щелкнув ярлык «Windows PowerShell».
Get-FileHash входит в состав Windows 10. Но в Windows 7 Вам необходимо установить обновление PowerShell 4.0.
В командной строке введите Get-FileHash и нажмите клавишу пробела.
Введите путь к файлу, для которого Вы хотите вычислить контрольную сумму. Или, чтобы упростить задачу, перетащите файл из окна проводника в окно PowerShell, чтобы автоматически указать путь к нему.
Нажмите Enter, чтобы запустить команду, и Вы увидите хэш SHA-256 для файла. В зависимости от размера файла и скорости памяти Вашего компьютера процесс может занять несколько секунд.
Если Вам нужен другой тип контрольной суммы, добавьте соответствующую опцию -Algorithm в конец команды, например:
Сравните рассчитанную контрольную сумму с исходной. Не нужно смотреть слишком внимательно, так как будет большая разница в контрольной сумме, даже если в базовом файле будет только крошечная разница.
Если контрольная сумма совпадает, файлы идентичны. Если нет, значит проблема — возможно, файл поврежден или Вы просто сравниваете два разных файла. Если Вы скачали копию файла и ее контрольная сумма не соответствует ожидаемой, попробуйте загрузить файл еще раз.
Хэширование (хэш-функция) MD5 и SHA256: что это и для чего нужно?
Хеширование — это метод шифрования данных, преобразующим данные в 16-ричной системе счислений. Полученная в ходе преобразование значение называется хешем, хеш-суммой или хеш-кодом.
Как работает хеширование
Хеширование по модели преобразует все значения в файле в 32 битные комбинации в шестнадцатеричной системе счисления.
Важно! Изменение любого символа в шифрованном файле ведёт к бесповоротному изменению всех оставшихся значений.
Хеширование MD5
Преобразование по MD5 представляет собой превращение стандартных значений в 32 числа в 16-ричной системе.
Примеры преобразования
Пример #1
Примеры полученных данных: a648226f6272d009ee0afbc8255720a1
Пример #2
Конвертируем значение «info@seopulses.ru» в: c3591513ae27d3b8cf7883fda7dbcab7
Пример #3
Конвертируем «Сео пульс» в: 6bf889f4e3c6e8bd3ee6498c25750da3
Хеширование SHA256
Создаёт цифровые отпечатки фиксированной длины 256 бит, 32 байта.
Примеры преобразования
Пример #1
Примеры полученных данных: 0909553331f77d9a9c0c4ded9b4d7badfa7458b23daea311a68362a1524c6ffe
Пример #2
Случайное значение «info@seopulses.ru» в:
Пример #3
Преобразуем строку «SeoPulses» в:
Где применяется хеширование
Данный метод преобразования и шифрования используется рекламными системами для сбора и передачи аудитории и данных CRM систем без передачи в открытом виде контактов клиентов. Соответственно, файл преобразуется в нужный формат и уже после загружается в рекламную систему. Данный формат можно использовать в:
Немного о хэшах и безопасном хранении паролей
Upd. Если вы знаете, что такое BCrypt, можете дальше не читать. Если вы используете PHP 5.5+ то можете прочитать эту статью. Ниже же я изобрел свой велосипед, рабочий, но с двумя рулями, задний запасной. Молод был, горяч.
Привет, хабр! Сегодня, в процессе разработки системы аутентификации для своего проекта передо мной встал выбор — в каком виде хранить пароли пользователей в базе данных? В голову приходит множество вариантов. Самые очевидные:
Коллизия хеш-функций
Коллизия хеш-функции возникает, когда она выдает одинаковый результат на разные входные данные. Конечно же, вероятность этого достаточно мала, и зависит от длины хэша. Однако устаревшая (но до сих пор иногда используемая) функция crc32() возвращает в качестве хэша 32-битное целое число. Т.е., чтобы подобрать пароль к такому хэшу, по теории вероятности нужно получить 2^32 = 4 294 967 296 различных хэшей. Даже на моем бесплатном хостинге crc32 работает со скоростью порядка 350 000 раз в секунду — посчитайте сами сколько нужно секунд, чтобы взломать такой хэш 😉
Конечно же это не относится к md5() (128-битный хеш) и тем более sha1() (160-битный хеш). Использовать их коллизию практически невозможно, хотя есть одна статейка.
Радужные таблицы
Радужные таблицы состоят из хэшей наиболее часто употребляемых паролей — имен, дат рождения, названий животных и т.п. Эти таблицы могут включать миллионы, миллиарды значений, но работа с ними относительно быстра, и проверить хэш на соответствие одному из значений не составляет никакого труда. Частично, от них можно защититься с помощью «соли» или конструкций типа md5(sha1(md5($pass))).
Радужные таблицы. Часть 2
Статическая соль и тому подобные конструкции могут служить достаточно хорошо… пока структура этих конструкций и соль хранятся в тайне. Если же злоумышленник вызнает секрет хэширования — он с легкостью сможет модифицировать под него свою «радужную таблицу». А т.к. мы не можем абсолютно полагаться на систему защиты своего сервера, нужно искать другой вариант. Одним из решений может быть генерация уникальной соли для каждого юзера, что-то вроде:
Еще лучше генерировать совсем случайную соль, например так:
Конечно, уникальную соль придется вносить в базу данных, но даже получив доступ к ней, злоумышленник вряд ли сможет сгенерировать несколько миллионов радужных таблиц.
Скорость хэширования
Казалось бы — чем быстрее, тем лучше. Чем быстрее сгенерируется хэш, тем быстрее наш юзер сможет зарегистрироваться и начать уже приносить профит. Однако чем больше скорость хэширования, тем быстрее его сможет подобрать и хакер.
Современные ПК с мощными GPU, могут рассчитывать миллионы хэшей в секунду и больше. А это позволяет ломать пароли простым подбором, с помощью брутфорса-атак. Считаете что пароль в 8 символов достаточно безопасен? Если в пароле используются символы в нижнем и верхнем регистрах и цифры, то общее количество возможных символов составит 62 (26+26+10). Для пароля длиной в 8 символов, существует 62^8 различных комбинаций (порядка 218 триллионов). Со скоростью в 1 миллиард хэшей в секунду (достаточно маленькая для брутфорс-атаки), пароль будет сломан примерно за 60 часов. А для наиболее распространенной длины пароля в 6 символов, длительность расшифровки составит меньше двух минут.
Можно конечно пренебречь пользователями, использующими короткие и простые пароли, или заставить всех в добровольно-принудительном порядке использовать 10-символьные пароли, со знаками препинания и символами шумерской клинописи. Но лучше использовать более медленные функции хэширования. Например можно замедлить функцию хэша вручную в 1000 раз с помощью следующего кода:
Используя ее, вместо 60 часов, хакер будет ломать 8-символьный пароль около 7 лет. Более удобным вариантом замедления, является использование алгоритма Blowfish, реализованного в PHP через crypt(). Проверить доступность этого алгоритма можно с помощью if (CRYPT_BLOWFISH == 1) echo ‘it works!’; В PHP 5.3 Blowfish уже включен.
$2a — это указание на то, что будет использоваться алгоритм Blowfish
$10 — это сила замедления функции. В данном случае равна 2^10. Может принимать значения от 04 до 31
Используем ее на конкретном примере:
Такой код должен обеспечить максимальную безопасность — подобрать пароль нормальной сложности и длины (программными методами, конечно) практически невозможно.
SHA1 vs md5 vs SHA256: что использовать для входа в PHP?
Я делаю логин php, и я пытаюсь решить, использовать ли SHA1 или Md5 или SHA256, о которых я читал в другой статье stackoverflow. Являются ли они более безопасными, чем другие? Для SHA1/256 я все еще использую соль?
Кроме того, это безопасный способ хранения пароля как хэш в mysql?
ОТВЕТЫ
Ответ 1
Использование bcrypt в PHP 5.5 +
PHP 5.5 предлагает новые функции для хэширования паролей. Это рекомендуемый подход для хранения паролей в современных веб-приложениях.
Если вы используете более старую версию PHP вам действительно нужно обновить, но пока вы не сможете использовать password_compat, чтобы открыть этот API.
Кроме того, пожалуйста, password_hash() создайте соль для вас. Он использует [CSPRNG] (http://
Два оговорки bcrypt
У вас может возникнуть соблазн разрешить первое предостережение предварительное хеширование ваших паролей перед запуском их через bcrypt, но это может привести к вашему приложению для запуска вперёд во второй.
Вместо того, чтобы писать свою собственную схему, используйте существующую библиотеку, написанную и/или оцененную экспертами по безопасности.
Ответ 2
Я думаю, что использование md5 или sha256 или любой хеш, оптимизированный для скорости, отлично подходит, и мне очень любопытно слышать любые опровержения, которые могут иметь другие пользователи. Вот мои причины.
Если вы разрешаете пользователям использовать слабые пароли, такие как Бог, любовь, война, мир, то независимо от того, какое шифрование вы по-прежнему позволяете пользователю вводить пароль, а не хэш, и эти пароли часто используются сначала, таким образом, это НЕ будет иметь какое-либо отношение к шифрованию.
Если вы не используете SSL или не имеете сертификата, тогда злоумышленники, прослушивающие трафик, смогут вытащить пароль, а любые попытки шифрования с помощью javascript или тому подобного будут на стороне клиента и легко взломать и преодолеть. Опять же, это НЕ будет иметь какое-либо отношение к шифрованию данных на стороне сервера.
Атаки грубой силы будут использовать слабые пароли и снова, потому что вы разрешаете пользователю вводить данные, если у вас нет ограничения на вход 3 или даже немного больше, чем проблема снова будет НЕ имеют какое-либо отношение к шифрованию данных.
Если ваша база данных становится скомпрометированной, то, скорее всего, все было скомпрометировано, включая ваши методы хеширования, независимо от того, насколько вы загадочны. Опять же, это может быть недовольная атака сотрудника XSS или SQL-инъекция или другая атака, которая не имеет никакого отношения к вашему шифрованию паролей.
Я действительно считаю, что вы все еще шифруете, но единственное, что я вижу, это шифрование, это предотвращение того, что люди уже имеют или каким-то образом получили доступ к базе данных, просто прочитав вслух пароль. Если в базе данных кто-то несанкционирован, у вас есть больше проблем, чтобы беспокоиться о том, почему Sony взяла их, потому что они считали, что зашифрованный пароль защищает все, включая номера кредитных карт, все, что он делает, защищает это одно поле.
Причина, по которой я хотел попытаться понять это, заключается в том, что слишком часто люди считают, что зашифрованный пароль означает, что им не нужно беспокоиться о том, что он скомпрометирован, и они перестают беспокоиться о безопасности веб-сайта.
Ответ 3
Как отметил Йоханнес Горсет, сообщение Томаса Птачека из Matasano Security объясняет, почему простые универсальные функции хеширования, такие как MD5, SHA1, SHA256 и SHA512, не подходят для хеширования паролей.
Соление без растягивания ключа означает, что вы не можете предварительно вычислить радужный стол, вам нужно создать его специально для этой конкретной соли. Но это не сильно усложнит жизнь.
Пользователь @Will говорит:
Все говорят об этом, как будто их можно взломать интернет. Как уже говорилось, ограничение попыток делает невозможным взломать пароль через Интернет и не имеет ничего общего с хэш.
Им не нужно. По-видимому, в случае LinkedIn они использовали общую уязвимость SQL-инъекций для получения таблицы БД входа в систему и взломали миллионы паролей в автономном режиме.
Затем он возвращается к сценарию автономной атаки:
Безопасность действительно вступает в игру, когда вся база данных скомпрометирован и хакер может затем выполнить 100 миллионов паролей попыток в секунду против хеша md5. SHA512 составляет около 10000 раз медленнее.
Ответ 4
Как добавленное примечание, FRKT, пожалуйста, покажите мне, где кто-то может легко взломать хвойный SHA256? Мне действительно очень интересно это видеть.
Важное редактирование:
Двигаясь вперед, используйте bcrypt как затвердевший хеш. Более подробную информацию можно найти здесь.
Используйте случайное число или случайный поток байтов и т.д. Вы можете использовать уникальное поле записи в своей базе данных как соль тоже, таким образом, соль различна для каждого пользователя.
Ответ 5
Кажется, что люди не видят, что, если у хакера есть доступ к базе данных, он, вероятно, также имеет доступ к файлу php, который хэширует пароль и, скорее всего, просто изменит это, чтобы отправить ему все успешные пароли паролей имени пользователя. Если у него нет доступа к веб-каталогу, он всегда может просто выбрать хэш пароля и записать его в базу данных. Другими словами, алгоритм хеширования не имеет особого значения, как системная безопасность, и ограничение попыток входа в систему также, если вы не используете SSL, тогда злоумышленник может просто прослушать соединение, чтобы получить информацию. Если вам не нужен алгоритм для вычисления времени (для ваших собственных целей), то SHA-256 или SHA-512 с определенной пользователем солью должно быть достаточно.
В качестве дополнительной меры безопасности настройте script (bash, batch, python и т.д.) или программу и дайте ему неясное имя и попросите его проверить и посмотреть, изменился ли login.php(проверьте дату/время печать) и отправьте вам электронное письмо, если оно есть. Также, вероятно, следует регистрировать все попытки входа в систему с правами администратора и регистрировать все неудавшиеся попытки входа в базу данных и отправки журналов по электронной почте.
Ответ 6
Все говорят об этом, так как их можно взломать через Интернет. Как уже говорилось, ограничение попыток делает невозможным взломать пароль через Интернет и не имеет ничего общего с хешем.
Соль является обязательной, но сложность или несколько солей даже не имеет значения. Любая соль сама по себе останавливает злоумышленника от использования готового радужного стола. Уникальная соль для каждого пользователя останавливает злоумышленника от создания новой таблицы радуги для использования против всей вашей базы пользователей.
Безопасность действительно вступает в игру, когда вся база данных скомпрометирована, и хакер может выполнить 100 миллионов попыток пароля в секунду против хеша md5. SHA512 примерно в 10 000 раз медленнее. Сложный пароль с сегодняшней властью может по-прежнему занять 100 лет, чтобы выполнить брутфорс с помощью md5 и потребовал бы в 10 000 раз больше с SHA512. Соли не останавливают грубую силу вообще, поскольку они всегда должны быть известны, что, если злоумышленник загрузил вашу базу данных, он, вероятно, был в вашей системе.
Ответ 7
Sha-1 будет достаточно безопасным для этого. Причина, по которой вы храните засоленную версию пароля sha-1, заключается в том, что вы не храните пользовательский apassword в файле, который они могут использовать с серверами других пользователей. В противном случае, какая разница?
И даже если бы хакер с будущими технологиями мог генерировать миллион ша-1 ключей в секунду для атаки грубой силы, мог бы ваш сервер обрабатывать миллион логинов в секунду, чтобы хакер мог проверить свои ключи? Это, если вы позволяете хакеру пытаться подключиться к соленой sha-1 вместо пароля, как обычный вход в систему.
Ответ 8
Используйте argon2i. Функция хэширования паролей argon2 выиграла конкурс хэширования паролей.
Другие разумные варианты, если использование argon2 недоступно, это scrypt, bcrypt и PBKDF2. В Википедии есть страницы для этих функций:
Переключение с MD5 на SHA1 или SHA512 не сильно улучшит безопасность конструкции. Вычисление хэша SHA256 или SHA512 выполняется очень быстро. Злоумышленник с обычным оборудованием может попробовать десятки миллионов (с одним процессором) или даже миллиарды (с одним графическим процессором) хэшей в секунду. Хорошие функции хеширования паролей включают рабочий фактор, замедляющий атаки по словарю.
Вот предложение для программистов PHP: прочитайте FAQ по PHP, затем используйте password_hash().
Ответ 9
Вот сравнение между MD5 и SHA1. Вы можете получить четкое представление о том, какой из них лучше.
Ответ 10
Предположим следующее: хакеры украдут нашу базу данных, включая пользователей и пароль (зашифрованные). И хакеры создали фальшивую учетную запись с паролем, который они знают.
MD5 слаб, потому что его короткое и популярное и практически каждое хеш-генерация без пароля слаба в словарной атаке. Но..
Однако, если мы использовали MD5 + SALT, и мы применили MD5, тогда нет способа восстановить информацию. Однако, повторяю, MD5 по-прежнему короток.
md5 с хешем: 56adb0f19ac0fb50194c312d49b15378
mD5 с хешем по md5: 28a03c0bc950decdd9ee362907d1798a Я попытался использовать эти онлайн-службы, и я не нашел ни одного, кто мог бы взломать его. И его единственный MD5! (может быть, так как сегодня это будет треск, потому что я создал md5 в Интернете)
Если вы хотите переполнить, тогда SHA256 более чем достаточно, если его применить с солью и дважды.
TL;DR MD5 (HASH + MD5 (пароль)) = ok, но короткий, SHA256 более чем достаточно.
Ответ 11
Шифрование md5 является одним из худших, потому что вы должны повернуть код, и он уже расшифрован. Я бы порекомендовал вам SHA256. Я программирую немного дольше и имею хороший опыт. Ниже также будет шифрование.
Риски и проблемы хеширования паролей
Безопасность всегда была неоднозначной темой, провоцирующей многочисленные горячие споры. И всё благодаря обилию самых разных точек зрения и «идеальных решений», которые устраивают одних и совершенно не подходят другим. Я считаю, что взлом системы безопасности приложения всего лишь вопрос времени. Из-за быстрого роста вычислительных мощностей и увеличения сложности безопасные сегодня приложения перестанут завтра быть таковыми.
Недостатки простого хэширования
Тот факт, что с помощью эффективного алгоритма невозможно провести операцию, обратную хэшированию, и восстановить исходные данные, не означает, что вас не могут взломать. Если хорошо поискать, то можно найти базы данных с хэшами распространённых слов и коротких фраз. Кроме того, простые пароли можно быстро и легко брутфорсить или взламывать перебором по словарю.
Вот небольшая демонстрация, как инструмент sqlmap через внедрение SQL-кода взламывает пароли с помощью брутфорса хэшей, сгенерированных алгоритмом MD5.
Почему небезопасны хэши с применением соли
Чтобы затруднить атаки описанного вида, применяется так называемая соль. Это стандартное средство, но в условиях современных вычислительных мощностей его уже недостаточно, особенно если длина соли невелика.
В общем виде функцию с использованием соли можно представить так:
f(password, salt) = hash(password + salt)
Для затруднения брутфорс-атаки соль должна быть длиной не менее 64 символов. Но проблема в том, что для дальнейшей аутентификации пользователей соль должна храниться в БД в виде простого текста.
if (hash([введённый пароль] + [соль]) == [хэш]) тогда пользователь аутентифицирован
Благодаря уникальности соли для каждого пользователя мы можем решить проблему коллизий простых хэшей. Теперь все хэши будут разными. Также уже не сработают подходы с гугленьем хэшей и брутфорсом. Но если злоумышленник через внедрение SQL-кода получит доступ к соли или БД, то сможет успешно атаковать брутфорсом или перебором по словарю, особенно если пользователи выбирают распространённые пароли (а-ля 123456).
Тем не менее взлом любого из паролей уже не позволит автоматически вычислить пользователей, у которых тот же пароль, — ведь у нас ВСЕ хэши разные.
Момент случайности
Для генерирования подходящей соли нам нужен хороший генератор случайных чисел. Сразу забудьте о функции rand().
Есть замечательная статья, посвящённая этому вопросу. Вкратце: компьютер сам по себе не генерирует случайные данные, это детерминированная машина. То есть каждый выполняемый алгоритм, получив несколько раз на входе одни и те же данные, на выходе представит один и тот же результат.
Когда от компьютера хотят случайное число, то обычно он берёт данные из нескольких источников (например, переменные среды: дату, время, количество записанных/считанных байтов и т. д.), а затем производит над ними вычисления для получения «случайных» данных. Поэтому такие данные называют псевдослучайными. А значит, если каким-то образом воссоздать набор исходных состояний на момент исполнения псевдослучайной функции, то мы сможем сгенерировать то же самое число.
Если псевдослучайный генератор ещё и реализован неправильно, то в генерируемых им данных можно обнаружить паттерны, а с их помощью предсказать результат генерирования. Взгляните на эту картинку, представляющую собой результат работы PHP-функции rand():
А теперь сравните с данными, сгенерированными полноценным генератором случайных чисел:
К сожалению, ни rand(), ни mt_rand() нельзя считать подходящими инструментами для обеспечения высокого уровня безопасности.
Если вам нужно получить случайные данные, воспользуйтесь функцией openssl_random_pseudo_bytes(), которая доступна начиная с версии 5.3.0. У неё даже есть флаг crypto_strong, который сообщит о достаточном уровне безопасности.
Растяжение пароля
Можно внедрить растяжение пароля, это позволяет ещё больше затруднить брутфорс-атаки. Растяжение представляет собой итеративный, или рекурсивный, алгоритм, который раз за разом вычисляет хэш самого себя, десятки тысяч раз (а то и более).
Количество итераций должно быть таково, чтобы общее время вычислений заняло как минимум одну секунду. Чем более длительное получается хэширование, тем больше времени атакующему приходится тратить на взлом.
Для растяжения пароля можно использовать стандартные алгоритмы, например PBDKDF2, представляющий собой функцию формирования ключа:
Есть и более затратные по времени и памяти алгоритмы, например bcrypt (о нём мы поговорим ниже) или scrypt:
На данный момент в PHP не реализована поддержка алгоритма scrypt, но можно воспользоваться реализацией от Domblack.
Применение технологий шифрования
Многие путаются в терминах «хэширование» и «шифрование». Как было упомянуто выше, хэш — результат работы псевдослучайной функции, в то время как шифрование — осуществление псевдослучайного преобразования: входные данные делятся на части и обрабатываются таким образом, что результат становится неотличим от результата работы полноценного генератора случайных чисел. Однако в этом случае можно провести обратное преобразование и восстановить исходные данные. Преобразование осуществляется с помощью криптоключа, без которого невозможно провести обратное преобразование.
Есть и ещё одно важное отличие шифрования от хэширования: размер пространства выходного сообщения не ограничен и зависит от размера входных данных в соотношении 1:1. Поэтому нет риска возникновения коллизий.
Необходимо уделять большое внимание правильности использования шифрования. Не думайте, что для защиты важных данных достаточно просто зашифровать по какому-нибудь алгоритму. Есть немало способов украсть данные. Главное правило — никогда не занимайтесь самодеятельностью и пользуйтесь уже готовыми, отработанными реализациями.
Некоторое время назад у Adobe была мощная утечка пользовательской БД из-за неправильно реализованного шифрования. Давайте разберём, что у них произошло.
Предположим, что в таблице хранятся следующие данные в виде обычного текста:
Мы не знаем, какой применялся криптоключ. Но если проанализировать данные, то можно заметить, что в строках 2 и 7 используется один и тот же пароль, так же как и в строках 3 и 6.
Пришло время обратиться к подсказке пароля. В строке 6 это «I’m one!», что совершенно неинформативно. Зато благодаря строке 3 мы можем предположить, что пароль — queen. Строки 2 и 7 по отдельности не позволяют вычислить пароль, но если проанализировать их вместе, то можно предположить, что это halloween.
Ради снижения риска утечки данных лучше использовать разные способы хэширования. А если вам нужно шифровать пароли, то обратите внимание на настраиваемое шифрование:
Пусть у нас есть тысячи пользователей и мы хотим зашифровать все пароли. Как было показано выше, лучше избегать использования единого криптоключа. Но и сделать для каждого пользователя уникальный ключ мы тоже не можем, поскольку хранение ключей само по себе превратится в проблему. В этом случае достаточно применять общий для всех криптоключ, но при этом делать «настройку», уникальную для каждого пользователя. Комбинация ключа и «настройки» и будет являться уникальным ключом для каждого пользователя.
Простейший вариант «настройки» — так называемый первичный ключ, уникальный для каждой записи в таблице. Не рекомендуется пользоваться им в жизни, здесь он показан лишь для примера:
f(key, primaryKey) = key + primaryKey
Здесь ключ и первичный ключ просто сцепляются вместе. Но для обеспечения безопасности следует применить к ним алгоритм хэширования или функцию формирования ключа (key derivation function). Также вместо первичного ключа можно для каждой записи использовать одноразовый ключ (аналог соли).
Если мы применим к нашей таблице настраиваемое шифрование, то она будет выглядеть так:
Конечно, нужно будет ещё что-то сделать с подсказками паролей, но всё-таки уже получилось хоть что-то адекватное.
Обратите внимание, что шифрование — не идеальное решение для хранения паролей. В связи с угрозами внедрения кода лучше избегать этого метода защиты. Для хранения паролей надежнее всего использовать алгоритм bcrypt. Но нельзя забывать и о том, что даже самые лучшие и проверенные решения обладают уязвимостями.
PHP 5.5
Сегодня оптимальным способом хэширования паролей считается использование bcrypt. Но многие разработчики всё ещё предпочитают старые и более слабые алгоритмы вроде MD5 и SHA-1. А некоторые при хэшировании даже не пользуются солью. В PHP 5.5 был представлен новый API для хэширования, который не только поощряет применение bcrypt, но и существенно облегчает работу с ним. Давайте разберём основы использования этого нового API.
password_hash()
Несмотря на высокий уровень безопасности, обеспечиваемый функцией crypt(), многие считают её слишком сложной, из-за чего программисты часто допускают ошибки. Вместо неё некоторые разработчики используют для генерирования хэшей комбинации слабых алгоритмов и слабых солей:
Функция password_hash() существенно облегчает разработчику жизнь и повышает безопасность кода. Для хэширования пароля достаточно скормить его функции, и она вернёт хэш, который можно поместить в БД:
И всё! Первый аргумент — пароль в виде строки, второй аргумент задаёт алгоритм генерирования хэша. По умолчанию используется bcrypt, но при необходимости можно добавить и более сильный алгоритм, который позволит генерировать строки большей длины. Если в своём проекте вы используете PASSWORD_DEFAULT, то удостоверьтесь, что ширина колонки для хранения хэшей не менее 60 символов. Лучше сразу задать 255 знаков. В качестве второго аргумента можно использовать PASSWORD_BCRYPT. В этом случае хэш всегда будет длиной в 60 символов.
Обратите внимание, что вам не нужно задавать значение соли или стоимостного параметра. Новый API всё сделает за вас. Поскольку соль является частью хэша, то вам не придётся хранить её отдельно. Если вам всё-таки нужно задать своё значение соли (или стоимости), то это можно сделать с помощью третьего аргумента:
Всё это позволит вам использовать самые свежие средства обеспечения безопасности. Если в дальнейшем в PHP появится более сильный алгоритм хэширования, то ваш код станет использовать его автоматически.
password_verify()
Теперь рассмотрим функцию сравнения пароля с хэшем. Первый вводится пользователем, а второй мы берём из БД. Пароль и хэш используются в качестве двух аргументов функции password_verify(). Если хэш соответствует паролю, то функция возвращает true.
Помните, что соль является частью хэша, поэтому она не задаётся здесь отдельно.
password_needs_rehash()
Если вы захотите повысить уровень безопасности, добавив более сильную соль или увеличив стоимостный параметр, или изменится алгоритм хэширования по умолчанию, то вы, вероятно, захотите перехэшировать все имеющиеся пароли. Данная функция поможет проверить каждый хэш на предмет того, какой алгоритм и параметры использовались при его создании:
Не забывайте, что вам нужно будет это делать в тот момент, когда пользователь пытается залогиниться, поскольку это единственный раз, когда у вас будет доступ к паролю в виде простого текста.
password_get_info()
Более ранние версии PHP
Как видите, работать с новым API не в пример легче, чем с неуклюжей функцией crypt(). Если же вы используете более ранние версии PHP, то рекомендую обратить внимание на библиотеку password_compact. Она эмулирует данный API и автоматически отключается, когда вы обновляетесь до версии 5.5.