Я подумал, что, может быть, моя система входа в систему не так безопасна, как я думал. Итак, во-первых, я объясню вам, на словах, что я делаю.
Когда пользователь регистрируется, генерируется соль 16 символов. Я храню соль в базе данных в поле под названием «соль». Я храню хэшированный пароль + соль (они хэшируют вместе hash("sha256", $salt.$password); ) в поле «пароль»,
Когда пользователь пытается войти в систему, я беру поле «пароль» и поле «соль» из базы данных, а также несколько других вещей.
Чтобы проверить, правильно ли они ввели свой пароль, я делаю следующее:
$hashed = hash("sha256", $row['salt'].$pass); if ($row['password'] == $hashed) { //success
($ row – выбранный массив из базы данных. $ row ['salt'] – это соль в базе данных, $ pass – это пароль, который они ввели, а $ row ["password"] – хэшированный проход + соль в базе данных )
Я думал, и мне кажется, что моя соль предлагает мало (или вообще нет) преимуществ в плане безопасности. Мой вопрос для всех вас таков: мой метод предлагает дополнительную защиту (или он даже защищает все это?)
Кроме того, у меня есть второй вопрос. Я хочу проверить, что этот скрипт «check login» нельзя подделать / обмануть, чтобы получить доступ к чужой учетной записи без их пароля.
session_start(); require_once 'db_connect.php'; //If the session variable "id" isn't set (ie they aren't logged in) if (!isset($_SESSION['id'])) { //Check if they wanted to be "remembered" (so they have 2 cookies if (isset($_COOKIE['rem_user']) && isset($_COOKIE['rem_pass'])) { $query = "SELECT id, password, auth, email, username FROM users WHERE username='".$_COOKIE['rem_user']."' AND active IS NULL" $res = mysql_query( $query ); if (mysql_num_rows($res) == 1) { $row = mysql_fetch_array($res); // If the "remember me" cookie containing their password // is equal to the one in the database, log them back in. if ($_COOKIE['rem_pass'] == $row['password']) { $_SESSION['id'] = $row['id']; $_SESSION['username'] = $row['username']; $_SESSION['auth'] = $row['auth']; $_SESSION['email'] = $row['email']; $logged_in = 1; } } } else $logged_in = 0; } else //Since the session variable "id" WAS set, they ARE logged in. $logged_in = 1;
Я бы подумал, что единственный способ войти в систему – это …
Обратная связь будет оценена по достоинству. Я хочу, чтобы моя система была в безопасности. 🙂
Спасибо!
Хорошо, вот оно … не сворачивайте свою собственную безопасность. Вот некоторые проблемы, описанные выше:
Хешированный пароль хранится как файл cookie. ЭТО НИКАКИЕ РАЗНЫЕ, КОТОРЫЕ ХРАНЯТСЯ / ПРОХОДИРОВАТЬ ПАРОЛЬ ПЛАН-ТЕКСТА, потому что он проверен как есть без функции хеш-функции.
Файл cookie – это вектор атаки на инъекции SQL.
Использует SHX для хеширования. (Используйте bcrypt, scrypt, hmac и т. Д.)
И потом я перестала смотреть. # 1 показывает, что это должно быть оставлено в существующей проверенной / проверенной библиотеке.
Использовать hash_hmac
Я использую его так: hash_hmac ($ algo, $ password. $ Salt, $ siteKey);
Даже если злоумышленник попал в вашу базу данных, им понадобится ваш sitekey для успешной работы с грубой силой, хотя я не буду комментировать столкновения. Выберите свой алго / яд. : D
Солирует ли вам дополнительную безопасность? Да. Если хеш скомпрометирован, вам нужно больше ресурсов для взлома пароля, потому что соль добавляет много комбинаций. Поэтому теперь вы не можете использовать старую традиционную атаку радужного стола . Где хранить соль – это другой вопрос. Как обычно хэш будет найден хакером? За счет компрометации базы данных. Если база данных скомпрометирована, тогда у нее также будет соль, которая сделает соление менее эффективным. Но если соль жестко закодирована в скрипте, компрометация базы данных не будет иметь эффекта. Поэтому я бы настоятельно рассмотрел соль hardcoding в скрипте или используя две соли – hardcoded или в базе данных.
Второй вопрос. Не храните пароль в файлах cookie. Вы можете легко их подделать (даже в расширенных настройках Chrome). Или украсть их (например, уязвимость XSS). Храните их в сеансе.