Как правильно зашифровать первичные ключи

Question

У меня есть таблица базы данных, которая имеет простое инкрементное число в качестве первичного ключа (1,2,3 и т. Д.).Эти цифры представляют выпускников колледжа с личной информацией в записях.Меня попросили дать каждой записи уникальный идентификатор при отображении пользователю (после того, как он запросил базу данных), но идентификатор не должен быть первичным ключом, и он должен быть согласованным.

Если кто-то, например, извлек запись с произвольным идентификатором 88gh344r, затем сделал другой поиск и снова извлек запись 88gh344r, он должен иметь возможность сказать «Это тот же человек».Поскольку люди должны иметь возможность распознавать идентификатор из одного поиска в следующий, идентификатор не может быть длинным и сложным.

Я думал о трех подходах:

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

2. Шифрование первичного ключаиспользуя MySQL SHA2 или AES, но они создают длинные буквенно-цифровые последовательности.

3. Шифрование первичного ключа на лету в запросе с использованием чего-то вроде шифрования Base64 в PHP.

Что из этого лучше, или я пропустил лучший подход?

Answer 1

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

Самый простой способ:

добавить символ CHARв столбце таблицы и выберите длину, которую вы хотите, чтобы другие идентификаторы имели, например, CHAR (16).

присвойте этому столбцу уникальный индекс, чтобы у вас не было дубликатов.

для каждой строки создайте безопасную * случайную * строку длиной 16 и обновите строку.

НЕ ХЕШИТ простой первичный ключ.Если ключи начинаются с 1,2,3 .., то каждый может сопоставить id с hash, просто вычисляя хэши для 1,2,3 .... и т.д.

Другая проблема заключается в том, чтонапример, если у вас уже есть 200 строк в таблице и вы добавляете 1, то злоумышленник может автоматически связать первичный ключ 201 со случайной строкой, которая только что появилась в списке.

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

Answer 2

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

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

Answer 3

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

Answer 4

Вы можете урезать хеш или зашифрованное значение до желаемой длины, но с обоими вы рискуете столкнуться. С восемью цифрами из 36 базовых у вас есть приблизительно 50% вероятность столкновения , если у вас 2 миллиона записей. Если вы не конвертируете в base-36 и просто берете восемь шестнадцатеричных цифр, вам нужно всего 80 тысяч записей.

Со случайными числами у вас нет этой проблемы, потому что вы можете наложить ограничение на уникальность столбца и сгенерировать новое число, если произойдет столкновение.

Answer 5

например, вы можете выполнить кодирование base 36 по идентификатору пользователя * 100 или чему-то еще.

идентификатор пользователя 26 = 208 идентификатор пользователя 3 = 8C

http://www.translatorscafe.com/cafe/units-converter/numbers/calculator/decimal-to-base-36

Answer 6

Не усложняйте.

Учтите это:

1. Пользователь получает альтернативный ключ сопоставления. Это может быть временное отображение сеанса и / или вторичный уникальный ключ (но это не PK и может или не может быть в той же таблице) и, конечно, должно быть уникальным для домена.

2. Токен доступа, генерируемый случайным образом для каждого элемента, но не обязательно должен быть уникальным, который объединяется с простым PK для открытого идентификатора. Это можно сделать так, чтобы при желании выглядело красиво через соответствующие преобразования. Маркер доступа также может рассматриваться как отдельное значение.

Мне нравится второй подход. В обоих случаях это не "прямой PK", который выставлен, хотя есть больше связи во 2-ой форме.

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

Счастливого кодирования.