Должен ли я скрывать значения первичного ключа?

Ответ 1

То, что вы делаете, это в основном обфускация. Реверсивный зашифрованный (и base64 на самом деле не считается как шифрование) первичный ключ все еще является первичным ключом.

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

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

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

Некоторые утверждают, что их никогда не должны видеть пользователи. Я не думаю, что вам нужно зайти так далеко.

Ответ 2

О рисках раскрытия вашего первичного ключа вы хотите прочитать " автоинкремент считается опасным", Джошуа Шахтер.

URL-адреса, содержащие идентификатор, будут препятствует вам по трем причинам.

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

Во-вторых, в какой-то момент какой-то рывок будет получите идею написать оболочку scriptс зацикливанием и попытайтесь получить каждый один объект из вашей системы; это это определенно не забава.

Наконец, в случае пользователей это позволяет людям получать какие-то социальной иерархии. Свидетельствует о частых угон и/или взлом идентификаторы ICQ с высоким уровнем престижа.

Ответ 3

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

Например, вместо того, чтобы давать пользователю значение "SearchID", вы даете им SearchToken, который представляет собой некоторое длинное уникальное psuedo-random значение (Read: GUID), которое затем отображается на SearchID внутри.

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

Если вы пытаетесь обеспечить ввод запросов к базе данных, просто используйте параметризованные запросы. Нет никакой причины скрывать первичные ключи, если они управляются публикой.

Когда вы видите base64 в URL-адресе, вы в значительной степени уверены, что разработчики этого сайта не знают, что они делают, и сайт уязвим.

Ответ 8

URL-адреса, содержащие идентификатор, будут препятствует вам по трем причинам.

Неверно, неправильно, неправильно.

Сначала - каждый запрос должен быть проверен, независимо от того, что он поступает в форме HTTP GET с идентификатором, POST или вызовом веб-службы.

Во-вторых - правильно сделанный веб-сайт нуждается в защите от ботов, которые полагаются на анализ IP-адресов и анализ частоты запросов; скрытие идентификаторов может помешать некоторым людям писать оболочку script, чтобы получить последовательность объектов, но есть и другие способы использования веб-сайта с помощью атаки с использованием грубой силы.

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

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

Ответ 9

Когда мне нужен параметр строки запроса, чтобы иметь возможность идентифицировать одну строку в столбце, я обычно добавляю столбец GUID в эту таблицу, а затем передаю GUID в строке соединения вместо значения первичного ключа строки.