Система входа в систему PHP с жестким кодом имени пользователя и пароля

Мне пришлось создать базовую систему входа в систему для защиты страницы, и у меня нет доступа к базе данных, поэтому я храню имя пользователя и пароль, жестко закодированные на странице php.

Мой вопрос: может ли эта система входа выдержать атаку? Мне нужно, чтобы он продержался около 1 месяца.

Любые предложения по улучшению будут полезными. Кода нет в laravel, даже если он может выглядеть. Имя пользователя и пароль, конечно, будут изменены на что-то более надежное.

Заранее спасибо.

<?php
class UserController {
private $username;
private $password;
private $isLoggedIn = false;

// Credentials
public function credentials() {
    $credentials = array(
        array(
            "username" => "telekom",
            "password" => "1234"
        ),
        array(
            "username" => "telekom2",
            "password" => "1234"
        )
    );
    return $credentials;
}

// Basic login
public function login() {
    foreach ($this->credentials() as $credential) {
        if ($this->username == $credential['username'] && $this->password == $credential['password']) {
            Session::put('username', $this->username);
            Session::put('password', $this->password);
            $this->isLoggedIn = true;
        }
    }
}

// Get login status
public function isLoggedIn() {
    return $this->isLoggedIn;
}

// Logout
public function logout() {
    // Delete all sessions
    Session::all();
    redirect('/telekom/');
}

// Telekom
public function telekom() {
    $form = new Form();
    if (Input::get('logout') == 1) {
        $this->logout();
    }

    // Post Data from login form
    if (Input::has('username') || Input::has('password')) {
        if (!$form->isCsrfValid()) {
            $form->errors['CSRF'] = "CSRF Token";
        } // CSRF protection is on, comment to disable
        if (empty($form->errors)) {
            $this->username = Input::get('username');
            $this->password = Input::get('password');

            // Check Login
            $this->login();
            if (!$this->isLoggedIn()) {
                Session::put('login', 'Username and password do not match.');
            } else {
                redirect('/telekom/');
            }
        } else {
            Session::put('login', '<p class="color-dark-red"><strong>Errors:</strong></p>
                        <p>' . $form->displayErrors($form->errors) . '</p>');
        }
    // Check if session has username and password 
    } elseif (Session::has('username') && Session::has('password')) {
        $this->username = Session::get('username', false);
        $this->password = Session::get('password', false);
        // Check Login 
        $this->login();
    }
}
}// EOF Class User

// Outside class
$user = new UserController();

// Outside class
if (!$user->isLoggedIn()) {
    // display login form
} else {
    // display protected content    
}
?>

person George    schedule 17.09.2015    source источник
comment
Если PHP когда-либо не сможет выполнить предварительную обработку страницы, он может сбросить содержимое скрипта... В этом случае любой может увидеть имя пользователя/пароль. Не столько атака, сколько то, что нужно учитывать. Вы можете поместить его в отдельный текстовый файл (недоступный для публики) и загрузить/разобрать его с помощью php. Вместо этого это звучит как хороший кандидат для аутентификации веб-сервера.   -  person Gary    schedule 17.09.2015
comment
Класс UserController находится в папке include/controllers/UserController.php с установленным htaccesss для доступа только из моего IP-домена, автоматически загружается композитором и доступен на странице, такой как /telekom/index.php, если php не удается предварительно -процесс, как вы думаете, будут отображаться страницы, автоматически загружаемые композитором, в виде простого текста или только index.php?   -  person George    schedule 17.09.2015
comment
В случае сбоя никакие включения не будут выгружены, потому что они включаются предварительной обработкой. Единственный открытый текст, который увидит пользователь, — это фактическая страница, которую он посетил (однако он увидит включаемые пути). Но htaccess, о котором я говорил, заключается в том, что веб-сервер может сам обеспечивать базовую аутентификацию по паролю.   -  person Gary    schedule 17.09.2015
comment
Путь в index.php — это require_once dirname(DIR) . '/includes/init.php'; который защищен htacess. Заказать Запретить, Разрешить Запретить от всех Разрешить с моего ip   -  person George    schedule 17.09.2015
comment
Это хорошо. Я имел в виду потенциальное использование Apache для аутентификации доступа к index.php вместо PHP . Вы по-прежнему можете делать это так, как делаете, но я не рекомендую хранить эту информацию в одном файле. Если ничего другого, вы можете поместить эти переменные в один из ваших защищенных включений.   -  person Gary    schedule 17.09.2015
comment
Логин и пароль находятся в UserController.php, файл защищен htaccess. Спасибо, что сняли некоторые мои опасения.   -  person George    schedule 17.09.2015
comment
О, извините, я был немного туповат; Я следую сейчас. Я думаю, что ваша установка в порядке. Единственное, что я бы изменил, так это то, что пароль не хранится в памяти так долго.   -  person Gary    schedule 17.09.2015


Ответы (3)


Мои комментарии становятся длинными, поэтому я просто перенесу их сюда. Я бы не рекомендовал вам помещать имя пользователя и пароль в один и тот же файл. Если PHP когда-либо не сможет обработать страницу, она будет выведена пользователю как обычный текст. Даже для соединений с базой данных (где un/pwd почти должен храниться в виде простого текста) большинство людей не помещают информацию в один и тот же файл.

У вас есть несколько вариантов:

