Jay

2015-11-10 20:03:06 UTC

view on stackexchange narkive permalink

可以說攻擊者擁有您的密碼。您登錄並重置它。如果重置並沒有使所有現有會話無效，那麼只要攻擊者不讓其會話過期，攻擊者仍然可以訪問。

在這種情況下，重置實際上沒有任何作用。

根據網站的工作情況，使用現在過期的密碼登錄也可能會出現問題。假設您的密碼用於解鎖某些東西，您使用“ password1”登錄，但是服務器現在將密碼另存為“ password2”，會發生什麼？這顯然是假設的，但希望可以說明這一點。

我想重定向到登錄屏幕只是一個建議。我不確定將用戶發送到哪裡很重要，但是從可用性的角度來看，將用戶發送到登錄頁面而不是首頁更有意義。

我想將它們發送回登錄屏幕的原因是實際上使用戶清楚他/她必須再次登錄。

為什麼要將用戶發送到登錄屏幕，而不是通過登錄屏幕發送用戶並再次實際登錄？我理解使現有會話無效的建議，聽起來很明智，但是*“我兩次輸入了複雜的新密碼，而您仍然不知道我是誰，並且您立即希望我再次輸入它” *是非常令人沮喪的用戶體驗。

@TessellatingHeckler兩因素身份驗證？編程更簡單？總有一天，密碼會消失了，我們再也不會遇到這種問題。

@nocomprende可能是相同的“更簡單的編程”，它會在密碼重置序列中引起較早的模式，在該序列中，您嘗試無休止地登錄，放棄嘗試記住，單擊以重置密碼，並顯示“輸入用戶名”的形式或電子郵件地址”，然後想想*“您好？我剛剛提交了我的用戶名*十幾次，您難道無法在一次頁面更改中跟踪它嗎？” *。

使所有活動會話均無效也可以確保，如果攻擊者是更改密碼的人（如果他以某種方式獲得了您當前的密碼），則合法用戶將意識到這一事實。但這仍然不需要更改一個會話的密碼。當然，它確實有助於劫持會話。

您在第一段中寫的內容以及您的第一要點（...使**所有現有會話無效）不是OWASP備忘單（**該會話**應該無效）中寫的內容。

用戶登錄的事實不會使現有會話無效。

嗯，我錯過了最後一句話...實際上，它阻止了使用您之前使用的密碼/會話登錄的人使用您的帳戶。

正如我之前評論的那樣，您列出的所有這些內容都可以輕鬆完成，而無需進入登錄頁面。因此，刪除所有無法回答問題的內容，可以歸結為您的最後一段：“不知道，我想這是對可用性的建議。”您確定找不到與安全性相關的任何原因嗎？或至少詳細說明了為什麼具有良好的可用性？

-1這根本無法回答問題！請參閱@TessellatingHeckler's註釋。（抱歉，我無法與自己的代表-1）。

@TomášZato我認為他的意思更像是“密碼重置*所有*會話終止後，因此強制進行新的登錄，並因此重定向到登錄頁面”，而不是暗示再次登錄會神奇地執行alter-session終止。至少這是我編寫的系統處理pw reset的方式-reset操作的最後一步是終止該用戶的所有當前會話，因此除了重定向到登錄頁面外，別無他法。

SilverlightFox

2015-11-10 20:16:02 UTC

view on stackexchange narkive permalink

在可能受到威脅的帳戶上保護會話

如果安全地更改了密碼後的會話管理，則無需實際重定向到登錄頁面。也就是說，只要所有當前會話標識符都無效並且當前會話附加到新的會話標識符（通常作為身份驗證cookie中的令牌發布-cookie僅發送到剛剛更改了密碼的會話），就可以不會威脅已經在帳戶中的攻擊者保持登錄狀態。

OWASP文章

下面解釋了OWASP文章的基本原理。它的安全性沒有問題，但是存在一些可用性問題。

當用戶希望保護其帳戶安全時，經常使用密碼重置功能。

通過使所有密碼無效密碼重置後，如果現有會話已存在，則係統將確保只有擁有新密碼的人才能登錄。

例如，攻擊者使用舊密碼登錄了該帳戶，重置所有會話將註銷攻擊者。

為什麼我要註銷當前用戶，我聽到你問？

好說攻擊者正在使用當前用戶的會話，例如使用會話修復漏洞。這意味著攻擊者與真實用戶具有相同的會話。重置當前會話還可以確保該帳戶上沒有任何人沒有訪問權限。

