Эффективно ли хранит мой алгоритм безопасности PHP учетные данные пользователя?

Question

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

// Get a 32 character salt like '69Mt6nexL1rsjWnu011S53MpB/WmT4Vl'
$passwordSalt = Security::generateBase64Salt();

$user = new User();
$user->setUsername($_POST['username']);

// $_POST['password'] comes in as a 128 character string
// Client side javascript is used to sha512 the string before sending it over POST
// see http://pajhome.org.uk/crypt/md5/
// This prevents novice eavesdroppers from capturing the raw password in plaintext
$user->setPassword(
    hash('sha512', $passwordSalt.$_POST['password'])
);
$user->setPasswordSalt($passwordSalt);
$user->save();

Вот запись в базе данных для определенного пароля:

Пароль:

69a78a7586a111b8a567b2d4f42f93f01fb59d337f7fa3c35949a66b246095778c1fa01ff4026abace476091e1e9a183bbdec1c31b12ce3f786921895c98cf6f

Соль:

69Mt6nexL1rsjWnu011S53MpB / WmT4Vl

Вопросы:

• Есть ли в этом алгоритме недостатки наследования?
• Можно ли хранить соль в той же базе данных и таблице, что и хэш соли + пароля?
• Повлияет ли наличие большого пароля длиной 128 символов на производительность при входе в систему (на несколько секунд), если в таблице несколько сотен тысяч пользователей?
• Можно ли перевернуть эти данные для получения оригинального пароля?

Для удовольствия:

Я заплачу вам $ 5, если вы сможете предоставить мне оригинальный пароль, используя хеш соль и соль + пароль.

Answer 1

Все, что сказал Кендалл, и ..

.. Пропустите хеширование, которое вы выполняете на стороне клиента в javascript. Вместо этого просто купите SSL-сертификат и отправьте учетные данные через https. Защитит вас как от новичков, так и от опытных злоумышленников.

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

Answer 2

Есть ли какие-либо недостатки наследования с этим алгоритмом?

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

Можно ли хранить соль в той же базе данных и таблице, что и хэш соли + пароля?

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

Будет ли большой пароль длиной 128 символов вызывать проблемы с производительностью входа (с точностью до нескольких секунд), еслиУ меня в таблице несколько сотен тысяч пользователей?

Ориентир: сколько времени (в секундах) требуется для проверки пароля (hash('sha512', $salt.$password_attempt )).Найдите обратное значение этого числа, и это, вероятно, близко к тому, сколько попыток ввода пароля вы можете обработать в секунду на ядро ​​ЦП.

Можно ли перевернуть эти данные для получения исходного пароля?

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