  1. Создайте отдельный PHP-файл, который устанавливает ваши переменные UN/PWD, поместите его в место, недоступное снаружи вашего сервера, и включите его в index.php. В этом случае я бы не включал файл до тех пор, пока вы не собираетесь сравнивать переменные и не позволять локальной области выгружать его как можно скорее.

  2. Так как это базовая аутентификация, вы можете использовать встроенный модуль Apache для аутентификации по паролю.

person Gary    schedule 17.09.2015
comment
Я избегаю базовой аутентификации от apache, потому что это некрасиво :). У меня есть имя пользователя и пароль, хранящиеся в UserController.php, защищенные с помощью htaccess. Если index.php не обработается, он покажет только местоположение init.php, init.php имеет 2 строки кода, одна для запроса userfunctions.php и одна composer/autoload.php. - person George; 17.09.2015
comment
Это действительно уродливо, но безопасно и легко настраивается. В любом случае, теперь, когда я вижу, что ты уже делаешь то, что я предлагал, я думаю, ты в порядке. - person Gary; 17.09.2015

на мой взгляд, это решение достаточно безопасно, если вы не планируете использовать его вечно. Что бы я проверил, так это настройку вашего веб-сервера - некоторые текстовые редакторы делают резервные копии отредактированных файлов, таких как index.php~, index.php.bkp или что-то в этом роде. Убедитесь, что ваш веб-сервер не обслуживает эти файлы, если они есть.

person Vrata Blazek    schedule 17.09.2015
comment
Сервер не делает резервные копии. - person George; 17.09.2015
comment
Не сервер, но некоторые текстовые редакторы могут это сделать. И сервер, если он неправильно настроен, отображает исходный код вашего скрипта, когда, например, yourserver.com/index.php~ запрашивается адрес. - person Vrata Blazek; 17.09.2015
comment
Я проверил на всякий случай, я отредактировал код с помощью возвышенного текста 3, резервных копий, похоже, нет. Я редактирую файл php локально, а затем загружаю на сервер. Спасибо за ваше предложение. - person George; 17.09.2015

Проблема временных решений в том, что они никогда не бывают временными.

Никогда не используйте жесткие пароли. Вот некоторые из причин:

  • Сохранить исходный код в секрете труднее, чем ключ.
  • Любые уязвимости на вашем сайте, которые позволяют читать исходный код, могут раскрыть пароль.
  • Пароли из разработки попадут в производство.
  • Невозможно изменить пароли без повторного развертывания.
person SilverlightFox    schedule 22.09.2015