Проверка пароля

Question

Использование mysql и php

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

РЕДАКТИРОВАТЬ: Для тех, кто упомянул это ниже, да, пароль хэшируется в базе данных.

Answer 1

Если я вас правильно понимаю, вам интересно, есть ли разница между сравнением результатов:

$results = mysql_query("SELECT name FROM users WHERE name = $properlyEscapedName AND pass = $properlyEscapedPassword");
if (mysql_num_rows($result) == 1)
    $authenticated = true;

против

$results = mysql_query("SELECT name, pass FROM users WHERE name = $properlyEscapedName");
$array = mysql_fetch_assoc($results);
if ($array["pass"] == $unescapedPass)
    $authenticated = true;

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

Answer 2

У вас есть компромисс между информацией, предоставленной пользователю, и защитой от атак.

Если вы запрашиваете в своей базе данных проверку на наличие соответствующего логина и пароля, и она не срабатывает, вы можете только сказать пользователю, что логин или пароль ошибочны. Не помогает, если он не помнит, какой логин вы использовали для регистрации (это был "Арх01", "Арх" или "Арх1").

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

Чтобы предотвратить грубое насилие, зарегистрируйте количество попыток, сделанных IP или входом в систему, и заблокируйте любую дальнейшую попытку после 5-ти ошибок. Желательно заблокировать используемый IP, а не аккаунт.

О хранении хешированных паролей, используйте соли и hmac + sha512 в php: hash_hmac

Answer 3

Здесь я вижу 2 вопроса.

1. Общий способ проверить любую информацию в базе данных - создать базу данных для этого. Итак, введите в запрос как логин, так и пароль. Особенно, если мы храним хеш, а не сам пароль
2. Защита от подбора пароля является ценным дополнением к любой системе авторизации.

Answer 4

Чем больше вы работаете / чем дольше вы удерживаете, открываете соединение после неудачной попытки входа в систему, тем больше вы оставляете себя открытым для атаки DOS. OTOH вы должны сбалансировать это с предотвращением грубых поисков.

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

Это не полностью предотвращает атаки грубой силы, но делает их намного сложнее.

C.

Answer 5

В принципе нет никакой разницы между этими двумя методами. Оба метода сообщат вам, если пароль не совпадает с именем.