PHP Login Script (безопасный, но не как банковское хранилище)

Question

Ищем скрипт входа в php.Я искал stackoverflow и видел много сообщений, но кто-нибудь может порекомендовать лучший метод?Кроме того, если я хочу использовать хеширование, как вы декодируете пароль при получении?В моем приложении для iPhone используется та же база данных, и в настоящее время пароли хранятся в обычном тексте (я знаю, что это не очень безопасно).

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

С нетерпением ждем вашего ввода.Большое спасибо.

Answer 1

С опозданием на мой ответ, но я все равно опубликую, и я знаю, что это не дает прямого ответа на вопрос, но это связано, тем не менее. Вот несколько моментов о безопасности входа в систему.

Запомнить меня

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

Сессия

Помните о захвате сессии: http://en.wikipedia.org/wiki/Session_hijacking

CSRF

Подделка межсайтовых запросов - Реализована после входа в систему, но о ней нужно знать, поскольку она затрагивает только зарегистрированных пользователей: http://en.wikipedia.org/wiki/Cross-site_request_forgery

1024 * HTTPS *

HTTPS должен использоваться на странице, на которую отправляется запрос на вход - он НЕ обязательно должен быть на странице, на которой вы вводите свои данные для входа!

хеширование

Вы можете хэшировать пароли на стороне клиента, используя javascript, который будет работать только на сервере, чтобы защитить участников от кражи их паролей при передаче их по сети, когда HTTPS не используется. Это хорошо, потому что многие люди часто используют один и тот же пароль для многих сайтов. Недостатки: вы не можете проверить длину пароля на стороне сервера, и они не могут войти, если javascript отключен (хотя вы можете программировать это до некоторой степени). Yahoo раньше (возможно, до сих пор) делал это несколько лет назад.

Когда вы получаете пароль на сервере, он часто перефразируется с помощью начального числа и сохраняется в базе данных. Это более безопасно, так как даже если люди знают хэш, они все равно не могут войти! Только оригинальный пароль будет перефразирован в тот же хеш, позволяя пользователю войти в систему.

кейлоггеров

Если вы хотите обойти клавиатурные шпионы (или большинство из них), вы можете сделать это, добавив клавиатуру / клавиатуру JavaScript. Затем пользователь нажимает буквы и цифры, чтобы ввести свой пароль, используя мышь вместо клавиатуры, и это означает, что кейлоггер с трудом регистрирует пароль.

Что-то знает, что-то есть, что-то

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

Боты

Компьютеры иногда пытаются перебрать страницу быстрого входа в систему (должна быть быстрой, как если бы пароль был неправильным, а скрипт останавливался даже на 1 секунду, что значительно сокращало общее количество попыток входа в систему, которые может предпринять бот. Чтобы помочь вам остановить это, можно приостановить неверный вход в систему на 1 или 2 секунды (как это делает linux), или вы можете сделать захват, который боты решают трудно после X неправильных входов (как это делает Google).

Там основные моменты, но я уверен, что есть и другие.

Answer 2

Все еще в разработке, но надежно, быстро, чисто, хорошо и актуально:

[актуальная версия] https://github.com/Panique/PHP-Login

[сайт старой версии] http://www.php -login.net

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

Answer 3

Это отличный учебник по дизайну системы авторизации. Он охватывает все основные темы объектно-ориентированным образом и отлично подходит для изучения различных соображений.

Декодируемые пароли не так безопасны, как могли бы, но у меня есть клиенты, которые настаивают на том, что они могут получить и изменить пароль по своему желанию, без исключений. Так что в некоторых случаях я решил добавить соль в кодировке base64 для хранения в базе данных, и это, кажется, работает довольно хорошо. Существует функция для кодирования / декодирования по мере необходимости для пользователя с правами администратора.

Действительно, контроль сеанса (и / или куки) - это метод управления доступом. Построение его с использованием объектно-ориентированного шаблона позволит вам сделать это всего лишь одной или двумя строками кода на странице (или строкой в ​​заголовке, если это распространено).

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

Answer 4

POST к URL HTTPS.

Вы никогда не расшифруете хешированный пароль. Утерянные пароли требуют другого механизма для обработки.

Да, управление сессией. Установите флажок в сеансе при входе в систему и проверьте его на других страницах.

Answer 5

в основном вы хешируете свой пароль, поэтому его нельзя извлечь в злонамеренных целях, хеш хранится в базе данных вместо пароля в виде обычного текста, вы сравниваете только 2 значения хеша.пароль, как они хотят, но веб-приложение должно на каждом этапе контролировать достоверность сеанса (хранить некоторые зарегистрированные идентификаторы в переменных сеанса с надлежащим сроком действия или что-то в этом роде), поэтому в основном вы require("session_control.inc") на каждой «защищенной» страницеВы можете проверить правильность сеанса.

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

Answer 6

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

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

Answer 7

Вы можете использовать хеширование пароля, но есть и функция php crypt () http://php.net/manual/en/function.crypt.php

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

function crypt_password($password)
{
    if($password){
        //blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 base 64
        $blowfish = '$2a$10$';

        //get the random bytes and makes a salt
        $salt = $this->get_salt();

        //append salt2 data to the password, and crypt using salt, results in a 60 char output
        $crypt_pass = crypt($password,$blowfish . $salt);

        //blowfish comes out as 60, check
        $len = strlen($crypt_pass);

        if($len == 60)
        {
            return $crypt_pass;
        }
        else {
            throw new Exception('encryption failed');
            return false;
        }
    }
    else {
        throw new Exception('encryption failed, missing password');
        return false;
    }
}

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

if (crypt($input_pass, $stored_pass) == $stored_pass) {
    return true;
}