🥇您想了解的有關安全密碼重設的所有資訊。第 1 部分

我最近有時間再次思考安全密碼重設功能應該如何運作，首先是當我將此功能建置到薩法網，然後當他幫助另一個人做類似的事情。在第二種情況下，我想給他一個規範資源的鏈接，其中包含如何安全實現重置功能的所有詳細資訊。然而，問題是這樣的資源並不存在，至少不存在描述對我來說重要的一切的資源。所以我決定自己寫。

你看，遺忘密碼的世界其實是個相當神祕的世界。有許多不同的、完全可以接受的觀點，也有許多相當危險的觀點。作為最終用戶，您很可能多次遇到它們中的每一個；因此，我將嘗試使用這些範例來展示誰做得正確，誰做得不好，以及您需要專注於什麼才能在您的應用程式中獲得正確的功能。

密碼儲存：雜湊、加密和（驚呼！）純文字

在討論如何儲存密碼之前，我們不能討論如何處理忘記的密碼。密碼以三種主要類型之一儲存在資料庫中：

簡單的文字。有一個密碼列，以純文字形式儲存。
已加密。通常採用對稱加密（加密和解密均使用一個金鑰），加密後的密碼也儲存在同一列中。
散列。單向過程（密碼可以進行哈希處理，但不能進行去哈希處理）；密碼， 我願意希望，後面跟著一個鹽，每個鹽都在自己的列中。

我們直接回答最簡單的問題： 切勿以純文字形式儲存密碼！ 絕不。一個漏洞注射，一個不小心的備份，或數十個其他簡單錯誤之一 - 就是這樣，遊戲結束，你所有的密碼 - 也就是說，抱歉， 您所有客戶的密碼 將成為公共領域。當然，這意味著極有可能他們所有的密碼來自他們在其他系統中的所有帳戶。這將是你的錯。

加密效果更好，但也有其弱點。加密的問題是解密；我們可以將這些看起來瘋狂的密碼轉換回純文本，當這種情況發生時，我們又回到了人類可讀的密碼情況。這是怎麼發生的？解密密碼的程式碼中存在一個小缺陷，使其公開可用 - 這是一種方法。駭客可以存取儲存加密資料的機器 - 這是第二種方法。另一種方法是竊取資料庫備份，有人還可以獲得加密金鑰，而該金鑰的儲存方式通常非常不安全。

這就引出了哈希。散列背後的想法是它是單向的；將使用者輸入的密碼與其雜湊版本進行比較的唯一方法是對輸入進行雜湊處理並進行比較。為了防止來自彩虹表等工具的攻擊，我們在過程中加入了隨機性（閱讀我的郵寄關於加密儲存）。最終，如果實作正確，我們可以確信雜湊密碼永遠不會再次變成純文字（我將在另一篇文章中討論不同雜湊演算法的好處）。

關於雜湊與加密的快速爭論：您需要加密而不是雜湊密碼的唯一原因是當您需要以純文字形式查看密碼時，並且 你永遠不應該想要這個，至少在標準網站情況下是這樣。如果您需要這個，那麼很可能您做錯了什麼！

警告！
貼文下方有色情網站 AlotPorn 的部分截圖。它修剪得很整齊，所以海灘上沒有什麼是你看不到的，但如果它仍然可能引起任何問題，請不要向下滾動。

始終重置您的密碼從來沒有別提醒他

您是否曾被要求建立一個函數提醒密碼？退後一步，反向思考這個請求：為什麼需要這個「提醒」？因為用戶忘了密碼。我們真正想做的是什麼？幫他重新登入。

我意識到「提醒」這個詞（經常）是在口語中使用的，但我們真正想做的是 安全地幫助用戶重新上線。由於我們需要安全性，因此提醒（即向用戶發送密碼）不合適的原因有兩個：

