mysql字元串加密

① MySQL函數的加密函數

a) 函數 AES_ENCRYPT(str ,key_str ) , AES_DECRYPT(crypt_str ,key_str )
函數使用說明：這些函數允許使用官方 AES 進行加密和數據加密 ( 高級加密標准 ) 演算法 , 即以前人們所熟知的 「Rijndael」 。 保密關鍵字的長度為 128 比特，不過你可以通過改變源而將其延長到 256 比特。我們選擇了 128 比特的原因是它的速度要快得多，且對於大多數用途而言這個保密程度已經夠用。
b) 函數DECODE(crypt_str ,pass_str )
函數使用說明：使用 pass_str 作為密碼，解密加密字元串 crypt_str ， crypt_str 應該是由 ENCODE() 返回的字元串。
c) 函數 ENCODE(str ,pass_str )
函數使用說明：使用 pass_str 作為密碼，解密 str 。 使用 DECODE() 解密結果。
d) 函數 DES_DECRYPT(crypt_str [,key_str ])
函數使用說明：使用 DES_ENCRYPT() 加密一個字元串。若出現錯誤，這個函數會返回 NULL 。
e) 函數 DES_ENCRYPT(str [,(key_num |key_str )])
函數使用說明：用 Triple-DES 演算法給出的關鍵字加密字元串。若出現錯誤，這個函數會返回 NULL 。
f) 函數 ENCRYPT(str [,salt ])
函數使用說明：使用 Unix crypt() 系統調用加密 str 。 salt 參數應為一個至少包含 2 個字元的字元串。若沒有給出 salt 參數，則使用任意值。
g) 函數 MD5(str )
函數使用說明：為字元串算出一個 MD5 128 比特檢查和。該值以 32 位十六進制數字的二進制字元串的形式返回 , 若參數為 NULL 則會返回 NULL 。例如，返回值可被用作散列關鍵字
h) 函數 OLD_PASSWORD(str )
函數使用說明：當 PASSWORD() 的執行變為改善安全性時， OLD_PASSWORD() 會被添加到 MySQL 。 OLD_PASSWORD() 返回從前的 PASSWORD() 執行值 ( 4.1 之前 ) ，同時允許你為任何 4.1 之前的需要連接到你的 5.1 版本 MySQL 伺服器前客戶端設置密碼，從而不至於將它們切斷
i) 函數PASSWORD(str )
函數使用說明：從原文密碼str 計算並返回密碼字元串，當參數為 NULL 時返回 NULL 。這個函數用於用戶授權表的Password 列中的加密MySQL 密碼存儲

② 如何在mysql中把密碼用md5加密

MD5是不可逆的。

但是同樣值的字元串只能有一個MD5編碼。

所以用戶登錄輸入密碼後：

在後台驗證時是先把取得的用戶密碼轉換成MD5碼，然後和資料庫中的MD5碼比較。

③ MYSQL數據表中要存儲密碼要用什麼類型

html。

那個pasword為*是可以輸出來的，如果要在mysql裡面存儲密碼，可以考慮用字元串類型 char(32) 32位，

然後將前台html裡面輸入的密碼用MD5多加密幾次（加密一次很容易破解），然後將加密後的密碼（32位）插入到資料庫中。

如果以後要實現登陸驗證功能，可以把用戶登陸的密碼MD5後再跟資料庫比較。

(3)mysql字元串加密擴展閱讀：

MySQL需要注意的地方

1、如果客戶端和伺服器端的連接需要跨越並通過不可信任的網路，那麼就需要使用SSH隧道來加密該連接的通信。

2、用set password語句來修改用戶的密碼，三個步驟，先「mysql -u root」登陸資料庫系統，

然後「mysql> update mysql.user set password=password('newpwd')」，最後執行「flush privileges」就可以了。

3、需要提防的攻擊有，防偷聽、篡改、回放、拒絕服務等，不涉及可用性和容錯方面。對所有的連接、查詢、其他操作使用基於ACL即訪問控制列表的安全措施來完成。也有一些對SSL連接的支持。

4、除了root用戶外的其他任何用戶不允許訪問MySQL主資料庫中的user表； 加密後存放在user表中的加密後的用戶密碼一旦泄露，其他人可以隨意用該用戶名/密碼相應的資料庫；

5、用grant和revoke語句來進行用戶訪問控制的工作；

6、不使用明文密碼，而是使用md5()和sha1()等單向的哈系函數來設置密碼；

7、不選用字典中的字來做密碼；

8、採用防火牆來去掉50%的外部危險，讓資料庫系統躲在防火牆後面工作，或放置在DMZ區域中。

④ 怎麼把mysql資料庫中現有的數據進行des加密，加密後的結果和java中des加密的結果一樣。

最近需要對數據進行加密/解密, 因此選用了CryptoJS庫, 對數據做DES演算法的加密/解密

首選查看官方示例, 將密文進行Base64編碼, 掉進一個大坑
<script src="htt p:/ /crypto-js.googlecod e.c om/svn/tags/3.1.2/build/rollups/tripledes.js"></script>
<script>
var encrypted = CryptoJS.DES.encrypt("Message", "Secret Passphrase");
// ciphertext changed every time you run it
// 加密的結果不應該每次都是一樣的嗎?
console.log(encrypted.toString(), encrypted.ciphertext.toString(CryptoJS.enc.Base64));
var decrypted = CryptoJS.DES.decrypt(encrypted, "Secret Passphrase");
console.log(decrypted.toString(CryptoJS.enc.Utf8));
</script>

