Kohana: Понимание и репродуцирование Соли и Хешированных паролей с помощью Подлинного Модуля

Я, прежде всего, программирую в Java и C#, но использую динамические языки (ruby/perl) для поддержки более гладкого развертывания, начиная задачи ОС, автоматизированное создание отчетов, некоторый парсинг журнала, и т.д.

После короткого времени, учась и экспериментируя с рубином или жемчугом, необходимо быть в состоянии записать некоторому regex управление сценариями, которые могут изменить форматы данных или захватить информацию от журналов. Примером маленького ruby/perl сценария, который мог быть записан быстро, будет сценарий для парсинга очень большого файла журнала и отчета только несколько мероприятий или в человекочитаемом формате или в формате csv.

кроме того, имея опыт со множеством различных языков программирования должен помочь Вам думать о новых способах заняться проблемами на более структурированных языках как Java, C++ и C#.

5
задан Gary 16 November 2009 в 05:44
поделиться

2 ответа

Задача 1. Конфигурация соли хранится в config / auth.php . Найдите этот файл в modules / auth / config , затем в папке app / config (как вы, возможно, уже знаете, Kohana использует механизм каскадной файловой системы). Файл по умолчанию, возвратный массив ( 'driver' => 'ORM', 'hash_method' => 'sha1', 'salt_pattern' => '1, 3, 5, 9, 14, 15, 20, 21, 28, 30', 'время жизни' => 1209600, 'session_key' => 'auth_user', 'users' => массив ( // 'admin' => 'b3154acf3a344170077d11bdb5fff31532f679a1919e716a02', ), );

Задача 2. На мой взгляд, механизм хеширования паролей, используемый Auth, который представляет собой SHA1 с добавлением соли, достаточно безопасен при условии, что вы сохраняете свои соли, то есть файл auth.php , в безопасности.

Проблема 3. Встроенный механизм хеширования Auth использует SHA1, который относительно более устойчив к взлому, чем MD5, поэтому я бы сказал, не используйте метод MD5, независимо от того, насколько сложной может выглядеть ваша схема. Эксперт по безопасности Томас Птачек в своем блоге написал:

Нет, правда. Используйте чужой система паролей. Не создавайте свои собственные.

Самый худший уровень безопасности в отрасли проблемы (например, известный плохой LANMAN хэш) произошло потому что умный разработчики подошли к коду безопасности так же, как они сделали остальную часть их код.

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

3
ответ дан 14 December 2019 в 13:39
поделиться

Что касается точки 1 , функция hash_password () используется как для генерации хэша пароля (с учетом соли, включая соль), который хранится в базы данных (например, во время регистрации), а также для воссоздания этого хэша, когда пароль необходимо проверить (например, во время входа в систему). Функция hash_password () будет кодировать любую заданную соль (или uniqid () , если ничего не задано) в самом хэше пароля; это форма шифрования, где ключ salt_pattern является ключом; если salt_pattern можно сохранить в секрете, тогда это обеспечивает дополнительную безопасность, поскольку злоумышленник не сможет выполнить перебор хеша в автономном режиме, поскольку метод хеширования не воспроизводится ( если salt_pattern можно сохранить в секрете) :

// Signup time; forget about uniqid(); you can use any salt that
// you please; once the password hash is stored in the database there
// is no need to know where your salt came from since it will be
// included in the password hash.
$password_hash = hash_password($password, FALSE);

// Login time; note that the salt is taken from the password hash itself.
$reproduced = hash_password($password, find_salt($password_hash));
$verifies   = $password_hash == $reproduced;

Функция hash_password () сначала хеширует пароль против соли, а затем вставляет каждый символ соли в хэш пароля с соответствующим смещением salt_pattern . find_salt () извлечет эти солевые символы, чтобы можно было воспроизвести хэш. Вы можете увидеть это как hash_password () , шифрование соли и find_salt () ее дешифрование. Хотя вы также можете видеть, что у него есть hash_password () , скрывающая соль и find_salt () , обнаруживающая ее, этот метод шифрования может ' Я думаю, это можно назвать стеганографией , потому что из кода ясно, что в хэше пароля хранится соль (существование соли не секрет).

Относительно пункта 2 ], использование вашей собственной соли просто и полностью совместимо с модулем Auth и уже существующей базой данных.

Что касается пункта 3 , использование соли для каждого пользователя ( uniqid () по умолчанию) является , а не излишество. Особенно с MD5, который взломан в целях безопасности и где обнаружение коллизий уже практично с помощью современных технологий. Еще лучше было бы использовать bcrypt () , который использует намеренно более медленный алгоритм хеширования для предотвращения попыток перебора.

Что касается пункта 4 , я раньше не использовал фреймворк Kohana, но воспроизвести или перенести модуль Auth просто. Следует позаботиться о том, чтобы salt_pattern не был забыт или утерян, поскольку он является важной частью алгоритма хеширования. salt_pattern также следует держать в секрете, поскольку это единственное, что удерживает определенного злоумышленника от перебора хэшей паролей. uniqid () - это просто разумное значение по умолчанию, и его можно заменить любым, что вы хотите (при условии, что это значение для каждого пользователя, а не постоянное значение для всего сайта).


Кроме того, существует очень хороший ответ здесь на stackoverflow относительно переносимого bcrypt () и PHP . Естественно, это не будет совместимо с модулем Auth, но я все равно хотел бы упомянуть об этом, так как он '

3
ответ дан 14 December 2019 в 13:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: