Работа с зашифрованным идентификатором

Question

Билет имеет целочисленный идентификатор.

Мы решили, что пользователи не должны взаимодействовать (см., Введите в качестве параметра поиска) целочисленный идентификатор, потому что он последовательный, предсказуемый.

Таким образом, пользователи должны работать с зашифрованным идентификатором. Он должен иметь восемь символов между буквами и цифрами, избегая тех, которые выглядят как (0, o, 1, l, 5, s, u, v) и не являются последовательными.

Какой алгоритм, по вашему мнению, лучше всего подходит для генерации этого зашифрованного идентификатора, этой двусторонней конвертируемой строки? (от идентификатора до зашифрованного, от зашифрованного до идентификатора)

спасибо!

edit : hashed => encrypted

Answer 1

Хеш по определению не конвертируется обратно в оригинал.

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

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

Answer 2

Один упрощенный подход:

• Объявите строку, содержащую все символы, которые вы делаете хотите использовать.
• Чтобы получить хеш, создайте новый экземпляр Random с идентификатором билета в качестве начального числа
• Возьмите первые 8 случайных чисел из этого экземпляра Random и используйте эти числа для индексации в строке, чтобы определить 8 случайных символов.

Однако, это действительно создаст хеш , поскольку он может быть не уникальным (или обратимым). Вы уверены, что это нормально для ваших целей?

Почему бы не сгенерировать случайный «видимый идентификатор билета» при создании нового тикета, многократно генерируя случайные строки из 8 (или более?) Символов, пока вы не избежите столкновения - тогда сохраните этот видимый идентификатор билета вместе с данными билета (чтобы вы могли искать их позже, когда пользователь предоставит их вам).

Чем больше ваш алфавит или , чем больше символов вы используете, тем меньше вероятность столкновения.

Обратите внимание, что одним из преимуществ генерации случайного "видимого идентификатора", который не на основе последовательного идентификатора билета, является то, что вы не полагаетесь на безопасность через неизвестность ... если вы используете что-то, что предсказуемо создает ту же строку из того же идентификатора, а затем, если кто-то разработает этот алгоритм, вы вернетесь к тому, с чего начали (они могут определить «текущий» порядковый номер и сгенерировать следующий видимый идентификатор заявки).

Answer 3

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

Мы реализовали обертку вокруг класса DESCryptoServiceProvider, чтобы можно было шифровать строку и расшифровывать обратно в строку. Мы используем это для шифрования идентификаторов в строках запроса. Мы ToString () идентификаторы, чтобы сделать их строки, которые мы можем затем зашифровать. Наш метод класса Encrypt-обертки возвращает строку в кодировке base64. Наш класс-оболочка заботится о преобразовании ввода строки в байтовый массив, шифровании и возвращении зашифрованного байтового массива в виде строки, закодированной в base64. Метод Decrypt в нашей оболочке берет строку, закодированную в base64 строку, и расшифровывает ее в текстовую строку. Затем вам придется анализировать открытый текст обратно в int. Одно замечание, если вы используете в URL-адресе, вы должны UrlEncode кодированной строки base64, прежде чем поместить ее в URL.

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

Answer 4

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

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

Answer 5

Я думаю, что вы не хотите хэшировать данные, но кодировать их. (Хеширование - это ОДИН СПОСОБ алгоритма)

Чтобы создать кодер / декодер, просто выполните следующее:

Encode - создать набор допустимых символов - взять идентификатор, разделить его на количество символов, которые у вас есть -> Остаток становится индексом в ваших символах aray -> добавить это письмо к тем, которые у вас уже есть. - возьмите полученный результат и начните с шага 2, пока не получите результат меньше 1

Decode: Возьмите 1-й символ и получите его индекс в вашем массиве. добавьте его к текущим элементам * в вашем массиве символов возьмите следующий символ и продолжайте в шаге 2