電子郵件是一個不安全的管道。正如我們不會透過 HTTP 發送任何敏感資訊（我們會使用 HTTPS）一樣，我們也不應該透過電子郵件發送任何敏感訊息，因為它的傳輸層不安全。事實上，這比簡單地透過不安全的傳輸協定發送訊息要糟糕得多，因為郵件通常儲存在儲存裝置上，系統管理員可以存取、轉發和分發、惡意軟體可以存取等等。 未加密的電子郵件是一個極度不安全的管道。
無論如何，您不應該訪問該密碼。 重新閱讀前面有關儲存的部分 - 您應該擁有密碼的雜湊值（帶有良好的強鹽），這意味著您不應該能夠以任何方式提取密碼並透過郵件發送。

讓我用一個例子來示範這個問題 usoutdoor.com：這是一個典型的登入頁面：

顯然，第一個問題是登入頁面無法透過 HTTPS 加載，但網站也會提示您發送密碼（「傳送密碼」）。這可能是上述術語的口語使用的一個例子，所以讓我們更進一步，看看會發生什麼：

不幸的是，它看起來並沒有好多少。並透過電子郵件確認存在問題：

這告訴我們 usoutdoor.com 的兩個重要面向：

該網站不會對密碼進行哈希處理。它們充其量是加密的，但很可能是以純文字形式儲存的；我們沒有看到相反的證據。
該網站透過不安全的通道發送長期密碼（我們可以返回並一次又一次地使用它）。

解決這個問題後，我們需要檢查重置過程是否以安全的方式完成。執行此操作的第一步是確保請求者有權執行重設。也就是說，在此之前我們需要進行身分檢查；讓我們看一下，如果在沒有先驗證請求者實際上是帳戶擁有者的情況下驗證身份，會發生什麼情況。

列出使用者名稱及其對匿名的影響

這個問題最好用視覺來說明。問題：

你有看到？請注意「沒有使用者使用此電子郵件地址註冊」的訊息。如果這樣的網站確認的話，問題顯然就會出現 可用性 使用者使用該電子郵件地址註冊。賓果 - 你剛剛發現了你的丈夫/老闆/鄰居的色情癖！

當然，色情內容是隱私重要性的一個相當標誌性的例子，但將身分與特定網站聯繫起來的危險比上述潛在的尷尬情況要廣泛得多。一種危險是社會工程學；如果攻擊者可以將某人與該服務相匹配，那麼他將擁有可以開始使用的資訊。例如，他可能會聯繫冒充網站代表的人並要求提供更多信息，以試圖承諾魚叉式網路釣魚.

這種做法也帶來了「使用者名稱枚舉」的危險，即人們可以透過簡單地進行群組查詢並檢查對它們的回應來驗證網站上是否存在整個使用者名稱或電子郵件地址集合。您是否有所有員工的電子郵件地址清單並需要幾分鐘時間來編寫腳本？然後你就知道問題是什麼了！

還有什麼選擇呢？事實上，它非常簡單，而且在歐貝:

在這裡，Entropay 完全沒有透露其係統中是否存在電子郵件地址 給不擁有該地址的人... 如果你 自己的 該位址並且系統中不存在，那麼您將收到以下電子郵件：

當然，在某些可接受的情況下，某人想您已在網站上註冊。但事實並非如此，或者我是透過不同的電子郵件地址進行的。上面顯示的範例很好地處理了這兩種情況。顯然，如果地址匹配，您將收到一封電子郵件，以便更輕鬆地重置密碼。

Entropay選擇的解決方案的精妙之處在於，身份驗證是根據 電子郵件 在進行任何線上驗證之前。有些網站要求使用者回答安全問題（更多內容請見下文）對如何開始重置；然而，這樣做的問題是，您必須在回答問題的同時提供某種形式的身份證明（電子郵件或用戶名），這使得在不透露匿名用戶帳戶存在的情況下幾乎不可能直觀地回答。

透過這種方法有小的可用性會降低，因為如果您嘗試重設不存在的帳戶，則不會立即得到回饋。當然，這就是發送電子郵件的全部意義，但從真正的最終用戶的角度來看，如果他們輸入了錯誤的地址，他們只有在第一次收到電子郵件時才會知道。這可能會給他帶來一些緊張，但對於如此罕見的過程來說，這只是一個很小的代價。

