題:
密碼重置提供了可能有效電子郵件地址的線索
davshowhan449
2020-03-19 18:25:56 UTC
view on stackexchange narkive permalink

我們有一個系統,如果您忘記密碼並想要重設密碼,請轉到“忘記密碼”頁面並輸入您的電子郵件地址。臨時鏈接將發送至您的電子郵件,以重置密碼。

現在,當我們對應用進行滲透測試時,發現一個問題:

應用程序正在提供嘗試重設密碼時可能有用的電子郵件地址的線索。只需猜測可能的電子郵件地址並能夠通過錯誤消息找到有效的電子郵件地址,就可以濫用此功能。

好吧,只有一個字段,當然,很明顯,如果重置密碼嘗試失敗,原因是電子郵件無效。似乎此滲透測試是錯誤的。除了添加其他字段(除了電子郵件)以重置密碼外,是否有解決此問題的解決方案?

請務必在此處闡明“無效電子郵件”和“未註冊電子郵件”之間的區別。如果用戶鍵入的內容與有效電子郵件地址的格式不匹配,那麼從安全角度考慮,當然可以通知他們該過程失敗。但是,如果他們輸入的有效電子郵件與註冊用戶沒有關聯,則該信息將被保密。
您給登錄時使用錯誤電子郵件地址的用戶有什麼反應?
@DocRoot:最好的做法是使用諸如“無效的電子郵件或密碼”之類的通用消息進行響應(假設您使用電子郵件+密碼組合作為憑據)。
@bhorkarg是的,我知道。這原意是作為《任擇議定書》的一個線索/修辭性問題。如果他們在登錄嘗試失敗時提供“一般”(錯誤)消息(如我所期望的那樣,因為這是出於用戶帳戶安全的考慮而被廣泛認可的做法),那麼為什麼要在另一個階段提供“更多公開”響應在用戶帳戶過程中?
六 答案:
yoozer8
2020-03-19 18:35:05 UTC
view on stackexchange narkive permalink

不表示嘗試“失敗”。一個用戶(合法或不合法),要求提供密碼重置鏈接,並給您一個電子郵件地址。您應該在這裡說的就是

您的提交已經收到。如果我們有一個與您的電子郵件地址匹配的帳戶,您將收到一封電子郵件,其中包含用於重置密碼的鏈接。

用戶仍將獲得鏈接(成功),但攻擊者不會知道提供的電子郵件地址是否與帳戶關聯。

