Очепятка в коде

[The_survived 1]

Я нашёл в коде генерации ключа сессии авторизации (dle_hash) небольшую ошибку. В алфавите, из которого генерируется cоль, пропущена буква "d" и вместо неё стоит повторяющаяся буква "h".

Вырезка из кода:

$salt = sha1( str_shuffle("abchefghjkmnpqrstuvwxyz0123456789") . $stronghash );

*Файл engine/modules/sitelogin.php, строка 106. DLE 10.1

Я не буду говорить, что это огромная дыра в криптографической защите ключа. Но это — уменьшение алфавита, а, следовательно, уменьшение криптостойкости.

Можно предположить, что лицензионная копия продукта будет установлена на сервер, на котором отключена функция openssl_random_pseudo_bytes(), а RAND_MAX равен "1". Тогда вариантов перебора будет чуть более, чем 1,29 * 10⁵¹. Однако же, это число меньше количества вариантов перебора, где алфавит содержит букву "d", чуть более чем на 3,91 * 10⁴².

Меня ещё смущает тот факт, что здесь содержится не весь английский алфавит, но я предполагаю, что это так и задуманно.

Спасибо за внимание.

UPD: Не обратил внимания на функцию uniqid(), что обрабатывает mt_rand(). Она увеличит кол-во вариантов, но пропорции останутся теми же

Изменено 3 декабря 2013 пользователем The_survived

[PBoX 2]

Такими темпами ты dle код перепишешь

[celsoft 6 072]

The_survived,

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

[The_survived 1]

celsoft,

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

А разве она не защищает от хакера, знающего md5-хеш пароля пользователя? Без этой небольшой защиты можно было бы вполне легко несанкционированно авторизоваться на сайте, работающем на движке dle, если заполучить хеш-сумму пароля пользователя на другом сайте (XSS уязвимости, взлом базы данных другого сайта). Но картина совсем другая. Чтобы получить доступ к аккаунту по md5 пароля бедному хакеру нужно не только знать сам хеш, но и время, когда прошла авторизация с точностью, хотябы, до секунды ( в идеале, до 10^-64 секунды). Плюс ко всему на сервере ситуация должна совпадать с описанной в первом сообщении. Тогда можно перебором найти ключ. Мало того, так есть ещё несколько факторов... Например, ресурсоёмкости одного компьютер явно не хватит и потребуется целая сеть компьютеров. Возможно, ботнет или домашний суперкомпьютер. А ещё есть вероятность того, что сервер, так беспечно настроенный, упадёт от такой нагрузки. А вот фактор сокращения алфавита усластит злоумышленнику жизнь примерно на 0,0000003%. Не надо так.

Изменено 4 декабря 2013 пользователем The_survived

[celsoft 6 072]

А разве она не защищает от хакера, знающего md5-хеш пароля пользователя?

Нет не защищает. И даже разрешена к отключению в настройках скрипта в админпанели. Хеш пароля защищают другие функции.

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

в DLE нет XSS, а даже если и найти, то куки пользователя защищены специальными другими опциями, авторизационные куки недоступны через JS скрипты. А эта переменная также хранится в куках. как и кука с md5 паролем. А в БД пароль отличается от того что храниться в куках еще одним md5 шифрованием. И кстати использовать один и тот же пароль на разных сайтах, непростительная для администратора сайта ошибка. Администраторские пароли никогда не должны совпадать с теми что используются на других сайтах.

[The_survived 1]

Нет, Вы не поняли. XSS уязвимость/взлом бд не на сайте под dle, а на стороннем сайте, где пользователь использует такой же пароль, что и на сайте под dle

Изменено 4 декабря 2013 пользователем The_survived

[celsoft 6 072]

Нет, Вы не поняли. XSS уязвимость/взлом бд не на сайте под dle, а на стороннем сайте, где пользователь использует такой же пароль, что и на сайте под dle

Глупо использовать один и тот же пароль там где администратор и там где ты просто пользователь. Да и шифрование паролей как правило разное.

[The_survived 1]

Мало ли, какой уровень знаний о информационной безопасности у администратора. Да и речь ведь не о том. Я не говорю, что на каждом сервере отключена функция openssl_random_pseudo_bytes(), RAND_MAX равен "1" и в мире полно отчаянных хакеров с домашним суперкомпьютером. Я всего лишь заметил, что dle_hash - не просто "небольшая защита", а исчезнувшая буква "d" на 0,0000003% уменьшает криптостойкость.