構建激活/密碼重置鏈接的最佳方法

Question

構建包含激活或密碼重置令牌的鏈接的最佳方式是什麼？該網址將通過電子郵件發送，用戶需要點擊該網址才能激活其帳戶或重置密碼。現在有很多關於這個主題的，但似乎沒有成爲一個統一的方法，每個方法似乎都有優點和缺點，無論從安全和發展的角度看：

1. 鏈路包括令牌作爲參數並在查詢字符串

   http://www.example.com/activations/:token?email=joe@gmail.com 
   

   採用這種方法的電子郵件地址，令牌數據庫散列和電子郵件是用來查找用戶。然後使用像brycpt這樣的庫將令牌與數據庫中的散列版本進行比較。這似乎包括敏感數據，例如查詢字符串中的電子郵件地址exposes some security risks。

2. 鏈接只包括令牌作爲參數或查詢字符串。

   http://www.example.com/activations/:token 
   

   這似乎是理想的解決方案，但我不知道如何，除非存儲在數據庫中的令牌非散列的令牌進行比較。從安全角度來看，有些人認爲token in the database doesn't need to be hashed，而其他人則認爲token should be hashed。假設我們在數據庫中保留一個散列標記，遍歷數據庫中的每個標記並與鏈接中的標記進行比較似乎非常耗時，特別是在擁有大量用戶的應用程序中。所以也許我錯了，但似乎使用這種方法會要求我將令牌存儲在數據庫中。

任何人對最佳方法有任何想法？

Answer 1

沒有反對使用僅包含令牌的方法2的論據。

只有標記的散列應該存儲在數據庫中（SQL注入），這是正確的。您所看到的問題，來自使用BCrypt：

1. Bcrypt包括鹽，這將阻止在數據庫中的令牌搜索。
2. 由於BCrypt適用於密鑰伸縮驗證非常慢，因此無法檢查每個存儲的哈希值。

這兩種技術，salting和key-stretching，對於存儲弱密碼是強制性的，它們使暴力行爲變得不可行。因爲我們的令牌是一個非常強大的「密碼」（最少20個字符0-9個AZ），所以不需要這些技術，您可以將令牌的SHA-256無損信息存儲在數據庫中。這種散列可以直接用SQL搜索。

爲了表明它非常安全，我們做一個簡單的計算。一個20個字符的標記將允許7E35組合。如果我們能計算出3 Giga SHA-256 per second，我們仍然期望3'700'000'000'000'000'000年來找到一個匹配。

只要確保令牌是從密碼隨機源創建的。