通過刪除和重新創建同名來更改證書+密鑰算法

我們有一種情況，即（很久以前）使用TRIPLE_DES. 這用於加密密碼列，並被大約十個儲存過程使用（使用這些與OPEN SYMMETRIC KEY SSN_Key_01 DECRYPTION BY CERTIFICATE MyCertificate01;）

我想用AES_192. 但是，如果可能的話，我寧願避免編輯儲存過程。

我編寫了以下常式：

1. 將密碼列解密為純文字欄位
2. 刪除現有的密鑰和證書
3. 創建與上述同名的新證書和密鑰
4. 使用新的證書/密鑰重新加密純文字列

我的問題是，對於受過訓練的人來說，這裡有什麼東西會引起警鐘，特別是因為舊名稱和新名稱是相同的，並且這些名稱是在儲存過程中使用的？

我已經測試了程式碼並且它有效，但是我缺乏加密經驗和今天的資訊過載讓我非常緊張，因此請求專業知識……

-- Decrypt data

ALTER TABLE [dbo].[tbl_Users] ADD PasswordClear nvarchar(250) NULL;
GO

OPEN SYMMETRIC KEY SSN_Key_01 DECRYPTION BY CERTIFICATE MyCertificate01;
UPDATE [tbl_Users] SET PasswordClear = CONVERT(nvarchar(250), DECRYPTBYKEY(PasswordEnc))
CLOSE SYMMETRIC KEY SSN_Key_01;
GO

-- Drop old encryption

ALTER TABLE [dbo].[tbl_Users] DROP COLUMN PasswordEnc;
GO

DROP SYMMETRIC KEY SSN_Key_01;
GO

DROP CERTIFICATE [MyCertificate01];
GO


-- Create new certificate and key

CREATE CERTIFICATE MyCertificate01 WITH SUBJECT = 'My Certificate 01';
GO

CREATE SYMMETRIC KEY SSN_Key_01 WITH ALGORITHM = AES_192 ENCRYPTION BY CERTIFICATE MyCertificate01;
GO

ALTER TABLE [dbo].[tbl_Users] ADD PasswordEnc varbinary(256) NULL;
GO

OPEN SYMMETRIC KEY SSN_Key_01 DECRYPTION BY CERTIFICATE MyCertificate01;
UPDATE [tbl_Users] SET PasswordEnc = ENCRYPTBYKEY(Key_GUID('SSN_Key_01'), PasswordClear);
CLOSE SYMMETRIC KEY SSN_Key_01;
GO

ALTER TABLE [dbo].[tbl_Users] DROP COLUMN PasswordClear;
GO

ALTER TABLE [dbo].[tbl_Users] ALTER COLUMN PasswordEnc varbinary(256) NOT NULL;
GO

只是為了回饋這一點，該過程執行良好，數據已成功重新加密。

因此，儘管對對稱數據加密提出了一些擔憂（其中有商業規則來證明這一點），但一切都運作良好。

所有引用該密鑰的儲存過程都可以繼續正常工作，無需進行任何修改。

我看到以下問題：

• 有一個（短）時間跨度，所有密碼在數據庫中都未加密（以及日誌文件和日誌備份，可能還有一些錯誤日誌或跟踪等），這可能是一個真正的安全問題
• 更好地使用另一個名稱創建證書並在單個事務中進行解密/重新加密
• 您永遠無法解密密碼，否則永遠無法保存（每個開發人員都可以呼叫您的解密程序並獲取您的 CEO 的密碼或您自己的密碼，並用它來做一些有害的事情在他/她/你的名字）
• 在這種情況下，新密碼欄位應該是 a （長度取決於算法） ，而不是創建證書並與ENCRYPTBYKEY()您合作HASHBYTES('SHA2_256', password + salt)``BINARY(32)
• 當有人登錄時，您通常應該對密碼進行雜湊處理（最好在客戶端，這樣未加密的密碼將永遠不會通過 LAN 發送到您的伺服器）並僅比較雜湊值。每種程式語言中通常都有用於通用散列函式（如 SHA_256）的庫
• 您沒有對密碼進行加鹽，因此擁有密碼“P@assw0rd”的每個人都具有相同的雜湊值，可用於攻擊（將您自己的密碼設置為具有相同密碼的任何外觀）
• 所以添加一個鹽列（UNIQUEIDENTIFIER數據類型）NEWID()作為預設值，並在加密之前將其添加到原始密碼中
• 在登錄過程中，您可能必須將目前使用者的鹽（不是秘密）發送到客戶端，以將其添加到鍵入的密碼並對其進行雜湊處理
• 當您實施加鹽/散列的東西（或將來進行更改）時，您可能需要重置所有密碼（因為您無法解密它們）
• 您不能再（也不應該）發送帶有原始密碼的忘記密碼郵件。如果您有網路界面，請發送一個指向重置密碼遮罩的特殊連結，否則將密碼設置為隨機密碼並發送（這始終是一種較弱的方法）並強制使用者在第一次登錄後重置它。

引用自：https://dba.stackexchange.com/questions/237735