2016-02-16 23 views
0

enter image description here的SQL Server:如何找回密碼的實際值加密使用HASHBYTES

insert into Customer(AccountNo,Name,EmailId,MobileNo,[Password],Balance, 
        CustomerKey,OTPPin,CreatedBy,CreatedOn) 
values(@AccountNumber,@Name,@EmailId, 
     EncryptByPassPhrase(@PassPhrase, CONVERT(nvarchar,@MobileNo)), 
     HASHBYTES('SHA1',@Password),@TotalBalance,@CustomerKey,@OTPPin,0,GETDATE()) 

我以這種形式enter image description here

越來越插入值現在我要密碼的實際值。我怎麼才能得到它?

回答

4

既然你已經使用HASHBYTES('SHA1'你的密碼 - 你不能簡單的回到其原始值。

SHA1是單向散列函數。

事實上,在大多數情況下,您不需要原始值。 hased密碼的典型用法不是以某種方式從hash中獲取原始值,並將其與用戶輸入的密碼進行比較,而是將hash函數應用於用戶輸入的密碼,然後比較兩個哈希值。

+1

從理論上講,你是對的,數學本身在這個時間點不能被有效地扭轉。然而,在實踐中,像oclHashcat和幾個GPU的仰臥起坐以驚人的速度猜測,甚至使用單核CPU,「12345」,「密碼」,「Jennifer2007」,「P @ $$ w0rd」,「 zhongguo「,」Changeme「,」jethrotull1「等可以通過猜測來確定,更復雜的人員密碼稍微不那麼簡單地被猜測出來(尤其是在9.7E16(2^56)的情況下,每8天NVidia Titan X視頻卡) –

1

不要使用散列單輪存儲密碼


不要使用無鹽散列保存密碼


不要使用SHA1保存密碼


立即閱讀Thomas Pornin's canonical answer to How to securely hash passwords

現在,選擇PBKDF2,BCrypt,或SCrypt。


散列規則

  • 做你的哈希,你控制它 - 在網絡上,這是你的服務器端應用程序(無論是PHP,ASP.NET等)。

    • 不是在SQL中,如果可能的話 - 你的應用程序服務器會更快,更容易擴展,並且你需要高迭代次數,以至於消耗大部分應用程序服務器的CPU以最高每秒登錄次數記錄 - 記住,8個內核可以在同一時間運行8次散列8個內核可以運行1次散列。
  • 安全地加密應用程序服務器和SQL服務器之間的連接。

  • 如果你絕對必須在SQL Server中出現亂碼,所以我有T-SQL PBKDF2 code in my Github repository與公共領域的許可證,包括很少的優化和一組測試向量。

    • 然後讓您的應用程序開發人員修復該應用程序。

Here是如何PBKDF2(或BCrypt,或SCrypt)存儲在數據庫中,是否會有所幫助的一些信息。


要針對一般

一個散列密碼比較密碼一旦你糾正你的密碼存儲,那麼正確的方法來驗證用戶的密碼是

  1. 檢索哈希密碼,鹽以及來自數據庫的迭代計數/工作因子
  2. 無論用戶使用剛纔檢索的salt和迭代計數/工作因子輸入的密碼作爲可能的密碼
  3. 如果新散列與前一個散列相同,則密碼相同。

要從哈希得到密碼的實際值:

如果你真的想要得到密碼的實際價值,你不應該只是密碼審計弱,用oclHashcat或者,如果你不能使用oclHashcat,請嘗試John the Ripper

這將對馬爾可夫和麪具攻擊(高級蠻力風格攻擊)以及統計攻擊和基於規則的字典攻擊做出每秒數十億次的密碼猜測,針對單輪SHA1或8次現代GPU的2016年初

  • 這是9.7E16(2^56)單次迭代SHA1每30天

    • 和針對無鹽哈希猜測的因爲,它可以做很多對數據庫中的每個密碼同時。
+0

您還應該注意:** 1。**散列需要完成**服務器端**,而不是客戶端。對客戶端jar或可執行文件進行逆向工程可以揭示哈希方法。散列/鹽值不應該跨越服務器邊界。 ** 2。**候選密碼應通過安全通道發送到服務器。 ** 3。**由於該散列方法已被棄用**,所以OP不應該使用SHA-1來進行散列。 –

+0

@TT。 - 好點,更新更多的信息。 –