Безопасность PHP и MySQL: одностороннее шифрование и двустороннее шифрование - PullRequest
4 голосов
/ 09 октября 2010

Я читал об использовании MySQL. AES_ENCRYPT / AES_DECRYPT (двустороннее шифрование) менее безопасен, чем использование PHP - hash () (одностороннее шифрование).

http://bytes.com/topic/php/answers/831748-how-use-aes_encrypt-aes_decrypt

Правда ли, что более безопасно, что «Вместо того, чтобы отправлять Пользователю его пароль, просто отправьте ему ссылку, по которой он может щелкнуть, чтобы восстановить свой пароль».?

И вдобавок, еслиЯ использую MySQL AES_ENCRYPT / AES_DECRYPT (что мне очень нравится ...), как определить ключ, который может быть принят MySQL?Например, важна ли длина ключа?или я могу просто использовать «123123 @ 123123» в качестве моего ключа?

спасибо!

Ответы [ 5 ]

7 голосов
/ 09 октября 2010

Существует принципиальная разница между двумя понятиями, хешированием и шифрованием:
Шифрование может быть обращено , хеширование не может (по крайней мере, это идея).

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

Именно поэтому пароли всегда должны быть хешированы (и засолены), никогда зашифрованы.

Например, важна ли длина ключа? или я могу просто использовать «123123 @ 123123» в качестве моего ключа?

AFAIK MySQL AES_ENCRYPT может принимать ключи произвольной длины; но очевидно, что более короткие ключи облегчат злоумышленнику грубую игру (то есть: попробуйте все возможные комбинации)

2 голосов
/ 09 октября 2010

Двустороннее шифрование по своей природе менее безопасно, потому что где-то хранятся реальные данные. То есть у вас есть пароль «привет». Затем вы хэшируете, вы получаете 5d41402abc4b2a76b9719d911017c592. Это бессмысленно для нормального человека, и они не будут знать, как его расшифровать, не зная правильного алгоритма шифрования. Они также не могут использовать это, потому что используется только оригинальный пароль. Вы проверяете пароль, хешируя его и сравнивая с хешем (также сохраненным). 5d41402abc4b2a76b9719d911017c592 hashed is 69a329523ce1ec88bf63061863d9cb14, поэтому они не совпадают. Даже если пользователь знает хешированный пароль, он ничего не может извлечь из него.

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

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

Что касается AES, я не могу сразу узнать об этом слишком много, но похоже, что не имеет значения, что вы шифруете. Поэтому, если вы используете AES_DECRYPT (AES_ENCRYPT ('x', 'b'), 'b'); он вернет «х». Вы должны следить за ключом.

1 голос
/ 09 октября 2010

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

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

Что касается ключейдля AES_ENCRYPT / DECRYPT-- MySQL будет принимать переменные длины для параметра key для функций, но независимо от этого он будет использовать 128-битный ключ, поэтому в ваших интересах передавать значение как минимум 128 бит.

1 голос
/ 09 октября 2010

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

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

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

0 голосов
/ 24 марта 2017

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

Двустороннее шифрование означает, что доступны функции шифрования и дешифрования. В PHP это достигается с помощью функций mcrypt_encrypt() и mcrypt_decrypt().

...