2013-09-22 3 views
1

У меня есть базовый сайт, который я использую для тестирования моего метода программирования, и я хочу получить полупринятый безопасный способ ведения регистрации пользователей. Вот код для register.php.Трехуровневая проверка безопасности; сессия все еще уязвима?

$username = $_POST["username"]; //username stored plaintext 
$passhashed = crypt($_POST["password"], $username); //hashed password salted with username 
$rnum = rand(1000,9999); //assign random 4-digit number 
$authkey = crypt($rnum, $passhashed); //unique authentication key per user, hashed and salted with hashed password 
//insert into SQL 

При входе в, $username, $passhashed и $authkey хранится в $_SESSION данных.

В верхней части каждой страницы у меня есть следующий фрагмент кода:

if(isset($_SESSION["username"]) 
&& isset($_SESSION["password"]) 
&& isset($_SESSION["authkey"])) { 
    $verifyuser = $db->prepare(" 
     SELECT * 
      FROM users 
      WHERE username = :user 
      AND password = :password 
      AND authkey = :authkey 
    "); 
    $verifyuser->execute(array(
     ':user' => $_SESSION["username"], 
     ':password' => $_SESSION["password"], 
     ':authkey' => $_SESSION["authkey"])); 
    if($verifyuser->rowCount() != 1) { 
     unset($_SESSION["username"]); 
     unset($_SESSION["password"]); 
     unset($_SESSION["authkey"]); 
    } 
} 

В принципе на любой странице, он выполняет проверку, что каждый кусок магазина в $_SESSION очищает с SQL, а если нет (если какая-либо из проверок завершится с ошибкой, вы получите rowCount, а не 1), он прекратит сеанс.

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

+2

если ваш управлением банка, его вероятно, достаточно хорошо –

+0

Я понял, что не стоит упоминать, но данные '$ _SESSION' сохраняются в живых в течение нескольких дней с' ini_set ('session.cooki e_lifetime ', 60 * 60 * 24 * 3); 'и' ini_set (' session.gc_maxlifetime ', 60 * 60 * 24 * 3); '. – gator

+1

Итак, я был прав, что обычно СЕССИЯ не существует. Но это все равно не работает. Когда они вернутся, пользователи получат новый идентификатор сеанса. – djot

ответ

2

The crypt function несколько устаревший. Вам будет лучше использовать bcrypt, который предоставляется на PHP, используя password_hash и password_verify. Кроме того, используя эти функции, соль (то, что вы называете $authkey) интегрирована в строку, поэтому вам не нужно хранить ее отдельно.

Я замечаю, что вы храните имя пользователя и пароль в $_SESSION. $_SESSION не может быть напрямую изменен клиентом, поэтому вам может быть лучше хранить там идентификатор пользователя.

+0

Cheers. Я всегда ищу более релевантные и безопасные методы хеширования. Фактически, до нескольких дней назад я использовал только «md5()», думая, что у него даже есть своя безопасность. Спасибо! – gator

2

Как вы упомянули, у меня также есть базовое понимание захвата сеанса.

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

При чтении, предупреждающем захват сеанса, я увидел пример как простой: - Если текущий IP-адрес не соответствует сеансу, запишите пользователя.

<?php 
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) 
{ 
session_destroy(); 
} 
?> 

Типовое: Я больше не может найти указанный веб-сайт ...

Некоторые ссылки, которые могут помочь вам:

Preventing session hijacking

Proper session hijacking prevention in PHP

+0

Это на самом деле довольно простой, но отличный способ сделать что-то. Я добавил это к моему коду, спасибо! – gator

+1

Нет проблем. Но, пожалуйста, учтите, что было сказано по ссылкам, которые я включил, - если вы еще не посмотрели, так как может быть истинная причина изменений в IP. – RobAtStackOverflow

+0

Плохая идея, ip! = Человек, может легко изменяться между запросами. –

Смежные вопросы