MariaDB 中的數據加密
這是我第一次在 MariaDB 中使用加密,所以我需要確保我做對了。我需要簡單地以加密方式儲存一些標識符,並且想知道我是否正確地執行了它。由於我在數據檢索時遇到了一些意想不到的行為(有時只是),我懷疑有什麼問題(我一直在檢查文件等,這一切似乎都是正確的..?)。
- 我將數據儲存在
BLOB
和NOT NULL
列中,沒有指定其他內容。- 我正在使用它插入數據,而
key
通過openssl rand -base64 32
INSERT INTO data_table ( encr_data ) VALUES( AES_ENCRYPT( "secret_string", "key" ) );
- 我正在使用以下方法檢索數據:
SELECT CAST( AES_DECRYPT( encr_data, "key" ) AS CHAR ) as encr_data FROM data_table;
這是在 MariaDB 中正確的做法嗎?秘密字元串由大約 35 - 40 個字元組成。
這對我來說真的很重要,因為我正在編寫的應用程序正在儲存一些秘密數據以與另一個 API 一起使用。換言之,加密本身不應帶來任何有關數據完整性的風險。只是想到由於任何加密錯誤(使加密+儲存的數據無法使用)而需要重新生成所有加密數據……
所以我需要確保加密字元串中沒有數據被裁剪,並且加密正確完成,因此是這個問題的原因。
AES_ENCRYPT
返回二進制數據(BLOB
或BINARY(...)
)
CASTing
一個 BLOB 到一個 CHAR 搞得一團糟。不要那樣做。您可以通過 將其轉換為十六進制
HEX(AES_ENCRYPT(...))
。 這可以放入 aVARCHAR
或TEXT
。秘密字元串由大約 35 - 40 個字元組成。
如果那是 40 個表情符號,那將佔用大量字節。我建議以下列方式之一聲明該列:
VARCHAR(200) COLLATE ascii_bin -- if storing the hex BINARY(100) -- if storing the binary version
如果用於密碼驗證,AES 是錯誤的方法。相反,請使用單向雜湊(MD5、SHA% 等)。
NULL vs NOT NULL——這取決於業務邏輯。如果您需要“尚未設置”(等),那麼
NULL
是合理的。