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

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

http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d

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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

URL может быть:

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

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

Ответ 4

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

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

Дублировать объекты, потому что идентификатор URL-адреса отличается (Как упоминалось выше)
Изменение URL-адресов.

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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