Блог

Недавно я пытался реализовать собственную безопасность в скрипте входа в систему, на который я наткнулся в Интернете. После того, как я изо всех сил пытался узнать, как создать свой собственный скрипт для генерации соли для каждого пользователя, я наткнулся password_hash .

Из того, что я понимаю (исходя из чтения на этой странице), соль уже генерируется в строке при использовании password_hash . Это правда?

Еще один вопрос, который у меня был, не было бы разумно иметь 2 соли? Один непосредственно в файле, а другой в БД? Таким образом, если кто-то скомпрометирует вашу соль в БД, у вас все равно останется соль непосредственно в файле? Я читал здесь, что хранение солей никогда не является разумной идеей, но меня всегда смущало, что люди имели в виду под этим.

Использование password_hash — рекомендуемый способ хранения паролей. Не разделяйте их на БД и файлы.

Допустим, у нас есть следующие входные данные:

 $password = $_POST['password'];
 

Сначала вы хэшируете пароль, делая это:

 $hashed_password = password_hash($password, PASSWORD_DEFAULT);
 

Затем посмотрите результат:

 var_dump($hashed_password);
 

Как вы можете видеть, он хэширован. (Я предполагаю, что вы выполнили эти шаги).

Теперь вы сохраняете этот хэшированный пароль в своей базе данных, обеспечивая достаточный размер столбца пароля для хранения хэшированного значения (не менее 60 символов или более).). Когда пользователь просит их войти в систему, вы проверяете ввод пароля с этим значением хэша в базе данных, делая это:

 // Query the database for username and password
// ...

if(password_verify($password, $hashed_password)) {
    // If the password inputs matched the hashed password in the database
    // Do something, you know... log them in.
} 

// Else, Redirect them back to the login page.
 

Официальная ссылка

Да, вы правильно поняли, функция password_hash() сама сгенерирует соль и включит ее в результирующее хэш-значение. Хранение соли в базе данных абсолютно корректно, она выполняет свою работу, даже если известна.

 // Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($_POST['password'], PASSWORD_DEFAULT);

// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($_POST['password'], $existingHashFromDb);
 

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

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

Да, это правда. Почему вы сомневаетесь в php faq по функции? 🙂

Результат выполнения password_hash() состоит из четырех частей:

1. используемый алгоритм
2. параметры
3. соль
4. фактический хэш пароля

Итак, как вы можете видеть, хэш является его частью.

Конечно, у вас может быть дополнительная соль для дополнительного уровня безопасности, но я, честно говоря, думаю, что это перебор в обычном приложении php. Алгоритм bcrypt по умолчанию хорош, а дополнительный алгоритм blowfish, возможно, даже лучше.

Существует явное отсутствие обсуждения обратной и прямой совместимости, которая встроена в функции паролей PHP. Примечательно:

1. Обратная совместимость: функции паролей по сути представляют собой хорошо написанную оболочку crypt() и по своей сути обратно совместимы с crypt() хэшами формата, даже если они используют устаревшие и / или небезопасные алгоритмы хэширования.
2. Совместимость с пересылкой: вставка password_needs_rehash() и немного логики в ваш рабочий процесс аутентификации могут поддерживать ваши хэши в актуальном состоянии с текущими и будущими алгоритмами с потенциально нулевыми будущими изменениями в рабочем процессе. Примечание: любая строка, которая не соответствует указанному алгоритму, будет помечена как требующая повторного хэша, включая хэши, не совместимые с криптографией.

Например:

 class FakeDB {
    public function __call($name, $args) {
        printf("%s::%s(%s)n", __CLASS__, $name, json_encode($args));
        return $this;
    }
}

class MyAuth {
    protected $dbh;
    protected $fakeUsers = [
        // old crypt-md5 format
        1 => ['password' => '$1$AVbfJOzY$oIHHCHlD76Aw1xmjfTpm5.'],
        // old salted md5 format
        2 => ['password' => '3858f62230ac3c915f300c664312c63f', 'salt' => 'bar'],
        // current bcrypt format
        3 => ['password' => '$2y$10$3eUn9Rnf04DR.aj8R3WbHuBO9EdoceH9uKf6vMiD7tz766rMNOyTO']
    ];

    public function __construct($dbh) {
        $this->dbh = $dbh;
    }

    protected function getuser($id) {
        // just pretend these are coming from the DB
        return $this->fakeUsers[$id];
    }

    public function authUser($id, $password) {
        $userInfo = $this->getUser($id);

        // Do you have old, turbo-legacy, non-crypt hashes?
        if( strpos( $userInfo['password'], '

Вывод:

 MyAuth::authUser::password_verify
MyAuth::authUser::rehash
FakeDB::prepare(["UPDATE users SET pass = ? WHERE user_id = ?"])
FakeDB::execute([["$2y$10$zNjPwqQX/RxjHiwkeUEzwOpkucNw49yN4jjiRY70viZpAx5x69kv.",1]])
bool(true)

MyAuth::authUser::legacy_hash
MyAuth::authUser::rehash
FakeDB::prepare(["UPDATE users SET pass = ? WHERE user_id = ?"])
FakeDB::execute([["$2y$10$VRTu4pgIkGUvilTDRTXYeOQSEYqe2GjsPoWvDUeYdV2x//StjZYHu",2]])
bool(true)

MyAuth::authUser::password_verify
bool(true)
 
В качестве последнего замечания, учитывая, что вы можете повторно хэшировать пароль пользователя только при входе в систему, вам следует рассмотреть возможность "закатывания" небезопасных устаревших хэшей для защиты ваших пользователей. Под этим я подразумеваю, что после определенного льготного периода вы удаляете все небезопасные [например: голые MD5 / SHA / в противном случае слабые] хэши и заставляете своих пользователей полагаться на механизмы сброса пароля вашего приложения.

Я создал функцию, которую я постоянно использую для проверки пароля и для создания паролей, например, для их хранения в базе данных MySQL. Он использует случайно сгенерированную соль, которая намного безопаснее, чем использование статической соли.

Класс Пароль полный код:

Я создал функцию, которую я постоянно использую для проверки пароля и для создания паролей, например, для их хранения в базе данных MySQL. Он использует случайно сгенерированную соль, которая намного безопаснее, чем использование статической соли.