黃昏的甘蔗

不囉唆～直接看 T-SQL 程式與執行結果
DECLARE @var VARCHAR(200)
SELECT @var ='plaintext data'
SELECT HASHBYTES ('MD2', @var) AS MD2, HASHBYTES ('MD4', @var) AS MD4 , HASHBYTES ('MD5', @var) AS MD5
SELECT HASHBYTES ('MD2', @var) AS MD2, HASHBYTES ('MD4', @var) AS MD4 , HASHBYTES ('MD5', @var) AS MD5
SELECT HASHBYTES ('sha', @var) AS SHA, HASHBYTES ('sha1', @var) AS SHA1
SELECT HASHBYTES ('sha', @var) AS SHA, HASHBYTES ('sha1', @var) AS SHA1

經測試在SQL2005/2008都能正常運作，但是 SQL 7 就不能了（因為手邊沒SQL2000所以沒辦法測試）

為啥都要執行兩次呢？原因是要觀察雜湊法HASH（MD2、MD4、MD5、SHA）所得到的加密結果是單向且每次計算結果都相同。

 怎麼加強單向 Hash 的安全性呢？你可以在使用者輸入值的前與後增加「Salt」，例如使用者輸入的密碼是hello，在加密前將 hello 增加額外字元，使其變成「xxhello_=」，然後才丟進去加密，這樣可以避免使用者輸入的 hello 值，直接跟 ciphertext 產生關連，以增加安全性。

第二種方式，用自訂密碼來對明文做加密

SELECT encryptbypassphrase('aaa','plaintext data') AS aaa_key , encryptbypASsphrase('ccc','plaintext data') AS ccc_key
SELECT encryptbypassphrase('aaa','plaintext data') AS aaa_key , encryptbypASsphrase('ccc','plaintext data') AS ccc_key

DECLARE @ss VARBINARY(100)
SELECT @ss = encryptbypassphrase('aaa','plaintext data')
SELECT N'加解密測試','plaintext data' AS 明文, @ss AS 密文, cast(decryptbypassphrase('aaa',@ss) AS VARCHAR(max))

由上圖可以觀察到，這樣的加密方式，每次得到的密文都不一樣，無法直接用編碼加密後的字串直接做比對，必須解密後才能比對是否正確！

加密用 ENCRYPTbypassphrase、解密用 DECRYPTbypassphrase

  ----------

一般來說員工編號或帳號使用字元或數字的範圍比較容易檢查判斷，也不會有特殊的字元符號，可以簡單的利用字串判斷來過濾 SQL Injection，但是密碼就很難限制使用者怎麼設定了。

所以查詢、查驗帳號是否有效，可以直接以過濾後的帳號去以 read-only 的SQL帳號去撈資料，撈出加密後的密碼欄，再跟前端使用者輸入的密碼作加密後比對，當然一定要加鹽巴（salt）以免反而提供被TRY成功的機率。

當然將密碼撈到前端判斷絕對不是好方法！不過 Salt 的觀念可以延伸到傳統的方式。

例如使用者的密碼為 hello ，你可以加以插字讓他變成 hxelulo，然後才加密到後端去比對，這麼一來還有個好處，當 Hacker 想要串 「' or 1=1 -- 」時，就會被你改成「'x our 1=1 -- 」，並限定整個密碼長度，這麼一來又增加防護 SQL Injection 的抵抗強度了。

～End