Плюсы и минусы использования md5 хэша URI в качестве первичного ключа в базе данных

Question

Я создаю базу данных, в которой будет храниться информация о ряде объектов (таких как научные статьи, образцы, последовательности ДНК и т. Д.), Которые все присутствуют в сети и могут быть идентифицированы с помощью URL-адреса или идентификатора, такого как DOI . Использование этих GUID в качестве первичного ключа для объекта кажется разумной идеей, и я следовал восхитительным и Connotea при использовании хеша md5 GUID. Вы увидите хэш md5 в строке состояния браузера, если навести курсор мыши на кнопки редактирования или удаления в восхитительной книжке или в закладке Connotea. Например, закладка для http://stackoverflow/ равна

http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d

где e4a42d992025b928a586b8bdc36ad38d - хэш md5 http://stackoverflow/.

Есть ли у кого-нибудь мнения о плюсах и минусах этого подхода?

Для меня преимущество этого подхода (в отличие от использования автоинкрементного первичного ключа, генерируемого самой базой данных) заключается в том, что мне приходится делать много ссылок между объектами, и с помощью хэшей md5 я могу хранить эти ссылки извне в файле (скажем, в результате анализа / извлечения данных), затем импортируйте их в базу данных. Точно так же, если база данных должна быть перестроена с нуля, URL-адреса объектов не изменятся, поскольку они используют хэш md5.

Я бы приветствовал любые мысли о том, звучит ли это разумно, или есть ли другие (лучшие?) Способы сделать это.

Answer 1

Это прекрасно.

Случайное столкновение MD5 невозможно во всех практических сценариях (чтобы получить 50% -ную вероятность столкновения, вам необходимо хешировать 6 миллиард URL в секунду каждую секунду для 100 лет).

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

Несмотря на то, что существует известная атака коллизий на MD5, преднамеренные злонамеренные коллизии в настоящее время невозможны для хэшированных URL.

• Тип коллизии, который вам нужен для намеренного столкновения с хешем другого URL-адреса, называется pre-image атака. Нет никаких известных изображений до MD5. По состоянию на 2017 год нет исследований, которые бы даже приблизились к осуществимости, поэтому даже решительный хорошо финансируемый злоумышленник не может вычислить URL-адрес, который бы хэшировал хэш любого существующего URL-адреса в вашей базе данных.

• Единственная известная атака коллизии на MD5 бесполезна для атаки URL-подобных ключей. Он работает, генерируя пару двоичных двоичных объектов, которые сталкиваются только друг с другом . Капли будут относительно длинными, содержать NUL и другие непечатаемые байты, поэтому они вряд ли будут напоминать что-либо вроде URL.

Answer 2

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

Answer 3

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

Проблемы, которые я вижу с подходом:

• Повторяющиеся объекты, потому что идентификатор URL отличается (Как уже упоминалось)
• URL меняются

Последний может быть важным - это можно сделать так же просто, как удалить и добавить. То есть, если эти идентификаторы никогда не видны / не сохраняются вне базы данных. (Например, как компонент URL.)

Полагаю, это не будет проблемой для DOI.

---

Как это будет работать с установкой целочисленного идентификатора без автонумерации, но где автономный агент вставки создает числа? (Может использовать выделенный диапазон номеров, может быть?) Может ли быть проблема с дублированием, если два пользователя независимо добавляют один и тот же URL?

Answer 4

Несколько строк могут создавать один и тот же хэш md5. Первичные ключи должны быть уникальными. Поэтому использование хеша в качестве первичного ключа не очень хорошо. Лучше использовать GUID напрямую.

GUID, подходящий для использования в URL. Конечно. Вот GUID (фактически, UUID), который я только что создал с помощью Java: 1ccb9467-e326-4fed-b9a7-7edcba52be84

URL может быть:

http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84

Это длинновато, но отлично подходит для использования и достигает того, что вы описываете.

Answer 5

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

Answer 6

Часто множество разных URL-адресов указывают на одну и ту же страницу. http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/. https://example.com/ и т.д.

Это может или не может быть проблемой для вас.

Answer 7

Может быть, вы хотите прочитать этот документ:

http://www.hpl.hp.com/techreports/2002/HPL-2002-216.pdf