另一個稍微偏離主題的說明：顯示使用者名稱或電子郵件地址是否正確的登入輔助功能也存在同樣的問題。始終使用「您的用戶名和密碼組合無效」訊息來回應用戶，而不是明確確認憑證的存在（例如，「用戶名正確，但密碼不正確」）。

發送重設密碼與發送重設 URL

我們需要討論的下一個概念是如何重設密碼。有兩種流行的解決方案：

在伺服器上產生新密碼並透過電子郵件發送
發送包含唯一 URL 的電子郵件以使重置過程更輕鬆

儘管許多指南，第一點永遠不該被使用。問題是這意味著有 儲存的密碼，您可以隨時返回並再次使用；它是透過不安全的管道發送的，並保留在您的收件匣中。收件匣很可能在行動裝置和電子郵件用戶端之間同步，而且它們可能會在網路電子郵件服務中線上儲存很長時間。重點是 郵箱不能被視為可靠的長期儲存手段.

但除此之外，第一點還有一個嚴重的問題──它 盡可能簡化 惡意封鎖帳戶。如果我知道在網站上擁有帳戶的人的電子郵件地址，那麼我可以隨時透過重設密碼來阻止他們；這是輕而易舉的拒絕服務攻擊！這就是為什麼只有在成功驗證請求者的權限後才應執行重設的原因。

當我們談論重置 URL 時，我們指的是以下網站的地址 重置過程的這種特殊情況是獨一無二的。當然，它應該是隨機的，不應該容易猜測，並且不應該包含任何指向帳戶的外部鏈接，以便更容易重置。例如，重置 URL 不應該只是像「Reset/?username=JohnSmith」這樣的路徑。

我們想要建立一個唯一的令牌，可以作為重設 URL 進行郵寄，然後與使用者帳戶的伺服器記錄進行匹配，從而確認帳戶擁有者實際上就是嘗試重設密碼的同一個人。例如，令牌可以是“3ce7854015cd38c862cb9e14a1ae552b”，並與執行重設的使用者 ID 和產生令牌的時間一起儲存在表中（更多內容請見下文）。郵件發送時，包含「Reset/?id=3ce7854015cd38c862cb9e14a1ae552b」這樣的URL，使用者下載時，頁面會提示token存在，確認使用者資訊後，允許使用者變更token。

當然，由於上述過程（希望）允許使用者建立新密碼，因此我們需要確保 URL 是透過 HTTPS 載入的。不，透過 HTTPS 透過 POST 請求發送它是不夠的，這個token URL必須使用傳輸層安全，這樣新的密碼形式就不會被攻擊 MITM 使用者建立的密碼透過安全連線傳輸。

另外，對於重設 URL，您需要新增代幣時間限制，以便重置過程可以在一定的時間間隔（例如一小時內）內完成。這可確保重置時間視窗保持在最小值，以便重置 URL 的接收者只能在這個非常小的視窗內進行操作。當然，攻擊者可以再次啟動重置過程，但他們需要取得另一個唯一的重置 URL。

最後，我們需要確保這個過程是一次性的。重置過程完成後，必須刪除令牌，以便重置 URL 不再運作。前一點對於確保攻擊者有一個非常小的視窗來操縱重置 URL 是必要的。另外，當然，一旦重置成功，就不再需要令牌了。

其中一些步驟可能看起來過於多餘，但它們不會影響可用性和 事實上 提高安全性，儘管我們希望這種情況很少見。 99%的情況下，使用者會在很短的時間內啟用重置，並且在不久的將來不會再次重置密碼。

驗證碼的作用

噢，驗證碼，這個讓我們又愛又恨的安全功能！事實上，與其說驗證碼是一種保護工具，不如說它是一種識別工具——無論你是人還是機器人（或自動化腳本）。其目的是避免自動提交表單，當然，可以被用作破壞安全的嘗試。在密碼重設的情況下，CAPTCHA 表示重設功能不能強制向使用者發送垃圾郵件或嘗試確定帳戶的存在（當然，如果您遵循有關部分的建議，則這是不可能的）驗證身分）。

