Sql字符串翻譯

我正在尋找一個簡單的（理想的內聯）tsql語句來實現以下翻譯。我們的數據中有參考編號字段，我們希望模糊。它的格式是AAA1234，總是7位數字，前三位是字母字符，其餘是數字。我們可以使用某種強大的加密技術，但我們也希望數據用戶能夠根據需要破譯客戶編號，以便他們能夠交叉參考。交叉引用可能會從紙質報告中完成。Sql字符串翻譯

對於基本的遮掩有許多技術途徑，比如我們可以轉換

ABC1234到ZYX4321（即A變成Z，B - Ÿ等）
ABC1234到0102034321（即A變成01，Z變成26）
ABC1234到CBA3412（反向的字母和數字交換1和2 3和4）

編輯 - 假設的要求爲說，我知道我身邊的加密方式，安全性，U服務器認證/授權，並且有這種想要解決問題的真正原因。沒有蛇油，沒有大的壞程序員出來猜測要求。有沒有人有一些整潔的SQL來做到這一點？

來源

2010-11-02 MrTelly

爲什麼加密的東西，如果你希望人們能夠反正輕鬆破解加密？ – tdammers 2010-11-02 06:56:39

我們想要隱藏數據，所以偶然的用戶不會立即知道客戶號碼是什麼。就是這樣，是的，我知道它可以被破壞，這不是問題。 – MrTelly 2010-11-02 12:00:31

要做的更好的事情是在列中使用散列，然後創建另一個存儲散列和引用號的表，然後限制對該表的訪問。

來源

2010-11-02 06:49:55

爲什麼要放第二張桌子？存儲散列就足夠了。 – nico 2010-11-02 07:09:57

@nico：哈希是不可逆的。 – 2010-11-02 07:13:54

它不一定是散列，GUID或任何其他唯一標識符也可以。基本上，您的解決方案可以概括爲：1）在整個數據庫中使用非敏感ID，2）將敏感數據存儲在具有相同ID的單獨表格（限制訪問）中。 – VladV 2010-11-02 09:49:58

數據的用戶需要訪問它，但該字段應該被遮擋，因此沒有人可以讀取它？然後，你想做什麼，告訴需要訪問關於你的蛇形算法的數字的人，然後希望他們不會告訴別人？這種方式會讓你的用戶更加複雜，而且對你的僱主來說不安全。這在我眼中是不可接受的。您需要某種用戶限制或強大的加密，但加密不是第一選擇，因爲每個人都需要相同的密鑰，所以不需要很長時間，直到沒有授權的人才能獲得密鑰，然後您必須更改整個數據庫。最好的方式，實際上，將是一個很好的用戶身份驗證和限制系統。

來源

2010-11-02 07:06:54 joni

其他人已經提到，整個概念很好，值得商榷。
你應該問自己，這種類型的加密（我喜歡在這裏用「加擾」來區分「真實」加密）會發生什麼類型的攻擊，能夠防止它無法阻止的那種攻擊，以及它們與攻擊你實際上期望並正在努力預防。

一般來說，你描述它的想法最好是'安全通過隱晦'，所以它增加了一些'安全感'，但幾乎沒有'真正的安全'。

不過，這裏有一些簡單的解決方案。

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. 商店中的字符串作爲一個數字（與隨機鹽進行異或運算）
'ABC1234' 變爲-5389962212370045368。

請注意，這不是字符串超過8個字符的工作，因爲MSSQL內置XOR與整數只能（以及其中最大的是8個字節長）。當然，我們可以創建一個UDF來執行任意長二進制類型的異或操作，但在這裏我試圖保持簡單。

-- 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)

這裏隨機鹽用於加擾和解擾。你可以嘗試在它之上建立一些額外的安全性 - 比如說，將salt值存儲在你的應用程序中，並在每次調用時將它傳遞給數據庫，這樣單靠數據庫訪問不足以輕鬆獲取數據（當然，這是仍然很容易破解 - 例如，已知的明文攻擊）。

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，所以這可能是一些建立「真正的」安全性的基礎（當然，還是有很多辦法來搞砸了:-)）。

來源

2010-11-02 09:42:36 VladV

Sql字符串翻譯

回答

相關問題