Помните, пользователя с безопасностью


Этот вопрос и не относится к безопасности паролей или шифрования самих данных. Вопрос логики. Хотите знать , какой самый верный способ создать эту схему "запомнить меня".

Я думал, следующий вид:

  1. аутентификации пользователя создать " cookie с ИДЕНТИФИКАТОРОМ сессии.
  2. " Сохранить ИДЕНТИФИКАТОР сеанса в регистрации пользователя.
  3. Сеанса истекает через 48 часов.
  4. каждый бесплатный обновить ИДЕНТИФИКАТОР сеанса.

то есть, моя идея заключалась в проверки подлинности пользователя на основе ИДЕНТИФИКАТОРА, сохраненного в файл cookie в браузере пользователя, и в регистрации пользователя в базе данных и подтверждения того, если этот ИДЕНТИФИКАТОР существует, потому что я думаю, что сохранить имя пользователя и пароль (в файлы "cookie", было то, что еще я нашел в сети этот вопрос), даже если они зашифрованы с hash и salt и др, не очень доверяю.

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

Author: KaduAmaral, 2014-09-23

1 answers

Некоторые элементы, которые мы должны с осторожностью:

  • "Cookie", которые легко украсть информацию
  • Атак через подмену запроса сайта, или Cross-site request forgery
  • Перезапустить систему и удалять все файлы cookies после изменения пароля, чтобы все могли быть воссозданы.
  • несмотря на то, что пользователь остается активным, запросить всегда пароля, когда привлечение финансовых операций.
  • Никогда не хранить данные пользователей в cookie,, такие как электронная почта, пароль, номер социального страхования, номер карты, etc.
  • основывать безопасность только на ИДЕНТИФИКАТОР сеанса, потому что этот КОД также может быть клонирован.
  • Не используйте переменные данные или передаче в качестве IP для проверки пользователя.
  • Никогда не оставит в силе подлинности вечной.
  • , Укажите путь к пользователю отключить все места, в которых сеанс увеличивать.

, Думая критериев, перечисленных выше, мы можем получить на следующем рисунке и минимизировать риски.

Генерации токена аутентификации

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

 - id           // Um identificador para o token, não utilize auto_increment,
                // pois pode trazer problemas, 
 - user_id      // Relacionamento com as informações do usuário
 - token        // Armazena o token de autenticação
 - browser      // Identifica qual browser foi utilizado para autenticar
 - last_access  // Último acesso (timestamp)
 - created_at   // Data de criação (timestamp)

Для создания id этой таблицы, мы можем использовать что-то простое типа

md5( uniqid( mt_rand(), true ) );

В Этом решении мы будем хранить также используемого браузера, чтобы затруднить попытки атак, будь то клонирование в систему, CSRF, автоматизированные атаки, коммуникации.

В PHP есть функций, которые облегчают определить браузер пользователя, но если вы предпочитаете любой способ, существует несколько интернет - . Не импортируем и браузера версии, чтобы избежать ошибок из-за автоматического обновления.

Для хранения последнего доступа пользователя, всегда обновлять поле last_access с помощью функции time().

Для поля created_at используйте также функцию time().

Маркер может быть сгенерирован таким образом, в случайном порядке, например:

sha1( uniqid( mt_rand() + time(), true ) );

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

В cookie мы сохраняем только id маркер и token в себя.

$id = md5( uniqid( mt_rand(), true ) );
$token = sha1( uniqid( mt_rand() + time(), true ) );

// Armazenar o token na tabela do banco de dados

$expire = ( time() + ( 30 * 24 * 3600 ) ); // O cookie não deve ser eterno.
$cookieToken = array( 
    'i' => $id,
    't' => $token
);
setcookie( 'auth', json_encode( $cookieToken ), $expire, '/', 'www.dominio.com', isset( $_SERVER["HTTPS"] ), true );

, Проверяя токен

В приведенном выше коде мы сообщаем вам, что файлы cookie действителен только для определенного домена, но это может быть изменено. Поэтому мы должны проверить, откуда идет запрос, и самый простой способ сделать это с помощью переменной $_SERVER['REMOTE_HOST'], домен должен быть известен.

После проверки заявок, восстановление файлов cookie, deserialize данных и утверждайте с базой данных.

$tokenData = isset( $_COOKIE['auth'] ) ? json_decode( $_COOKIE['auth'] ) : false;
if( $tokenData !== false ) {
    $id = $tokenData['i'];
    $token = $tokenData['t'];

    // Busque no banco de dados o id e valide o token;
    // Veja tambem a validade do token usando como base o campo 'created_at'
    // e o browser.
    // Se tudo estiver correto, apague este token, gere um novo
    // e inicie a sessão.
}

Увеличивая

, Чтобы сделать его еще более безопасным, вы можете зарегистрироваться, для всех ip-адресов и SESSION_IDs, которые использовали определенный маркер.

Каждый раз, когда начинается новый сеанс новый токен генерируется, просто запись во второй таблице IP, который генерируется маркер и SESSION_ID, у этих данных вы будете записывать ultima взаимодействие с системой и времени подключения.

Таблица будет выглядеть следующим образом:

 - ip            // Ip do usuário $_SERVER['REMOTE_ADDRE']
 - token_id      // Id do token que foi gerado quando o usuário iniciou a sessão.
 - session_id    // Id da sessão session_id()
 - user_agent    // Informação completa do browser $_SERVER['HTTP_USER_AGENT']
 - time          // Tempo de conexão
 - created_at    // Quando a conexão foi iniciada
 - updated_at    // Última atualização (função time() para toda atualização)

Каждый раз, когда пользователь делает какие-заявки на нашем сервере с активной сессии, мы будем обновлять запись текущего соединения с ним, беря его за session_id. Если ничего не будет восстановлен, в него запись недействительна, и bloquearemos доступ.

Для обновления, всегда должны проверить, если IP и user_agent одинаковы, так как мы можем проверить, если он имеет маркер, который был создается, когда подлинности началась.

Чтобы обновить время соединения, рассчитайте с помощью поля"created_at

time() - $created_at

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

Если маркер владеть запросы на IPs-разному на очень короткое время между ними, мы должны сделать недействительным токен и перенаправить любой запрос, подключенный к нему экран войти.

Примечания

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

Запросы вставки и обновления базы данных будет увеличиваться достаточно для этой модели. Чтобы избежать проблем, эта модель должна быть основана на банки не реляционных или использовать слой кэширования, как memcached, который будет получать все заявки, и время от времени, обновить базу данных.

Мы Должны предупредить всегда, когда пользователь более одного сеанса с активен, и предоставить возможность признания недействительными всех токенов, и войти снова.

Никогда не должны позволить обмен на пароль, не имея способ проверки подлинности, из тех, кто меняется.

Очень важно предупредить пользователя об использовании cookie-файлов и иметь политику, хорошо написано об этом.

 20
Author: marcusagm, 2014-09-24 04:45:31