當然，驗證碼本身並不完美；其軟體「駭客攻擊」並取得足夠成功率（60-70%）的先例有很多。此外，我的帖子中顯示了一個解決方案自動化人破解驗證碼，您只需付給人們幾分錢來解決每個驗證碼，並實現 94% 的成功率。也就是說，它很脆弱，但它（稍微）提高了進入障礙。

讓我們來看看 PayPal 的例子：

在這種情況下，只有在解決驗證碼後才能開始重置過程，因此 理論上 不可能使該流程自動化。理論上。

然而，對於大多數 Web 應用程式來說，這有點過分了 絕對正確 代表可用性下降 - 人們只是不喜歡驗證碼！此外，如有必要，您可以輕鬆返回驗證碼。如果服務開始受到攻擊（這是日誌記錄派上用場的地方，稍後會詳細介紹），那麼添加驗證碼再簡單不過了。

秘密問題和答案

透過我們考慮的所有方法，我們只需存取電子郵件帳戶即可重設密碼。我說“只是”，但是，當然，訪問他人的電子郵件帳戶是非法的。必須是一個複雜的過程。然而情況並非總是如此.

事實上，上面的連結是關於莎拉佩林的雅虎被駭客攻擊的。有兩個目的；首先，它說明了攻擊（某些）電子郵件帳戶是多麼容易，其次，它說明瞭如何惡意使用不良安全問題。但我們稍後會再討論這個問題。

100% 基於電子郵件的密碼重設的問題在於，您嘗試重設的網站帳戶的完整性將 100% 取決於電子郵件帳戶的完整性。任何有權存取您的電子郵件的人 可以存取任何只需接收電子郵件即可重設的帳戶。對於此類帳戶，電子郵件是您在線生活的“所有大門的鑰匙”。

降低這種風險的一種方法是實施安全問答模式。毫無疑問您已經見過它們：選擇一個只有您可以回答的問題有知道答案，然後當您重設密碼時，系統會要求您提供答案。這增加了嘗試重置的人確實是帳戶所有者的信心。

回到莎拉佩林：錯誤在於她的安全問題的答案很容易找到。特別是當你是如此重要的公眾人物時，有關你母親的婚前姓氏、教育背景或某人過去可能居住的地方的資訊並不是那麼秘密。事實上，幾乎任何人都可以找到其中的大部分內容。這就是莎拉身上發生的事：

駭客 David Kernell 透過尋找佩林的背景詳細資訊（例如她的大學和出生日期），然後使用雅虎的忘記密碼恢復功能，獲得了佩林帳戶的存取權限。

首先，這是雅虎的設計錯誤。 - 透過指定這些簡單的問題，該公司基本上破壞了安全問題的價值，從而破壞了對其係統的保護。當然，重置電子郵件帳戶的密碼總是比較困難，因為您無法透過向所有者發送電子郵件（沒有第二個地址）來證明所有權，但幸運的是，如今創建這樣的系統的用途並不多。

讓我們回到安全問題 - 有一個選項允許用戶創建自己的問題。問題是這會導致非常明顯的問題：

天空是什麼顏色？

當使用安全問題來識別時，會讓人感到不舒服的問題人（例如，在呼叫中心）：

聖誕節我和誰睡了？

或者坦白說愚蠢的問題：

“密碼”怎麼拼？

當涉及安全問題時，用戶需要自救！換句話說，安全問題應該由網站本身決定，或者更好的是，由網站提出系列使用者可以選擇的安全問題。而且選擇並不容易一;理想情況下，用戶應該選擇兩個或更多安全問題 註冊帳戶時，然後將用作第二個識別通道。擁有多個問題可以增加驗證過程中的信心，並且還提供了添加隨機性的能力（並不總是顯示相同的問題），並且在實際用戶忘記密碼的情況下提供了一些冗餘。

什麼是好的安全問題？這受到幾個因素的影響：