為什麼還要加上第二句話?只需給出一個通用的“您的提交已收到並將被處理”。
合法用戶有時會忘記他們使用的電子郵件地址,因此很高興告訴他們,由於帳戶不存在而請求可能失敗,而電子郵件被標記為垃圾郵件等。
另外,它只是讓用戶知道期望什麼。是的,我們大多數人之前都已完成此過程,並且知道我們應該尋找電子郵件。但是,對於初次重置密碼的人,您想讓他們知道接下來會發生什麼。
但是通過嘗試註冊可以發現同樣的事情。除非您也說“註冊可能成功或可能不成功”,這對我來說聽起來很糟糕。總而言之,感覺就像輕易繞開了混淆,卻以可用性為代價(如果用戶鍵入錯誤的電子郵件,他將永遠不會發現並徒勞地等待)。
如果後面有頁面怎麼辦?例如條款和條件,通知,FYI,廣告,調查等,然後才實際發送電子郵件?這可能會影響用戶體驗。一個合法的用戶可能會說,我經歷了所有這些,最後他們沒有告訴我我的電子郵件無效嗎?
這些頁面真的必要嗎?如果必須完成一項調查,關閉多個廣告並閱讀一些ToC,然後才能重設密碼,我會認真考慮是否要使用該服務。重置密碼應該像寫下我的電子郵件地址並單擊一個按鈕一樣簡單。
-1因為您談論的是最簡單的實現,甚至沒有涉及相關的威脅模型。例如,正如評論中指出的那樣,公開已註冊的用戶電子郵件是註冊表單的典型功能,而重要的事情通常是通過限制每個IP的速率來防止暴力破解。您也不會涉及對UX的巨大打擊以及做出相同響應的危險(實際用戶受到的傷害要大於惡意行為者)
@davshowhan449用戶應在註冊時而非使用期間接受任何ToC
@Christoph“我會認真考慮是否要使用該服務”,這是一種奇怪的方式,寫著“我將刪除帳戶,再也不會返回”
對於帳戶註冊,如果在沒有電子郵件驗證的情況下無法訪問新帳戶,則可以避免洩露該信息。這些技術都不困難。只需確定帳戶存在是否足夠秘密就足以證明對UX的打擊。當然,即使發生故障,您也可以通過發送電子郵件來緩解UX問題(例如,密碼重置失敗時,您可以發送“找不到帳戶”電子郵件)。
在任何情況下,都應將電子郵件發送到規定的電子郵件地址。如果沒有與該地址關聯的帳戶,請讓該電子郵件帳戶的所有者知道曾經嘗試過密碼重置。如果第三方嘗試重設密碼,則他們知道有人在攻擊他們。如果他們忘記了用於註冊的電子郵件地址,他們將不再等待該電子郵件,或者認為您的系統已損壞,只需嘗試下一個地址即可。
@UTF-8您是說應該將電子郵件發送到該地址,而不管它是否已在系統中註冊?這似乎值得懷疑。我絕對不想從與我無關的某些服務中獲取電子郵件,因為有人將我的電子郵件地址插入了Web表單。
@DavidZ因此,讓我們檢查一下我們所有人使用的流行服務如何處理這種情況。Idk,也許是SE?因此,我只是將與我的StackExchange帳戶無關的電子郵件地址插入“我忘記了密碼”表單。我得到了什麼?一封電子郵件指出:“我們在Meta Stack Exchange上收到了[我的輔助電子郵件地址]的帳戶恢復請求,但該電子郵件在我們的記錄中不存在。”
@DavidMulder我關心的是每個IP的速率限制,因為它經常將合法的VPN用戶拒之門外,這對UX也造成了巨大打擊。
@Schwern一小部分用戶的狀態會稍差一些,但仍能正常運行的註冊表格(假設其編寫得很好)似乎不是一個“巨大的成功”(尤其是與備選方案相比:不連續的註冊過程,您會收到一封電子郵件以繼續註冊)。但是,是的,考慮VPN用戶絕對是值得的。
@DavidMulder除非您是被鎖定的VPN用戶,否則影響不大。我不知道您最近是否看過新聞,但我們將看到越來越多的人在家中使用VPN進行工作。:鬼臉:
Demento
2020-03-19 18:34:12 UTC
view on stackexchange narkive permalink

此發現的原因是,用戶會根據電子郵件地址的存在而獲得不同的響應。可以簡單地告訴他們地址未知,或者響應中有些微妙。

避免此類問題的最簡單實現是返回完全相同的響應,無論電子郵件地址是否存在。

簡單的密碼重置信息已發送至提供的電子郵件地址。如果沒有收到電子郵件,請檢查您是否提供了正確的地址。

可以解決這個問題。

如果您知道該電子郵件地址,發送密碼重置信息。如果不存在,則什麼也不做。真正的用戶將獲得鏈接,而攻擊者無法確定是否發送了電子郵件。

完全有意義。謝謝。為什麼我以前沒想到呢?
@davshowhan449-不用擔心,這是Web應用程序中非常常見的漏洞,很容易被忽略。壞消息是,此類問題實際上是在野外利用的,一旦發生,很難在短時間內緩解。因此,儘管乍一看它只是“一個信息披露”,但我還是建議及時修復它。
如果後面有頁面怎麼辦?例如條款和條件,通知,FYI,廣告,調查等,然後才實際發送電子郵件?這可能會影響用戶體驗。一個合法的用戶可以說,我經歷了所有這些,最後他們沒有告訴我我的電子郵件無效嗎?
@davshowhan449然後也刪除那些附加頁面。和良好的擺脫,因為這首先聽起來像是一個可怕的經歷。但這也許值得一個新的問題。
@davshowhan449我認為我從未在密碼重置頁面中看到過這一點。假定您已經是該服務的成員,則無需要求用戶同意T&C。在您回复通過電子郵件發送的鏈接之前,其他內容不會顯示。
@davshowhan449儘管仍然不是很好的用戶體驗,但是解決該工作流程的一種方法是在用戶單擊電子郵件中的鏈接之後將所有*“必要”頁面移動到。
Michael P
2020-03-19 19:15:52 UTC
view on stackexchange narkive permalink

除上述答案外(本該更適合作為註釋,但不能這樣做),黑客可以採取的另一步驟是測量您對錶單的響應時間。確定電子郵件不存在可能需要10毫秒,而生成重置鏈接並發送電子郵件可能需要100毫秒。黑客可以知道響應是否較慢,因此無法成功找到它。如果找不到電子郵件,則可以使用隨機睡眠計時器,以使兩個響應都花費相同的時間。

