Перевод строки SQL

Question

Я ищу простой (в идеале встроенный) оператор tsql для реализации следующих переводов.У нас есть поле ссылочного номера в наших данных, которое мы хотим скрыть.Он имеет формат AAA1234, всегда 7 цифр, причем первые три - это буквенные символы, а остальные - цифры.Мы могли бы использовать какое-то сильное шифрование, но мы также хотели бы, чтобы пользователи данных могли расшифровывать номера клиентов, если это необходимо, чтобы они могли выполнять перекрестные ссылки.Вероятно, что перекрестные ссылки будут сделаны из бумажного отчета.

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

• ABC1234 в ZYX4321 (то есть A становится Z,B - Y и т. Д.)
• ABC1234 - 0102034321 (т. Е. A становится 01, Z - 26)
• ABC1234 - CBA3412 (поменять буквы и поменять местами цифры 1 и 2 с 3 и 4)

Редактировать - Предположим, что требования такие, как указано, я знаю, как обходиться с шифрованием, безопасностью, аутентификацией / авторизацией пользователей, и есть подлинные причины для того, чтобы решить эту проблему таким образом.Ни змеиного масла, ни большого плохого программиста, не угадывающего требования.У кого-нибудь есть аккуратный sql для этого?

Answer 1

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

Как правило, идея, которую вы описываете, это в лучшем случае «безопасность через неизвестность», поэтому она добавляет некоторое «чувство безопасности», но почти не «реальной безопасности».

Тем не менее, вот несколько простых решений.

1. Сохранить строку как ее шестнадцатеричное представление
«ABC1234» становится «0x41424331323334».

DECLARE @x varchar(30)

-- scrambling: convert string to its hex representation
SET @x = sys.fn_varbintohexstr(CAST('ABC1234' AS varbinary))
SELECT @x -- returns '0x41424331323334'

-- unscrambling
EXEC('SELECT CAST(' + @x + ' AS varchar(30))')

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

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

2. Сохранить строку как число (XORed со случайной солью)
«ABC1234» становится -5389962212370045368.

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

-- use a random salt (a kind of 'shared secret')
DECLARE @salt bigint
SET @salt = 0xf47142dde0d49248

DECLARE @x bigint

-- scramble: cast to bigint and XOR with the seed
SET @x = CAST(CAST('ABC1234' AS binary(8)) AS BIGINT) ^ @salt
SELECT @x -- returns -5389962212370045368

-- unscramble
SELECT CAST(CAST(@x ^ @salt as varbinary) as varchar)

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

3. Используйте встроенное симметричное шифрование
«ABC1234» становится 0x01000000AECBC6E2A5B51F09B6953DFD7A648675E4DD3CE46E93BC0D.

Это опирается на встроенные функции симметричного шифрования MSSQL2005 + (я полагаю, что для внутренних целей он использует AES256 или 3DES в зависимости от платформы).

-- use random passphrase
DECLARE @pwd varchar(30)
SET @pwd = 0xA0880D9980AE0C4EA28A8A247763AB5B
SELECT @pwd

-- encrypt with the passphrase
DECLARE @x varbinary(8000)
SET @x = EncryptByPassPhrase(@pwd, 'ABC1234')
SELECT @x -- 0x01000000AECBC6E2A5B51F09B6953DFD7A648675E4DD3CE46E93BC0D

-- decrypt
SELECT CAST(DecryptByPassPhrase(@pwd, @x) AS varchar)

См. Также EncryptByKey и другие функции crpytographic и Как: зашифровать столбец данных . Здесь используется реальное шифрование, а управление ключами изначально поддерживается MSSQL, поэтому это может послужить основой для создания некоторой «реальной» безопасности (конечно, есть еще много способов ее обойти :-)).

Answer 2

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

Answer 3

Пользователи данных должны иметь к ним доступ, но поле должно быть скрыто, чтобы никто не мог его прочитать? А затем, что вы хотите сделать, проинформировать людей, которым нужен доступ к числам, о вашем алгоритме snakeoil, и затем надеяться, что они не будут сообщать это другим? Этот способ сделает его более сложным для ваших пользователей и небезопасным для вашего работодателя. Это не приемлемо в моих глазах. Вам нужно какое-то ограничение пользователя или сильное шифрование, но здесь шифрование не является первым выбором, потому что всем нужен один и тот же ключ, и поэтому не потребуется много времени, пока кто-то, кто не авторизован, получит ключ, а затем вы надо поменять всю БД. На самом деле, лучшим способом была бы хорошая система аутентификации и ограничения пользователей.