Я создаю приложение, которое будет хранить пароли, которые пользователь может получить и увидеть. Пароли предназначены для аппаратного устройства, поэтому о проверке хэшей не может быть и речи.
Что мне нужно знать, это:
Как зашифровать и расшифровать пароль в PHP?
Какой алгоритм шифрования паролей является самым безопасным?
Где я могу хранить закрытый ключ?
Вместо того, чтобы хранить закрытый ключ, стоит ли требовать, чтобы пользователи вводили закрытый ключ каждый раз, когда им нужен расшифрованный пароль? (Пользователям этого приложения можно доверять)
Каким образом пароль может быть украден и расшифрован? Что мне нужно знать?
php
security
encryption
passwords
HyderA
источник
источник
Ответы:
Лично я бы использовал
mcrypt
как другие опубликованные. Но есть еще много чего отметить ...Как зашифровать и расшифровать пароль в PHP?
Смотрите ниже сильный класс, который позаботится обо всем для вас:
Какой алгоритм шифрования паролей является самым безопасным?
самый безопасный ? любой из них. Самый безопасный способ шифрования - это защита от уязвимостей раскрытия информации (XSS, удаленное включение и т. Д.). Если он выходит, злоумышленник может в конечном итоге взломать шифрование (никакое шифрование не является на 100% необратимым без ключа - как указывает @NullUserException, это не совсем верно. Существуют некоторые схемы шифрования, которые невозможно взломать, например OneTimePad ) ,
Где я могу хранить закрытый ключ?
То, что я хотел бы сделать, это использовать 3 ключа. Один из них предоставляется пользователем, один - для конкретного приложения, а другой - для конкретного пользователя (например, соль). Специфический ключ приложения может храниться где угодно (в файле конфигурации вне корневого веб-узла, в переменной среды и т. Д.). Конкретный пользователь будет храниться в столбце в БД рядом с зашифрованным паролем. Предоставленный пользователем один не будет сохранен. Затем вы бы сделали что-то вроде этого:
Преимущество заключается в том, что любые 2 ключа могут быть скомпрометированы без компрометации данных. Если есть атака SQL Injection, они могут получить
$userKey
, но не другой 2. Если есть эксплойт локального сервера, они могут получить$userKey
и$serverKey
, но не третий$userSuppliedKey
. Если они избивают пользователя гаечным ключом, они могут получить$userSuppliedKey
, но не два других (но, опять же, если пользователя избивают гаечным ключом, вы все равно опоздаете).Вместо того, чтобы хранить закрытый ключ, стоит ли требовать, чтобы пользователи вводили закрытый ключ каждый раз, когда им нужен расшифрованный пароль? (Пользователям этого приложения можно доверять)
Абсолютно. На самом деле, это единственный способ, которым я бы это сделал. В противном случае вам потребуется хранить незашифрованную версию в формате длительного хранения (совместно используемая память, такая как APC или memcached, или в файле сеанса). Это подвергает себя дополнительным компромиссам. Никогда не храните незашифрованную версию пароля ни в чем, кроме локальной переменной.
Каким образом пароль может быть украден и расшифрован? Что мне нужно знать?
Любая форма компрометации ваших систем позволит им просматривать зашифрованные данные. Если они могут внедрить код или получить доступ к вашей файловой системе, они могут просматривать расшифрованные данные (поскольку они могут редактировать файлы, которые расшифровывают данные). Любая форма Replay или MITM-атаки также даст им полный доступ к задействованным ключам. Обнюхивание необработанного HTTP-трафика также даст им ключи.
Используйте SSL для всего трафика. И убедитесь, что на сервере нет никаких уязвимостей (CSRF, XSS, SQL-инъекция, повышение привилегий, удаленное выполнение кода и т. Д.).
Изменить: Вот реализация класса PHP метода сильного шифрования класса:
Обратите внимание , что я использую функцию добавлена в PHP 5.6:
hash_equals
. Если у вас уровень ниже 5.6, вы можете использовать эту функцию замещения, которая реализует функцию сравнения, безопасную по времени, с использованием двойной проверки HMAC :Использование:
Затем расшифровать:
Обратите внимание, что я использовал
$e2
второй раз, чтобы показать вам, что разные экземпляры все равно будут правильно расшифровывать данные.Теперь, как это работает / почему использовать его поверх другого решения:
Ключи
Ключи не используются напрямую. Вместо этого ключ растягивается стандартным деривацией PBKDF2.
Ключ, используемый для шифрования, уникален для каждого зашифрованного блока текста. Таким образом, предоставленный ключ становится «главным ключом». Поэтому этот класс обеспечивает поворот ключей для ключей шифрования и аутентификации.
ВАЖНОЕ ПРИМЕЧАНИЕ :
$rounds
параметр настроен для истинных случайных ключей достаточной силы (как минимум 128 битов криптографически защищенных случайных ключей). Если вы собираетесь использовать пароль или неслучайный ключ (или менее случайный, чем 128 бит случайного CS), вы должны увеличить этот параметр. Я бы предложил минимум 10000 для паролей (чем больше вы можете себе позволить, тем лучше, но это увеличит время выполнения) ...Целостность данных
Шифрование:
MCRYPT_BLOWFISH
илиMCRYPT_RIJNDAEL_128
шифры иMCRYPT_MODE_CBC
для режима. Он достаточно сильный и достаточно быстрый (на моем компьютере цикл шифрования и дешифрования занимает около 1/2 секунды).Теперь, что касается пункта 3 из первого списка, это даст вам такую функцию:
Вы можете растянуть его в
makeKey()
функции, но так как он будет растянут позже, в этом нет особой необходимости.Что касается размера хранилища, это зависит от простого текста. Blowfish использует 8-байтовый размер блока, поэтому у вас будет:
Таким образом, для 16-символьного источника данных будет зашифровано 16 символов данных. Это означает, что фактический размер зашифрованных данных составляет 16 байтов из-за заполнения. Затем добавьте 16 байтов для соли и 64 байта для hmac, и общий сохраненный размер составит 96 байтов. Так что, в лучшем случае, накладные расходы в 80 символов, а в худшем - на 87 символов ...
Надеюсь, это поможет...
Примечание: 12/11/12: я только что обновил этот класс с НАМНОГО лучшим методом шифрования, используя лучшие производные ключи и исправив генерацию MAC ...
источник
-64
с, чтобы-128
помочь (так вы получаете$enc = substr($data, 128, -128)
и$mac = substr($data, -128);
Как зашифровать и расшифровать пароль в PHP? Благодаря реализации одного из многих алгоритмов шифрования. (или используя одну из множества библиотек)
Какой алгоритм шифрования паролей является самым безопасным? Существует множество различных алгоритмов, ни один из которых не является на 100% безопасным. Но многие из них достаточно безопасны для коммерческих и даже военных целей
Где я могу хранить закрытый ключ? Если вы решили реализовать алгоритм криптографии с открытым ключом (например, RSA), вы не храните закрытый ключ. У пользователя есть закрытый ключ. ваша система имеет открытый ключ, который может храниться где угодно.
Вместо того, чтобы хранить закрытый ключ, стоит ли требовать, чтобы пользователи вводили закрытый ключ каждый раз, когда им нужен расшифрованный пароль? (Пользователям этого приложения можно доверять) Хорошо, если ваш пользователь может запоминать смехотворно длинные простые числа, тогда - да, почему бы и нет. Но, как правило, вам нужно создать систему, которая позволит пользователю хранить свой ключ где-нибудь.
Каким образом пароль может быть украден и расшифрован? Что мне нужно знать? Это зависит от используемого алгоритма. Однако всегда следите за тем, чтобы вы не отправляли незашифрованный пароль пользователю или от него. Либо зашифруйте / расшифруйте его на стороне клиента, либо используйте https (или используйте другие криптографические средства для защиты соединения между сервером и клиентом).
Однако, если все, что вам нужно, это хранить пароли в зашифрованном виде, я бы посоветовал вам использовать простой XOR-шифр. Основная проблема этого алгоритма состоит в том, что он может быть легко взломан частотным анализом. Однако, как правило, пароли не состоят из длинных абзацев английского текста, я не думаю, что вам следует беспокоиться об этом. Вторая проблема с XOR Cipher заключается в том, что если у вас есть сообщение в зашифрованном и зашифрованном виде, вы можете легко узнать пароль, с помощью которого оно было зашифровано. Опять же, не большая проблема в вашем случае, поскольку она затрагивает только пользователя, который уже был скомпрометирован другими способами.
источник
Пример из руководства немного отредактирован для этого примера):
Вы бы использовали mcrypt_decrypt для расшифровки вашего пароля.
Лучший алгоритм довольно субъективен - спросите 5 человек, получите 5 ответов. Лично, если значение по умолчанию (Blowfish) не достаточно для вас, у вас, вероятно, есть большие проблемы!
Учитывая, что PHP необходим для шифрования - не уверен, что вы можете спрятать его где-либо - приветствуйте комментарии по этому поводу. Стандартные PHP лучшие практики кодирования применяются конечно!
Учитывая, что ключ шифрования будет в вашем коде в любом случае, не уверен, что вы получите, при условии, что остальная часть вашего приложения в безопасности.
Очевидно, что если зашифрованный пароль и ключ шифрования украдены, то игра окончена.
Я бы поставил на ответ гонщика - я не эксперт по криптографии PHP, но я думаю, что я ответил, что это стандартная практика - я приветствую комментарии, которые могут быть у других.
источник
$pass = $text
, Я думаю, что он изменил это, чтобы удовлетворить вопрос, и не заметил второго случая.MCRYPT_MODE_ECB
не использует IV. Во-вторых, если это произойдет, вам нужно будет сохранить IV, поскольку вы не сможете расшифровать данные без него ...Многие пользователи предлагают использовать mcrypt ... это правильно, но я хотел бы пойти дальше, чтобы его было легко хранить и передавать (поскольку иногда зашифрованные значения могут затруднить их отправку с использованием других технологий, таких как curl или json) ,
После того как вы успешно зашифровали с помощью mcrypt, запустите его через base64_encode и затем преобразуйте его в шестнадцатеричный код. Однажды в шестнадцатеричном коде это легко передать различными способами.
А с другой стороны:
источник
Я бы рекомендовал шифрование с открытым ключом только в том случае, если вы хотите установить пароль пользователя без его взаимодействия (это может быть удобно для сброса и общих паролей).
Открытый ключ
openssl_public_encrypt
иopenssl_private_decrypt
симметричный
Обе
4
, Да - пользователям придется каждый раз вводить пароль своего приложения, но сохранение его в сеансе вызовет другие проблемы5
,источник
openssl_private_decrypt()
.Я пробовал что-то вроде этого, но, пожалуйста, обратите внимание, что я не криптограф и не обладаю глубокими знаниями
php
или каким-либо языком программирования. Это просто идея. Моя идея состоит в том, чтобы сохранитьkey
в каком-либо файле илиdatabase
(или ввести вручную), какое (местоположение) не может быть легко предсказано (и, конечно, когда-нибудь что-нибудь будет расшифровано, концепция состоит в том, чтобы увеличить время дешифрования) и зашифровать конфиденциальную информацию.Обратите внимание, что это просто концепция. Любое улучшение в этом коде было бы весьма заметно.
источник
А? Я не понимаю Вы имеете в виду, что пароль должен быть восстановим?
Как уже говорили другие, расширение mcrypt предоставляет доступ ко многим криптографическим функциям - однако вы предлагаете своим пользователям положить все свои яйца в одну корзину - ту, которая потенциально может стать целью для злоумышленников - и если вы даже не знаете как начать решать проблему, тогда вы оказываете своим пользователям медвежью услугу. Вы не в состоянии понять, как защитить данные.
Большинство уязвимостей безопасности возникают не потому, что лежащий в основе алгоритм ошибочен или небезопасен, а из-за проблем с тем, как алгоритм используется в коде приложения.
Сказав это, можно построить достаточно безопасную систему.
Асимметричное шифрование следует рассматривать только в том случае, если у пользователя есть требование создать защищенное сообщение, которое может прочитать другой (определенный) пользователь. Причина в том, что это вычислительно дорого. Если вы просто хотите предоставить пользователям репозиторий для ввода и извлечения собственных данных, симметричное шифрование является адекватным.
Однако если вы храните ключ для расшифровки сообщения в том же месте, что и зашифрованное сообщение (или там, где хранится зашифрованное сообщение), то система не защищена. Используйте тот же токен для аутентификации пользователя, что и для ключа дешифрования (или в случае асимметричного шифрования используйте токен в качестве секретной фразы секретного ключа). Поскольку вам нужно будет сохранить токен на сервере, где дешифрование происходит, по крайней мере, временно, вы можете рассмотреть возможность использования субстрата хранения сеанса без возможности поиска или передачи токена непосредственно демону, связанному с сеансом, который будет хранить токен в памяти и выполнять расшифровку сообщений по требованию.
источник
Используйте password_hash и password_verify
И расшифровать
источник