Password Validation

Question

Использование MySQL и PHP

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

EDIT: Для тех, кто упомянул об этом ниже, да, пароль заполнен в базе данных.

Answer 1

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

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

Answer 2

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

$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 3

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

Answer 4

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

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

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

C.

Answer 5

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

Если вы запрашиваете свою базу данных, проверяя соответствующие логин и пароль, и она терпит неудачу, вы можете сообщить пользователю только, что логин или пароль ошибочны. Не помогает, если он не помнит, какой логин вы использовали для регистрации (были ли они «Arkh01», «arkh» или «Arkh1»).

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

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

О хранении хеширования паролей, используйте соль и HMAC + SHA512 в PHP: hash_hmac