Насколько безопасно полагаться на хэши для идентификации файлов?

Question

Я занимаюсь разработкой программного обеспечения облачного хранилища поверх стека LAMP.

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

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

Клиенты могут хранить файлы под любой строкой (обычно это какой-то путь и имя файла).

Эта строка гарантированно уникальна, потому что на первом уровне это что-то вроде «корзин», которые пользователи должны регистрировать, как в Amazon S3 и Google storage.

Мой план состоит в том, чтобы хранить файлы в виде хэша определенного клиентом пути.

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

Но я боюсь столкновений. В настоящее время я думаю об использовании хэшей SHA1.

Я слышал, что GIT использует хэши и идентификаторы ревизий.

Я знаю, что вероятность столкновения действительно очень мала, но возможна.

Я просто не могу судить об этом. Будете ли вы или не хотите полагаться на хеш для этой цели?

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

Answer 1

Предполагая, что у вас есть хеш-функция с "идеальными" свойствами, и что криптографические хеш-функции приближаются к той теории, которая применима к атакам на день рождения .Это говорит о том, что, учитывая максимальное количество файлов, вы можете уменьшить вероятность коллизии до минимума, используя больший размер хеш-дайджеста.SHA имеет 160 бит, поэтому для любого практического числа файлов вероятность столкновения будет примерно равна нулю.Если вы посмотрите на таблицу в ссылке, то увидите, что 128-битный хэш с 10 ^ 10 файлами имеет вероятность столкновения 10 ^ -18.

Пока вероятность достаточно мала, я думаю, чтоРешение это хорошо.Сравните с вероятностью того, что планета будет поражена астероидом, необнаружимыми ошибками на диске, битами в вашей памяти и т. Д. - до тех пор, пока эти вероятности достаточно малы, мы не беспокоимся о них, потому что они «никогда»бывает.Просто возьмите достаточный запас и убедитесь, что это не самое слабое звено.

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

Если вы думаете о злоумышленнике, пытающемся перебором, в приведенном выше сценарии, ему нужно будет запросить 2 ^ 18 файлов, прежде чем ониможет получить какой-то другой случайный файл, хранящийся в системе (опять-таки, если принять 128-битный хэш и 10 ^ 10 файлов, у вас будет намного меньше файлов и более длинный хэш).2 ^ 18 - это довольно большое число, и скорость, с которой вы можете справиться, ограничена сетью и сервером.Простая блокировка пользователя после x попыток политики может полностью закрыть эту дыру (именно поэтому многие системы реализуют такую ​​политику).Построение защищенной системы является сложным, и будет много вопросов для рассмотрения, но схема такого рода может быть совершенно безопасной.

Надеюсь, это полезно ...

РЕДАКТИРОВАТЬ: еще один способ думать оэто то, что практически каждая система шифрования или аутентификации полагается на определенные события, имеющие очень низкую вероятность своей безопасности.например, мне может повезти, и я угадаю главный фактор для 512-битного ключа RSA, но это настолько маловероятно, что система считается очень безопасной.

Answer 2

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

= конец бизнеса

Я бы предпочел использовать хеширование для вещей, которые были менее критичны, когда происходят столкновения; -)

Если у вас есть база данных, храните файлы под идентификаторами GUID, так что это не инкрементный индекс, а правильный глобально уникальный идентификатор. Они хорошо работают, когда дело доходит до распределенных сегментов / высокой доступности и т. Д.

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