Является ли ENCODE () и DECODE () «лучшим» способом обработки поля пароля приложения в MySQL?

Question

Я занимаюсь разработкой стека LAMP (erl) и знаю несколько способов хранения скрытых паролей. Я хотел бы услышать от тех, кто считает, что у них есть лучшая практика, учитывая MySQL 4.1.1 и Perl 5.8, и причины, по которым он лучший.

Один вариант, о котором я читал, с использованием функций MySQL ENCODE () и DECODE (), звучит довольно хорошо для меня ... ваши мысли?

Answer 1

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

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

Мне кажется, что encode () и decode (), вероятно, являются хорошими решениями, когда вы хотите, чтобы данные были восстанавливаемыми, но что невосстановимые хеши (использующие Crypt :: MD5) - лучший подход для сохраненных паролей.

Answer 2

Я думаю, что соленый хеш с правильной хеш-функцией, такой как SHA-256 , является лучшим. Обратимые пароли не так безопасны, как пароли, которые нельзя восстановить. Без внешнего модуля Perl вы можете использовать вместо этого встроенную функцию SHA1 (), не такую ​​хорошую, как SHA256, но лучше, чем ENCODE / DECODE.

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

Answer 3

Если вам нужен только пароль для аутентификации себя / пользователя, лучше использовать одностороннее хранение (например, md5).

Answer 4

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

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

Answer 5

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

Я бы порекомендовал использовать классический метод хэширования с солью.

Answer 6

Я не уверен, что эти функции делают, но для паролей на веб-сайте стека LAMP, я бы определенно использовал поле соли.

Ваша таблица будет иметь:

• имя
• передача
• соль

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

Это значительно повышает безопасность, потому что теперь ваши пользователи больше не используют 5-буквенные пароли, они используют пароли размером 5 + len (соль), и если соль достаточно велика, никакая радужная база данных не будет содержать ваши хэши. 1015 *

Answer 7

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