Хэширование старого питона выполняется слева направо - почему это плохо?

Question

Я пытаюсь научиться защищаться от атак на сайты.Ссылка ниже показывает хороший учебник, но я озадачен одним утверждением:

In http://google -gruyere.appspot.com / part3 # 3__client_state_manipulation , в разделе «Управление файлами», Грюйерговорит, что хэш Pythons небезопасен, поскольку он хешируется слева направо.

Приложение Gruyere использует это для шифрования данных:

# global cookie_secret; only use positive hash values
h_data = str(hash(cookie_secret + c_data) & 0x7FFFFFF)

c_data - имя пользователя;cookie_secret является статической строкой (по умолчанию это просто '')

Я понимаю, что в более безопасных хеш-функциях одно изменение генерирует совершенно новый результат, но я не понимаю, почему это небезопасно, потому что разные c_dataгенерирует совершенно разные хэши!

РЕДАКТИРОВАТЬ: Как можно было бы побить такой хэш, как это?

Answer 1

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

Следовательно, если вы пользователь ro, а сервер отправляет вам HASH(secret . ro), то вы можете легко рассчитать HASH(secret . root) и войти в систему под другим пользователем.

Answer 2

Я думаю, что это просто плохое объяснение.hash() в Python небезопасен, потому что легко находить столкновения, но «хэши слева направо» не имеют ничего общего с , почему легко находить столкновения. криптографически защищенные хэши также обрабатывают данные строго последовательно;они, скорее всего, будут обрабатывать данные 128 или 256 бит за раз, а не один байт за раз, но это лишь деталь реализации.

(Следует сказать, что hash() небезопасно не ошибка в Python, потому что это не то, для чего она нужна. Это разоблаченная деталь реализации словарей Python в виде хеш-таблиц , и вы обычно не вам нужна безопасная хеш-функция для вашей хеш-таблицы, потому что это настолько сильно замедлит ее, что это приведет к поражению цели. Python действительно обеспечивает безопасные хеш-функции в модуле hashlib .(Использование небезопасного хеша - не единственная проблема с кодом, который вы показываете, но это, безусловно, самая важная проблема.)

Answer 3

Алгоритм хеширования по умолчанию в Python (для всех типов, но он имеет самые серьезные последствия для строк, поскольку они обычно хэшируются для безопасности) направлен на быструю работу и хорошее исполнение с реализацией диктов.Это не криптографическая функция хеширования, вы не должны использовать ее для безопасности.Для этого используйте hashlib.

Answer 4

Встроенная в Python хэш-функция не предназначена для безопасного криптографического хеширования.Он предназначен для эффективного хранения объектов Python в словарях.

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

hash('a') < hash('b')
hash('b') < hash('c')
hash('c') < hash('d')

Этот последовательный характер обеспечивает отличное поведение хранилища словаря, для которого он был разработан.1012 * hashlib библиотека вместо.

Answer 5

Можно было бы «разбить» хеш-код, добавив их данные в конец хешируемой строки и предсказать вывод хэш-функции.Позвольте мне проиллюстрировать это:

Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> data = 'root|admin|author'
>>> str(hash('' + data) & 0x7FFFFFF);
'116042699'
>>> data = 'root|admin|authos'
>>> str(hash('' + data) & 0x7FFFFFF);
'116042698'
>>> 

Пустая строка ('') - это секрет cookie, который вы упомянули как пустую строку.В этом конкретном примере, хотя он и не является реально используемым, можно увидеть, что хэш изменился на 1, а последний байт data также изменился «на один».Теперь этот пример на самом деле не является эксплойтом (исключая тот факт, что создание имени пользователя в формате anything_here|admin делает этого пользователя администратором), потому что после имени пользователя есть некоторые данные (слева направо), так что даже если вы создаете имя пользователя, которое очень близкок атакующему остальная часть строки меняет хэш совершенно нежелательным образом.Однако, если файл cookie был в форме 105770185|user07 вместо 105770185|user07||author, вы легко могли бы создать пользователя "user08" или "user06" и вычислить для прогнозирования хэша (hometask: что такое хешдля "user08"?).