#hash #web-applications
Вопрос:
При создании веб-приложения, которое каким-то образом отображает отображение уникального идентификатора для повторяющегося объекта (видео на YouTube или раздел книги на сайте, подобном моему), Было бы лучше использовать идентификатор одинаковой длины, такой как хэш или уникальный ключ элемента в базе данных (1, 2, 3 и т. Д.).
Помимо раскрытия небольшой, на мой взгляд, несущественной информации о внутренних компонентах вашего приложения, почему использование хэша было бы лучше, чем просто использование уникального идентификатора?
Короче говоря: что лучше использовать в качестве публично отображаемого уникального идентификатора — хэш-значение или уникальный ключ из базы данных?
Редактировать: Я снова открываю этот вопрос, потому что Дмитрий поднял хороший вопрос о том, чтобы не привязывать именование к конкретному свойству бд. Будет ли такая привязка мешать мне оптимизировать/нормализовать базу данных в будущем?
Платформа использует php/python с ISAM /w MySQL.
Ответ №1:
Если вы не пытаетесь скрыть состояние своего внутреннего счетчика идентификаторов объектов, хэши излишне медленны (для генерации и сравнения), излишне длинны, излишне уродливы и могут столкнуться. Идентификаторы также длинные и уродливые, что делает их такими же непригодными для потребления человеком, как и хэши.
Для вещей, подобных инвентарю, просто используйте вместо этого последовательный (или разделенный) счетчик. Если вы перейдете в другую базу данных, вам просто нужно будет инициализировать новый счетчик до значения, по крайней мере, такого же большого, как ваш самый большой существующий идентификатор записи. Практически каждый сервер баз данных предоставляет вам способ сделать это.
Если вы пытаетесь скрыть состояние своего счетчика, возможно, потому, что вы подсчитываете пользователей и не хотите, чтобы конкуренты знали, сколько у вас их, я предлагаю избегать отображения ваших внутренних идентификаторов. Если вы настаиваете на их отображении и не хотите иметь недостатков хэша, вы можете рассмотреть возможность использования сдвигового регистра линейной обратной связи с максимальным периодом для генерации идентификаторов.
Ответ №2:
Я обычно использую хэши, если не хочу, чтобы пользователь мог угадать следующий идентификатор в серии. Но для ваших разделов книг я бы придерживался цифровых удостоверений личности.
Комментарии:
1. Придерживайтесь числовых идентификаторов, даже если есть много книг, написанных разными авторами? Первый автор получит набор чисел в диапазоне от 1 до 20, затем следующий получит от 21 до 30. Разве это плохо в каком-то смысле?
2. Нет, это звучит как типичное индексирование базы данных.
3. Использование хэша немного усложняет угадывание URL-адреса, но в любом случае вам нужна более надежная защита. Если вы не хотите скрыть порядок, в котором они были созданы в базе данных, или, возможно, количество, которое у вас есть. например, нужно ли кому-нибудь знать, что вы являетесь идентификатором пользователя 8 против 7 000 000.
4. Хэш не генерирует «следующий идентификатор», поэтому он не заменяет числовой идентификатор. Если только вы не имели в виду хэш чего-то плюс числовой идентификатор. В противном случае столкновение вполне вероятно. (Предположим, что 32-битные хэши объектов, учитывая «случайные» входы, ожидают столкновения в 65 Тыс. предметов?) Вместо этого вам нужен идентификатор GUID.
Ответ №3:
Использование хэшей предпочтительнее в случае, если вам по какой-либо причине потребуется перестроить базу данных, например, и порядок изменений. Порядковые номера будут перемещаться, но хэши останутся прежними.
Не полагаясь на порядок, в котором вы кладете вещи в коробку, а на свойства вещей, просто кажется … безопаснее.
Но, очевидно, следите за столкновениями.
Комментарии:
1. @Дмитрий, заказ не имеет значения. Уникальность здесь является важным вопросом. Если вы импортируете список последовательных входов в новую базу данных, он будет работать просто отлично.
Ответ №4:
С хэшами ты
- Вы можете свободно объединить базу данных с аналогичной (или создать резервную копию), если это необходимо
- Не делаете ничего, что могло бы хоть немного помочь некоторым атакам на угадывание
- Не раскрывайте больше личной информации о пользователе, чем необходимо, например, если кто-то видит пользователя под номером 2 в вашем текущем входе в базу данных, он получает информацию о том, что он пожилой.
- (При условии, что вы используете длинный хэш или идентификатор GUID), что очень поможет вам в случае, если вас купит YouTube и они решат интегрировать ваши базы данных.
- Помогая себе в случае, если появится поисковая система, которая индексирует по идентификатору пользователя.
Пожалуйста, дайте нам знать, внесли ли последние 6 месяцев некоторую ясность в этот вопрос…
Ответ №5:
Хэши не гарантированно уникальны и, как я полагаю, непротиворечивы.
Комментарии:
1. Они последовательны, но вы правы, говоря, что они не уникальны (по определению, существуют конфликты). Тем не менее, столкновений можно в значительной степени избежать, добавив какую-либо случайную или неопределенную соль (микро-время или случайное число) перед хэшированием.
2. Добавление соли не повлияет на количество столкновений.
3. .. но если вы каждый раз добавляете совершенно случайное число, они действительно не согласуются! 🙂
Ответ №6:
должны ли ваши пользователи запоминать/использовать это значение? или вы смотрите на это с точки зрения безопасности?
С точки зрения безопасности это не должно иметь значения, так как вы не должны просто полагаться на то, что люди не угадают другой, но действительный идентификатор чего — то, что они не должны видеть, чтобы не допустить их.
Комментарии:
1. На самом деле это имеет значение с точки зрения безопасности. Возможность определить порядок идентификаторов-это гораздо больше информации для криптоаналитиков, чем просто возможность время от времени сталкиваться со случайным столкновением. Это, конечно, при условии, что есть криптография для анализа.
Ответ №7:
Да, я не думаю, что вы ищете хэш — вы, скорее всего, ищете Guid.Если вы работаете на платформе .Net, попробуйте System.Guid.
Однако самая важная причина, по которой не следует использовать идентификатор Guid, — это производительность. Выполнение соединений с базой данных и поиск по (длинным) строкам очень неоптимально. Цифры растут быстро. Так что, если вам это действительно не нужно, не делайте этого.
Ответ №8:
Хэши имеют то преимущество, что вы можете проверить, являются ли они действительными или нет, ПРЕЖДЕ чем выполнять какую-либо проверку в вашей базе данных, существуют они или нет. Это может помочь вам отразить атаки со случайными хэшами, так как вам не нужно нагружать свою базу данных поддельными поисками.
Поэтому, если ваш хэш имеет какой-то четко определенный формат, например, с контрольной суммой в конце, вы можете проверить его правильность без необходимости обращаться к базе данных.