重定向到上面引用中的登錄頁面實際上是在描述您應該註銷用戶的事實。當前會話和所有會話（但不存在阻止您將它們放入具有新標識符的新會話中的風險）。

如何使當前會話無效並將其置於新會話中，必須將用戶引導到登錄頁面？

我認為只要當前會話和所有其他會話都無效，它就不會起作用。為當前客戶端創建一個具有新會話令牌值的新會話將滿足上述安全要求，並將征服繞過該會話或獲得先前密碼的攻擊者。

因為如果您剛剛註銷它們，他們將要重新登錄！

John Biddle

2015-11-11 00:28:52 UTC

view on stackexchange narkive permalink

從netsec的角度來看，其他答案可能更正確，但是我想補充一點，您還可以確保用戶實際上能夠使用其新密碼登錄。如果出現問題（例如瀏覽器自動填充舊密碼），這將很明顯。

它還可以防止用戶使用密碼重置作為登錄名。在我的一個帳戶上，回答安全問題比記住密碼更容易，因為每次重置密碼時我都必須設置一個唯一密碼，並且忘記了密碼。

是的，“ OhNoSecond”是您認識到的一次很棒的信息，它使您意識到自己在重置密碼時輸入了錯誤的密碼，現在卻不知道密碼是什麼。就像看鎖著的汽車一樣，看看駕駛員座位上的鑰匙。

@nocomprende但是，如果僅車門具有基於電子郵件的重置

我不知道如何將鑰匙鎖在車上。您需要鑰匙來鎖定它！

@Alex簡單。鎖上門，將鑰匙放在車上，然後關上門。人們一直在這樣做。還是您的車上有什麼特別的東西可以防止這種情況？

+1這實際上回答了問題（與另外兩個被否決的答案不同）。

很好-感到不便，但實際上再次確認了用戶意圖

Deduplicator

2015-11-11 10:26:31 UTC

view on stackexchange narkive permalink

只有一種與安全性相關的原因可以將您發送到登錄頁面，因為所有舊會話都可以失效，並且您當前的活動會話已將密碼更改為自動替換： >它使使用密碼重置進行登錄更加麻煩，從而使您使用它的頻率降低，從而更安全地防止它被竊聽和意外洩露。

還有一個可用性原因 for 發送給您：確保您可以實際使用新密碼，並且瀏覽器中的所有密碼緩存都將得到更新。

@Calimo接受的答案實際上並沒有給出重定向到登錄頁面的理由；從程序員的角度來看，它給出了一個理由做一些相關的事情，但是對於用戶來說似乎是完全不同的。

supercat

2015-11-11 22:52:31 UTC

view on stackexchange narkive permalink

如果允許用戶使用瀏覽器存儲密碼，則將用戶重定向到登錄頁面將使瀏覽器可以在該頁面捕獲新密碼。否則，下一次用戶登錄瀏覽器時，將使用舊密碼“有效地”預填充密碼字段-如果用戶不了解正在發生的情況，此操作可能會引起混亂。

Sarmad Ajmal

2015-11-11 18:13:20 UTC

view on stackexchange narkive permalink

如果我們繼續關注安全對策，這非常簡單。實際上，這將使您所有活動的會話以及造成麻煩的竊取設備失效。

而且這不能以更加用戶友好的方式完成嗎？我看不到，需要重新登錄的部分在哪裡？

Erroneous

2015-11-13 01:49:06 UTC

view on stackexchange narkive permalink

除了提供一種用於建立新的有效會話的簡便機制，驗證新密碼是否有效以及註銷當前會話外，還具有使用戶第三次輸入密碼的額外好處，從而使操作更加輕鬆要記住。

Bill

2015-11-13 21:28:21 UTC

view on stackexchange narkive permalink

除了此處提到的許多其他要點外，從可維護性/強化/審計的角度來看，將會話創建機制限制為僅一個入口點是有益的。

用戶在即使在跳過任何具有身份證明箍的恢復證明之後，鎖定狀態也不一定要視為已登錄用戶，否則在進行審核/筆測試時還需要測試其他順序。

hamish

2019-08-11 12:34:30 UTC

view on stackexchange narkive permalink

重置密碼後立即再次登錄

a），您比三天后更容易記住3秒鐘的密碼。

b），然後您的瀏覽器可以詢問用戶是否要使用新密碼更新保存的密碼，然後瀏覽器會在登錄頁面上記住該密碼。