對這些加密演算法不了解, 只能求助Google
des encrypion: js encrypted value does not match the java encrypted value
In cryptoJS you have to convert the key to hex and useit as word just like above (otherwise it will be considered as passphrase)
For the key, when you pass a string, it's treated as a passphrase and used to derive an actual key and IV. Or you can pass a WordArray that represents the actual key.

原來是我指定key的方式不對, 直接將字元串做為參數, 想當然的以為這就是key, 其實不然, CryptoJS會根據這個字元串算出真正的key和IV(各種新鮮名詞不解釋, 問我也沒用, 我也不懂 -_-")

那麼我們只需要將key和iv對應的字元串轉成CryptoJS的WordArray類型, 在DES加密時做為參數傳入即可, 這樣對Message這個字元串加密, 每次得到的密文都是YOa3le0I+dI=
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
var ivHex = CryptoJS.enc.Utf8.parse('inputvec');
var encrypted = CryptoJS.DES.encrypt('Message', keyHex, { iv: ivHex });

這樣是不是就萬事OK了? 哪有, 誰知道這坑是一個接一個啊.
我們再試試Java這邊的DES加密是不是和這個結果一樣, 具體實現請參考Simple Java Class to DES Encrypt Strings

果真掉坑裡了, Java通過DES加密Message這個字元串得到的結果是8dKft9vkZ4I=和CryptoJS算出來的不一樣啊...親

繼續求助Google
C# and Java DES Encryption value are not identical
SunJCE provider uses ECB as the default mode, and PKCS5Padding as the default padding scheme for DES.(JCA Doc)
This means that in the case of the SunJCE provider,
Cipher c1 = Cipher.getInstance("DES/ECB/PKCS5Padding");
and
Cipher c1 = Cipher.getInstance("DES");
are equivalent statements.

原來是CryptoJS進行DES加密時, 默認的模式和padding方式和Java默認的不一樣造成的, 必須使用ECB mode和PKCS5Padding, 但是CryptoJS中只有Pkcs7, 不管了, 試試看...
<script src="htt p:/ /crypto-js.googleco de.c om/svn/tags/3.1.2/build/rollups/tripledes.js"></script>
<script src="ht tp:/ /crypto-js.googleco de.c om/svn/tags/3.1.2/build/components/mode-ecb.js"></script>
<script>
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
var encrypted = CryptoJS.DES.encrypt('Message', keyHex, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
console.log(encrypted.toString(), encrypted.ciphertext.toString(CryptoJS.enc.Base64));
</script>

咦...使用Pkcs7能得到和Java DES一樣的結果了, 哇塞...好神奇
那我們試試統一Java也改成Cipher.getInstance("DES/ECB/PKCS7Padding")試試, 結果得到一個大大的錯誤
Error:java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS7Padding

沒辦法, 繼續Google
java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/ECB/PKCS7PADDING
I will point out that PKCS#5 and PKCS#7 actually specify exactly the same type of padding (they are the same!), but it's called #5 when used in this context. :)

這位大俠給出的解釋是: PKCS#5和PKCS#7是一樣的padding方式, 對加密演算法一知半解, 我也只能暫且認可這個解釋了.

忙完了DES的加密, 接下來就是使用CryptoJS來解密了. 我們需要直接解密DES加密後的base64密文字元串. CryptoJS好像沒有提供直接解密DES密文字元串的方法啊, 他的整個加密/解密過程都是內部自己在玩, 解密時需要用到加密的結果對象, 這不是坑我嗎?

只好研究下CryptoJS DES加密後返回的對象, 發現有一個屬性ciphertext, 就是密文的WordArray, 那麼解密的時候, 我們是不是只要提供這個就行了呢?
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
// direct decrypt ciphertext
var decrypted = CryptoJS.DES.decrypt({
ciphertext: CryptoJS.enc.Base64.parse('8dKft9vkZ4I=')
}, keyHex, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
console.log(decrypted.toString(CryptoJS.enc.Utf8));

果不其然, 到此為止, 問題全部解決, 豁然開朗...

完整代碼請參考CryptoJS-DES.html
Use CryptoJS encrypt message by DES and direct decrypt ciphertext, compatible with Java Cipher.getInstance("DES")

⑤ mysql資料庫連接密碼的加密方法

最基本的做法就是使用加密工具，先把字元串加密，之後用配置文件的方法，添加到你的項目中；
然後通過程序的運行，動態的將加密過的字元串進行逆轉操作，恢復成123456，你需要考慮的是，哪種加密方式可以逆反操作，MD5這樣的方式似乎只能進行單向的加密，其實，加密方式也就是一個計算的過程。

希望可以幫助到你~！

⑥ mysql欄位md5加密,求大神指點

UPDATE "這里是你的表名" SET "你需要加密的欄位" = MD5("你需要加密的欄位");
例如，我對user表中的password欄位加密
UPDATE user SET password = MD5(password);
在mysql的查詢編輯器中，可能表名和欄位名都有一個單引號，不過沒有什麼印象。
其實我也是在別的網站看見大神分析出來的，在這里也感謝那位大神。