Sql string translation

Question

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

Для основного затушевывания есть многочисленные approachs, например, мы могли бы преобразовать

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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 расшифровывать. Вы не можете легко расшифровывать все данные таким образом и должны делать это с помощью одной записи - вы можете видеть ее как плохую (неудобную) или хорошую (противнику нужно будет немного подумать, чтобы получить сразу все незашифрованные данные).

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

2. хранить строку как число (операция XOR со случайной солью)
'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 and other crpytographic functions и How to: Encrypt a Column of Data. Здесь используется какое-то реальное шифрование, а управление ключами поддерживается MSSQL, поэтому это может стать основой для создания «реальной» безопасности (конечно, есть еще много способов ее испортить :-)).