歡迎使用該網站,您的第一個+1!感謝您的加入。但是,有一個更簡單的解決方案。只需立即發送響應,而無需先檢查電子郵件。這樣,響應時間也與電子郵件地址的有效性無關。
@Demento從概念上來說很容易,但在技術上可能會很困難-許多基本的Web後端都不容易實現這種異步處理,因為默認情況下,它們將處理線程的生存期與HTTP響應綁定在一起。
@Bob是的,這有點困難,但也很容易處理。如果您有消息隊列,則可以使用該消息隊列,也可以使用帶有cron的可憐人/老套子運行,該cron每分鐘運行一次,以從待處理的重置提交數據庫中彈出項目。
如果您發送“無法重設密碼:找不到帳戶”電子郵件,此問題將消失。
Brian I贊成您,但請注意,您(沒有控制權)已使攻擊者A能夠使用您的服務向用戶S發送垃圾郵件。
這裡只是一個小提示-不要使用隨機睡眠,可以從統計上將其過濾掉。參見例如https://stackoverflow.com/questions/28395665/could-a-random-sleep-prevent-timing-attacks 計算得足夠長以使兩個響應都採取相同時間的延遲可能會有所幫助,但隨機情況不會。
如果您按照其他答案中的建議將相同的響應發送給所有人,則HTTP響應可能非常簡單,甚至是靜態HTML頁面或重定向。檢查和發送要么異步完成,要么在發送響應後您的框架不支持這種檢查和發送。那不是檢查,發送,響應,而是響應,檢查,發送。
David Mulder
2020-03-20 14:10:14 UTC
view on stackexchange narkive permalink

我們要防範的是什麼?

