雙因素身份驗證
你讀到的所有內容 與身份識別相關的事實是 請求者知道。 他知道他的電子郵件地址，知道如何訪問它（即知道他的電子郵件密碼），並且知道安全問題的答案。
“知識”被認為是一種認證因素； 另外兩個共同因素是 你有什麼，例如，物理設備，以及 你是誰例如指紋或眼睛的視網膜。
在大多數情況下，進行生物識別是不可行的，尤其是當我們談論Web應用程序的安全性時，因此在雙因素身份驗證（two-factorauthentication，2FA）中，通常使用第二個屬性—— “你擁有的東西”。 第二個因素的一個流行變體是物理令牌，例如， :
物理令牌通常用於企業 VPN 和金融服務中的身份驗證。 要對服務進行身份驗證，您需要將密碼和令牌上的代碼（經常更改）與 PIN 結合使用。 理論上，要識別攻擊者，他必須知道密碼、擁有令牌，並且還知道令牌的 PIN。 在密碼重置場景中，密碼本身顯然是未知的，但擁有令牌可以用來證明帳戶的所有權。 當然，與任何安全實施一樣， ，但肯定會提高進入門檻。
這種方法的主要問題之一是實施成本和後勤工作； 我們正在討論將物理設備移交給每個客戶並教他們新流程。 此外，用戶需要隨身攜帶設備，而物理令牌並不總是這樣。 另一種選擇是使用 SMS 實施第二個身份驗證因素，在 2FA 的情況下，可以確認執行重置過程的人員擁有帳戶所有者的移動電話。 谷歌是這樣做的：
您還需要啟用 ，但這意味著下次您重置密碼時，您的手機可能會成為身份驗證的第二因素。 讓我以我的 iPhone 為例來演示這一點，原因很快就會變得清楚：
識別帳戶的電子郵件地址後，Google 確定已啟用 2FA，我們可以使用驗證重置帳戶，該驗證通過短信發送到帳戶所有者的手機：
現在我們需要選擇重置過程的開始：
此操作會向註冊地址發送一封電子郵件：
此電子郵件包含重置 URL：
訪問重置 URL 時，會發送一條短信，網站會要求提供：
這是短信：
在瀏覽器中輸入後，我們回到了經典的密碼重置區域：
這聽起來可能有點冗長，確實如此，但該表格確認執行重置的人有權訪問帳戶持有人的電子郵件地址和手機。 但它比僅通過電子郵件重置密碼的安全性高九倍。 然而，也存在問題……
該問題與智能手機有關。 下面顯示的設備只能驗證一種身份驗證因素 - 它可以接收短信，但不能接收電子郵件：
不過，該設備可以接收短信 и 接收密碼重置電子郵件：
問題是我們認為電子郵件是身份驗證的第一個因素，短信（甚至是令牌生成應用程序）是第二個因素，但今天它們被組合在一個設備中。 當然，這意味著如果有人訪問您的智能手機，那麼所有這些便利都歸結為我們再次回到同一頻道； 第二個因素“你擁有什麼”意味著你也擁有第一個因素。 而且這一切都受到一個四位數 PIN 碼的保護……如果手機有 PIN 碼的話。 и 他被封鎖了。
是的，谷歌的 2FA 功能確實提供了額外的保護，但它並不是萬無一失的，而且它當然不依賴於兩個完全自治的通道。
通過用戶名重置與通過電子郵件地址重置
我應該只允許通過電子郵件地址重置嗎？ 或者用戶也應該能夠按名稱重置？ 通過用戶名重置的問題是無法通知用戶用戶名無效， 不透露 其他人可能擁有使用該名稱的帳戶。 在上一節中，電子郵件重置可確保該電子郵件的合法所有者始終收到反饋，而無需公開披露其在系統中的存在。 僅通過用戶名無法完成此操作。
所以簡短的答案是：僅限電子郵件。 如果您嘗試僅使用用戶名進行重置，那麼有時用戶會想知道發生了什麼， 或 您將披露帳戶的存在。 是的，它只是一個用戶名，而不是電子郵件地址，是的，任何人都可以選擇任何（可用）用戶名，但由於用戶傾向於重複使用名稱，您仍然很有可能間接洩露帳戶所有者。
那麼當有人忘記他們的用戶名時會發生什麼？ 假設用戶名不是立即的電子郵件地址（通常是這種情況），則該過程類似於密碼重置的開始方式 - 輸入電子郵件地址，然後向該地址發送消息，而不透露其存在。 唯一的區別是，這次消息僅包含用戶名，而不包含密碼重置 URL。 要么這樣，要么電子郵件會說該地址沒有帳戶。
身份驗證和電子郵件地址的準確性
重置密碼的一個關鍵方面，甚至可能是 最多 關鍵是要驗證嘗試重置的人的身份。 這確實是該帳戶的合法所有者，還是有人試圖侵入該帳戶或給所有者帶來不便？
顯然，電子郵件是最方便、最常見的身份驗證渠道。 它並不是萬無一失的，並且在很多情況下，如果需要高度可信的身份識別，僅僅能夠在帳戶所有者的地址接收郵件是不夠的（這就是使用 2FA 的原因），但它幾乎總是起點.重置過程。
如果電子郵件要在提供信心方面發揮作用，那麼第一步就是確保電子郵件地址確實正確。 如果有人弄錯了符號，那麼顯然重置將不會開始。 註冊時的電子郵件驗證過程是驗證地址正確性的可靠方法。 我們都見過它的實際應用：當您註冊時，您會收到一封電子郵件，其中包含一個可供點擊的唯一 URL，這將確認您是該電子郵件帳戶的真正所有者。 在該過程完成之前無法登錄可確保有動力驗證地址。
與安全性的許多其他方面的情況一樣，該模型降低了可用性，以換取相對於用戶身份的置信度而言提供更高程度的安全性。 對於用戶高度重視註冊並樂意在流程中添加另一個步驟（付費服務、銀行業務等）的網站來說，這可能是可以接受的，但如果用戶認為該帳戶是“一個- time”，並使用，例如，作為對帖子發表評論的一種方式。
識別誰啟動了重置過程
顯然，惡意使用重置功能是有原因的，攻擊者可以通過多種不同的方式使用它。 我們可以使用一個簡單的技巧來幫助驗證請求的來源（這個技巧 平時 有效）是信函的補充，其中包含重置請求者 IP 地址的建議。 它為接收者提供 一些 用於識別請求來源的信息。
以下是我目前正在 ASafaWeb 中構建的重置功能的示例：
“了解更多”鏈接將用戶帶到該網站 ，提供重置請求者的位置和組織等信息：
當然，任何想要隱藏自己身份的人都有很多方法來混淆他們的真實 IP 地址，但這是添加請求者的部分標識的便捷方法，並且 最多 在某些情況下，這將使您清楚地了解誰將完成密碼重置請求。
電子郵件更改通知
這篇文章貫穿著一個主題——溝通； 盡可能詳細地告訴帳戶所有者該過程的每個步驟發生的情況，而不透露任何可能被惡意使用的內容。 這同樣適用於密碼實際更改的情況 - 通知店主！
更改密碼的原因可能有兩個來源：
- 登錄後更改密碼，因為用戶想要新密碼
- 由於用戶忘記密碼而未登錄而重置密碼
雖然這篇文章主要是關於重置的，但通知第一篇文章可以降低有人在合法所有者不知情的情況下更改密碼的風險。 怎麼會發生這種事呢？ 一個非常常見的場景是獲取合法所有者的密碼（重複使用從其他來源洩露的密碼、通過鍵盤記錄獲得的密碼、容易猜測的密碼等），然後攻擊者決定更改它，從而阻止所有者。 如果沒有電子郵件通知，真正的所有者將不會知道密碼更改。
當然，在密碼重置的情況下，所有者應該已經自己啟動了該過程（或繞過了上述身份驗證工具），因此更改 不應該 然而，令他驚訝的是，電子郵件確認將是積極的反饋和額外的驗證。 此外，它還提供了與上述場景的統一性。
哦，如果還不太明顯的話—— 不要透過郵件發送新密碼！ 這可能會讓一些人發笑，但是 :
日誌，日誌，日誌，還有更多日誌
密碼重置功能對攻擊者很有吸引力：攻擊者要么想要訪問他人的帳戶，要么只是給帳戶/系統所有者造成不便。 上面描述的許多做法可以減少濫用的可能性，但不能防止濫用，而且它們當然不會阻止人們嘗試以非預期的方式使用某個功能。
對於檢測惡意行為，日誌記錄絕對是無價的實踐，我的意思是 非常詳細的記錄。 捕獲失敗的登錄嘗試、重置密碼、更改密碼（即當用戶已經登錄時）以及任何可以幫助您了解正在發生的情況的信息； 這在將來會非常有用。 甚至個別修復日誌 部分 例如，一個好的重置功能應包括通過網站啟動重置（捕獲重置請求和使用不正確的用戶名或電子郵件的登錄嘗試）、捕獲對重置URL 上的網站的訪問（包括嘗試使用不正確的用戶名或電子郵件）令牌），然後記錄安全問題答案的成功或失敗。
當我談論日誌記錄時，我的意思不僅是記錄頁面已加載的事實，而且還收集盡可能多的信息， 如果不是保密的話。 伙計們， 請不要記錄密碼！ 日誌需要註冊授權用戶的身份（如果他是授權用戶，那麼他就被授權了） 改變了 現有密碼或嘗試重置 別人的密碼 登錄後）、它嘗試的任何用戶名或電子郵件地址，以及它嘗試使用的任何重置令牌。 但也值得記錄 IP 地址等內容，如果可能的話，甚至請求標頭。 這不僅可以讓您重新創建 該 用戶（或攻擊者）正在嘗試做的事情，而且 誰 他就是這樣一個。
將責任委託給其他表演者
如果您認為所有這些都代表著巨大的工作量，那麼您並不孤單。 事實上，建立一個可靠的賬戶處理系統並不是一件容易的事。 並不是說它技術上很難，而是它有很多功能。 這不僅僅是重置，還有註冊、安全存儲密碼、處理多次錯誤登錄嘗試等等的整個過程。 雖然 除此之外，還有很多工作要做。
如今，有許多第三方供應商很樂意消除這種痛苦，並將其全部抽象為一項託管服務。 這些服務包括 OpenID、OAuth，甚至 Facebook。 有些人 （OpenID確實在Stack Overflow上非常成功），但其他的 .
毫無疑問，像 OpenID 這樣的服務解決了很多開發人員的問題，但也可以肯定的是它增加了新的問題。 他們有什麼作用嗎？ 是的，但很明顯，我們沒有看到身份驗證服務提供商的服務被大量使用。 銀行、航空公司、甚至商店都實施自己的身份驗證機制，這顯然是有充分理由的。
惡意重置
上述每個示例的一個重要方面是舊密碼僅被視為無用 確認賬戶所有者身份後。 這很重要，因為如果可以重置帳戶 對 身份檢查，這將為各種惡意活動提供機會。
舉個例子：有人在拍賣網站上競價，在競價過程即將結束時，他們通過啟動重置過程來阻止競爭對手，從而將他們從競價中刪除。 顯然，如果設計不當的複位功能可能被誤用，可能會導致嚴重的負面結果。 值得注意的是，阻止無效登錄嘗試的帳戶是類似的情況，但這是另一篇文章的主題。
正如我上面所說，如果您讓匿名用戶僅通過知道他們的電子郵件地址即可重置任何帳戶的密碼，那麼這就是拒絕服務攻擊的現成情況。 可能不是那個 ，我們曾經談論過，但是沒有比考慮不周的密碼重置功能更快地阻止對帳戶的訪問的方法了。
最薄弱的環節
從保護單個帳戶的角度來看，上面寫的所有內容都很棒，但您始終需要牢記您所保護的帳戶周圍的生態系統。 讓我舉一個例子：
ASafaWeb 託管在 AppHarbor 提供的一項令人驚嘆的服務上。 重置託管賬戶的流程如下：
第二階段：
第二階段：
第二階段：
第二階段：
閱讀完前面的所有信息後，已經很容易理解在理想世界中我們會以稍微不同的方式實現哪些方面。 然而，我在這裡想說的是，如果我在AppHarbor 上發布像ASafaWeb 這樣的網站，然後提出很好的安全問題和答案，添加第二個身份驗證因素，並按照規則執行其他所有操作，這不會改變事實上，整個過程中最薄弱的環節將能夠打破這一切。 如果有人使用我的信息在 AppHarbor 中成功進行身份驗證，那麼他將能夠將任何 ASafaWeb 帳戶的密碼更改為他需要的密碼！
關鍵是，應全面考慮安全實施的強度：應在系統中的每個入口點對威脅進行建模，即使它是登錄 AppHarbor 等膚淺的過程。 這應該讓我清楚地知道我需要在 ASafaWeb 密碼重置過程中付出多少努力。
把它們放在一起
這篇文章包含很多信息，所以我想將其集中在一個簡單的視覺方案中：
請記住，您應該對每一項進行最詳細的記錄。 就是這樣，很簡單！
結果
我的帖子似乎很全面，但是我還有很多其他材料 可以 包括在內，但為了簡潔起見，決定不包括：救援電子郵件地址的作用、您無法訪問與您的帳戶關聯的電子郵件的情況（例如，您辭職了）等等。 正如我前面所說，重置功能並沒有那麼複雜，只是有很多不同的觀點。
儘管重置並不那麼複雜，但它經常被錯誤地執行。 上面我們看到了幾個例子，其中實現 可以 導致出現問題的情況還有很多，錯誤重置的情況 真 造成了問題。 最近事實證明 。 這是一個嚴重的負面結果！
所以要小心你的重置功能， 在設計某個功能時，不要摘下你的黑帽子，因為很有可能其他人會戴上它！
論廣告的權利
維迪斯娜 提供便宜的 每日付費，每台服務器都連接到 500 Mbps 的互聯網通道，並免費免受 DDoS 攻擊！
來源： www.habr.com