我正在驗證用戶的電子郵件地址。
大多數人告訴的方式是創建一些獨特的令牌存儲在db和 發送給用戶。從「電子郵件+鹽」作爲標記哈希以驗證電子郵件
我正在使用哈希(sha256)電子郵件地址與全站鹽
並將此散列發送給用戶。
我是否錯過了一些東西或者是否足以驗證?
我正在驗證用戶的電子郵件地址。
大多數人告訴的方式是創建一些獨特的令牌存儲在db和 發送給用戶。從「電子郵件+鹽」作爲標記哈希以驗證電子郵件
我正在使用哈希(sha256)電子郵件地址與全站鹽
並將此散列發送給用戶。
我是否錯過了一些東西或者是否足以驗證?
一些可能值得一看(或不)的東西。
如果有人發現你的鹽,那麼他們可以重建你的哈希和洪水你的系統。在這種情況下,您需要確保用戶請求將他們的電子郵件地址添加到您創建的任何內容中。 (也就是說,我不會將散列存儲在數據庫中)
另外,如果salt相同,如果他們再次請求同一個電子郵件地址,散列值將相同。每次發出請求時,你是否想要不同的哈希值,即使是相同的電子郵件地址?您可以將服務器日期/時間連接到電子郵件地址,然後再對其進行散列以使其每次都不同。
你可以這樣做,如果沒有人得到服務器端的salt,它就是保存。最後,它是電子郵件驗證,如果您不需要出於法律原因進行驗證,則不需要使其更復雜。
但這取決於你的目標。希望它變得更安全嗎?你想輕鬆實現嗎?你想讓它容易維護嗎?你在考慮腳本的執行時間嗎?
順便說一句:當電子郵件中有一個長鏈接時,一個非常討厭的事情:可能有電子郵件客戶端打破了你的鏈接,所以也許隨着鏈接添加代碼,如果代碼沒有完全通過鏈接傳輸,有一個用戶可以添加代碼的表單。
電子郵件或電子郵件地址? (您剛剛確認用戶的電子郵件地址?) – John
電子郵件地址 - 只需確認 – Jask
有關您使用此環境的更多信息將會有所幫助。正如所寫,似乎第三方可以攔截包含該令牌的用戶的電子郵件,然後使用具有欺騙性發件人地址的令牌來回復將驗證但不是來自實際用戶的電子郵件。 – hatchet