首先應該問一下他們到底要防範的是什麼。在這種情況下,存在兩種不同的威脅:

  • 威脅1 攻擊者蠻行強迫隨機電子郵件查找有效的已註冊電子郵件。從理論上講,這可以用於創建垃圾郵件列表,但據我所知,從未完成過,因為發送電子郵件比處理額外的麻煩要簡單得多(我收到垃圾郵件的時間聲稱我[銀行]帳戶,即使他們不在美國,也需要採取行動。)
  • 威脅2 攻擊者將特定用戶或特定用戶列表作為目標。當某人在某處註冊的基本事實可能產生後果時,這一點尤其重要。例如:在某些社區中,對Grindr或Ashley Madison進行帳戶註冊可能會很危險。其他地方可能會公開相同的信息,並從整體上考慮這些信息。通常,註冊表格會通知用戶輸入的電子郵件是否已經註冊,但是當然不適用於大多數B2B軟件。除了“與用戶共享”功能(可以在其中輸入電子郵件以與該用戶共享某些對象的輸入框)之外,該功能通常還會公開此信息,但是由於很少見,因此我不會在此答案中包括這些信息。 p>

    具有公共註冊的系統的解決方案

    首先要承認的是,從UX的角度來看,不通知用戶註冊過程中已經存在帳戶是不愉快的。這同樣適用於密碼重設形式,當用戶輸入錯誤或有多封電子郵件時,密碼重設形式在 1 sup>內自動失敗。這並不意味著這是不應該做的事情,而是應該權衡安全風險和利益。

    考慮到具有公開註冊的系統,需要考慮的重要事項是威脅2 對您的產品用戶有多大。即使風險很小,也可以謹慎地更改註冊表格,從僅輸入姓名和電子郵件開始,給出一條消息“檢查您的電子郵件以繼續註冊”,如果該電子郵件已被註冊,則向用戶發送電子郵件通知他們這個。同樣,在這種情況下,密碼重置表單將不會以任何方式通知用戶電子郵件是否有效。

    另一方面,如果 Threat 2 最小,我們必須專門針對 Threat 1 建立模型。當然,先前的方法也可以完全針對Threat 1發揮作用,但是考慮到UX成本,值得考慮其他解決方案。最明顯的解決方案是對“電子郵件存在檢查”和“密碼遺忘”檢查都進行速率限制 2 sup>(從技術上講,這些調用甚至可以轉到相同的API端點)。在最初的10個左右的通話中,通常會設計得比較寬鬆,但是在那之後很快就會變得非常有限。

    重要:切勿從密碼中刪除錯誤消息

    沒有公共註冊的系統的解決方案

    所有這些都歸結為與上述相同的問題(我應該首先寫這篇文章) ),但是沒有註冊UX的額外費用,忘記了安全密碼的形式相對來說“便宜”,儘管對於用戶來說 still 當然令人不快,您仍然可以考慮是否速率限制不足以適合您的特定威脅模型。

    注意事項

    1:明智的做法是至少發送一封電子郵件到輸入的電子郵件,通知他們未找到他們的電子郵件,而不是默默地失敗。這樣1)可以使攻擊者避免大規模濫用系統(這將引起注意),並且2)可以防止用戶懷疑為什麼他們沒有收到電子郵件。 sup>

    2:做請注意,速率限制可能會對大型網絡或VPN的用戶產生負面影響。始終考慮觀眾對您的重要性,並基於此花費足夠的時間以確保應用程序即使在速率限制最苛刻的情況下也能保持功能正常(例如,通過解決驗證碼降低速率限製或將最大速率限制設置為大約每分鐘一次,並確保應用程序將等待一整分鐘(請注意:鑑於在同一次會議開始時有一群用戶註冊了相同的服務,因此仍然令人不快)。 sup>

這樣還行嗎:“已經向您發送了一封電子郵件以繼續註冊,如果您已經註冊,則不會收到任何電子郵件。”這樣可以防止攻擊者為他發送已知的電子郵件地址的垃圾郵件。
@SAJW我認為您所描述的與我寫的內容相同,“即使有很小的風險,也可以謹慎地更改註冊表格,從僅輸入姓名和電子郵件開始,然後輸入一條消息”繼續註冊“”。但是,如果您有任何想法如何使其更清晰或更佳:請隨時進行編輯
啊沒關係。您的方式已經足夠了,因為如果攻擊者知道您的電子郵件,如果您沒有註冊,他可以向您發送垃圾郵件,因此我們的解決方案不會給我們帶來太大的好處。
@SAJW不知何故,我完全誤讀了您的評論,現在很清晰了。但是,是的,通常來說,無聲地失敗是非常危險的,因為用戶永遠不知道某個慢速郵件服務器或垃圾郵件過濾器是否捕獲了他的電子郵件,或者他實際上是否應該不接收電子郵件。
Džuris
2020-03-20 07:05:59 UTC
view on stackexchange narkive permalink

您應該權衡問題與解決方案的不便之處。

通常我認為這是一個折衷。

為了用戶體驗,通常最好犧牲此安全性,除非有人因在您的網站中註冊而受到迫害。

幾年後,我有時會不定期地訪問某個站點,並嘗試查找用於該特定站點的電子郵件。隱藏這些信息的網站很煩人。

對其他答案的補充。應該針對當前上下文評估每個安全功能,以決定其成本是否值得。答案並不總是“是”。
如果我不知道我使用的是哪封電子郵件,我通常會通過我的主要電子郵件地址搜索站點名稱,以查看我註冊的電子郵件地址。與Google功能結合使用時特別有用,它可以在您的電子郵件地址中添加+任何內容。
這不僅與迫害有關,而且與網絡釣魚有關。假設某人收到“密碼重置”郵件,而5分鐘後,他顯然從您的網站收到一封郵件,說“我們識別出您可能不是從您的帳戶登錄/購買的帳戶。請訪問www.thisisascam.com進行檢查您的帳戶是否被盜用”。許多人將登錄到詐騙網站,因為重置電子郵件為此郵件準備好了郵件,並且詐騙者知道該人在您的帳戶中擁有一個帳戶,因此,他可以採用不同於普通垃圾郵件的格式設置郵件。
-1
eckes
2020-03-21 09:42:52 UTC
view on stackexchange narkive permalink

請注意,這(除其他答案外)也適用於註冊屏幕,而不是抱怨已經註冊的用戶向他們發送了電子郵件,表明他們已經註冊,並且除了“檢查您的郵件”之外,在網絡應用中不提供任何反饋“。

如果您在電子郵件驗證之前的第一步要求輸入最少的信息(這對GDPR也是有好處的,那麼您可以證明用戶收到了您的信息電子郵件並繼續註冊),這是最好的選擇)。

實際上,註冊沒有麻煩,應該始終這樣做。對於重置密碼功能,我們在軟件中提供了一個選項,您可以在其中選擇直接反饋或電子郵件反饋。(在公司場景中,尤其是在Intranet上,猜測電子郵件並不是真正的威脅。)



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...