他肯定是 簡短的 ——問題必須清晰明確。
答案一定是 具體的 ——我們不需要一個人可以給不同答案的問題
可能的答案應該是 各種各樣的 - 詢問某人最喜歡的顏色只會得到一小部分可能的答案
搜索答案一定很複雜 - 如果答案很容易找到任何（記得身居高位的人），那他就不好了
答案一定是常駐及時 - 如果你問某人最喜歡的電影，那麼一年後答案可能會不同

剛好有一個專門提出好問題的網站，名為 GoodSecurityQuestions.com。有些問題看起來相當不錯，有些則沒有通過上述的一些測試，尤其是「易於搜尋」測試。

讓我示範 PayPal 如何實施安全性問題，特別是該網站在身份驗證方面所做的努力。上面我們看到了啟動流程的頁面（帶有驗證碼），這裡我們將展示輸入電子郵件地址並解決驗證碼後會發生什麼：

結果，用戶收到以下信件：

到目前為止，一切都很正常，但以下是此重置 URL 背後隱藏的內容：

因此，安全問題就發揮了作用。事實上，PayPal還允許您透過驗證信用卡號來重設密碼，因此有一個許多網站無法存取的額外管道。我只是無法在不回答的情況下更改密碼兩安全性問題（或不知道卡號）。即使有人劫持了我的電子郵件，他們也無法重設我的 PayPal 帳戶密碼，除非他們知道更多關於我的個人資訊。什麼訊息？以下是 PayPal 提供的安全問題選項：

就搜尋的難易度而言，學校和醫院的問題可能有點不確定，但其他問題還不錯。然而，為了增強安全性，PayPal 需要額外的身份驗證變化安全問題的答案：

PayPal 是安全密碼重置的一個相當烏托邦的例子：它實現了驗證碼來減少暴力攻擊的危險，需要兩個安全問題，然後需要另一個完全不同的身份驗證來更改答案 - 而且是在用戶之後已經登入。當然，這正是我們所要的 預期的 來自貝寶；是一家處理大額資金的金融機構。這並不意味著每次密碼重設都必須遵循這些步驟（大多數情況下這是多餘的），但對於安全性至關重要的情況來說，這是一個很好的例子。

安全問題系統的便利之處在於，如果您還沒有立即實施，可以在以後根據資源保護等級需要時添加。 Apple 就是一個很好的例子，它最近才實施了這個機制 【2012年寫的文章】。當我開始在 iPad 上更新應用程式時，我看到了以下請求：

然後我看到一個螢幕，我可以在其中選擇幾對安全問題和答案，以及救援電子郵件地址：

至於 PayPal，問題是預先選定的，其中一些問題實際上相當不錯：

三個問題/答案對中的每一個都代表一組不同的可能問題，因此配置帳戶的方法有很多。

回答安全問題時需要考慮的另一個方面是儲存。在資料庫中擁有純文字資料庫會帶來與密碼幾乎相同的威脅，即暴露資料庫會立即暴露該值，不僅使應用程式面臨風險，而且可能使使用相同安全問題的完全不同的應用程式面臨風險（再次出現）阿薩伊漿果問題）。一種選擇是安全雜湊（一種強大的演算法和加密隨機鹽），但與大多數密碼儲存情況不同，可能有充分的理由將回應顯示為純文字。一個典型的場景是由現場電話接線員進行身份驗證。當然，雜湊也適用於這種情況（操作員可以簡單地輸入客戶端命名的回應），但在最壞的情況下，秘密回應必須位於某種層級的加密儲存中，即使它只是對稱加密。總結： 像對待秘密一樣對待秘密！

安全問題和答案的最後一個方面是它們更容易受到社會工程的攻擊。嘗試直接提取他人帳戶的密碼是一回事，但開始討論密碼的形成（一個流行的安全問題）則完全不同。事實上，你可以很好地與某人溝通他們生活中的許多方面，這些方面可能會提出秘密問題，而不會引起懷疑。當然，安全問題的關鍵就在於它與某人的生活經驗有關，所以容易記住，這就是問題所在—— 人們喜歡談論他們的生活經驗！ 對此您無能為力，除非您選擇此類安全問題選項，以便它們 較少的 可能可以透過社會工程來刪除。

[待續。