15 сентября разработчики свободного фреймворка Django в срочном порядке выпустили обновленные версии Django 1.4.8, Django 1.5.4 и Django 1.6 beta 4, чтобы закрыть уязвимость, которую публично разгласили посторонние лица утром того же дня. Все патчи доступны через PyPI и со страницы загрузки . В новых версиях Django закрывается баг во фреймворке аутентификации django.contrib.auth, позволяющий осуществлять атаку типа «отказ в обслуживании» (DoS). Django хранит в базе данных парольные хэши, и они вычисляются каждый раз при попытке пользователя авторизоваться. По умолчанию Django использует стандарт формирования ключа PBKDF2, который осуществляет множество зацепленных вычислений, чтобы максимально усложнить перебор паролей. По этой причине скорость генерации ключа невысока, это вообще один из самых медленных алгоритмов. Так, на процессоре Core2 скорость генерации составляет около 70 в секунду. К сожалению, эту сложность можно использовать во вред. Django не ограничивает длину текстовых паролей, и пароли исключительно большого размера сильно нагрузят сервер, выполняющий ресурсоемкие вычисления PBKDF2. Например, пароль длиной в 1 мегабайт нагрузит сервер на 1 минуту, так что один-единственный злоумышленник способен повалить большой сервер крупной компании, просто загружая произвольные пароли на произвольные учетные записи. Уязвимости присвоен классификационный номер CVE-2013-1443. Веб-фреймворк Django используется на таких крупных сайтах, как Instagram, Disqus, Mozilla, The Washington Times, Pinterest и многих других. В обычных условиях процесс закрытия багов в Django занимает неделю, говорят разработчики. Но это для нормальных ситуаций, когда специалисты по безопасности сообщают об уязвимостях в приватном порядке и можно спокойно работать над заплаткой. Здесь же ситуация была другая: о баге сообщили публично в списке рассылки django-developers. Но и закрыть дыру было просто: длину пароля просто ограничили 4096 символами. http://www.xakep.ru/post/61287/ 20.09
вот она обратная сторона PBKDF2. Высокая нагрузка на процессор позволяет без особых ухищрений заДдоссить систему. Мне кажется PBKDF2 следует использовать с фильтрами, по типу хранения более простого хэша от части пароля stage 1 MD5(substr(0, 4, password) + _conststrongsalt) если эта часть предложенного пароля верна, то переходим к полной проверке stage 2 PBKDF2(password) естественно пользователей придется обязать создавать пароли 9-10+ символьные, а не 123, qwerty в любом случае с мд5 сервер особо не напряжешь + добраться до stage 2 намного сложнее. ну и собственно в MD5 не пропускать строки длиннее 24 символов. Существует один минус описанной выше техники, это то, что если система будет скомпрометирована и МД5 хэши станут доступны и их постоянная соль, то с легкостью будут вычислены все начала полных паролей пользователей!!!!
Можно взять первый и последний символ пароля, в середину сунуть логин пользователя, типа MD5(substr(0, 1, $password).$username.substr(strlen($password), strlen($password)-1, password)). Даже если база сайта уйдет в паблик, такие хеши никакой пользы не дадут.