對於我們開發的許多網站，我們驗證用戶的電子郵件地址。典型地，所述工作流程是這樣的：從電子郵件中自動登錄用戶是不是一個好主意？
客戶經常抱怨這個過程很笨重，有點混亂，我同意。所提出的解決方案是在第2步
後，我不知道這是否重要刪除步驟3中，並自動記錄用戶（因此問題！），但我一直的自動登錄用戶警惕喜歡這個。在實施建議的解決方案之前，我應該考慮哪些額外的安全風
這也適用於像密碼重置，用戶可以自動登錄，然後做出更改其密碼的情況。
對於這個問題起見，我們假設驗證電子郵件是一個硬性要求。我知道有些情況下這不是必要的，但讓我們來談談那些地方。
我會確保有在電子郵件中的鏈接的區分有效性的時間限制，使其僅適用於點擊。
這取決於您的應用程序。如果你經營的是銀行網站，你永遠不會這麼做。如果您正在運行Flickr，Facebook或其他各種社交網站，則可以這樣做。
你可能要考慮的是提供輔助功能僅限於其他的事情。我知道亞馬遜在他們網站的某些部分做這件事。用戶可以瀏覽該網站，就好像他們已經登錄一樣，但僅限於某一點。在他們可以做任何與採購和訂單相關的事情之前，他們必須提供他們的密碼。
編輯：另外一個問題，這只是發生在我身上。確保您可以使網址無效。在數據庫中生成令牌並將其放入電子郵件中，然後有辦法撤銷這些令牌。一種方法是在您的所有用戶記錄中添加一個計數器，然後在生成電子郵件時將該計數器值複製到令牌表中。如果您需要快速撤銷大量令牌，您可以簡單地增加用戶記錄中的計數器。然後您可以很容易地看到令牌的計數器與用戶計數器不匹配，因此您可以拒絕該令牌。
有關代幣的不錯之一。這可能沒有必要，但如果你事先想到它很容易建立:) – extraneon 2010-08-27 17:24:49
是的，我們把它建成了我們的認證系統。當用戶更改其密碼時，會增加其「打勾」併爲該客戶端分配新的令牌。當前從其他位置登錄到該帳戶的任何客戶端都會立即註銷並要求重新進行身份驗證。並且不需要擔心涉及多少令牌，因爲只有一個數據庫行實際需要更改（而不是刪除可能是任意數字的所有相關令牌）。 – 2010-08-27 17:31:08
我不確定我是否理解此刻度/反想法。是不是隻是'刪除user_tokens WHERE user_id IN（/*...*/）'與'更新用戶SET計數器=計數器+ 1 WHERE user_id IN（/*...*/）'？後者的優點是什麼？ – notJim 2010-08-27 17:42:57
在最低限度，
我會自動登錄的用戶，當且僅當他們點擊一個複選框「在此計算機上記住我」在步驟1
沒有什麼錯誤使用一個電子郵件地址作爲用戶標識符。它告訴你正在進行註冊的人可以在該特定時間訪問該電子郵件地址。但我確實認爲鏈接應該到期，如果鏈接到期，請從數據庫中提取該電子郵件地址（因爲它可能是某人的電子郵件）。
與E-mail是不是安全的，也不是非常個人化的（有一些在網絡上免費的臨時電子郵件網站），你真的不能使用電子郵件的情況下的信任是非常重要的。但對於一個簡單的網站，你想要某種帳戶，我不認爲這是一個問題。
要在2點你opninion，在我看來，如果你沒有第2步，你也不必執行步驟1和3
打擾如果不讓用戶驗證電子郵件地址，你甚至不應該問它。你不會有任何線索，這是一個真實的地址，對應於試圖創建賬戶的人。
如果你沒有一個電子郵件地址，也沒有辦法一個可以給用戶一個新的密碼，因爲你不知道在哪裏把它發送到。輸入的電子郵件地址可能屬於其他人，他們甚至不想在您的網站上擁有帳戶。
如果您無法重置通過E-mail地址（可靠）的密碼，你不應該記錄在所有的麻煩。去一個無帳戶的網站。
這是假設你不使用呼叫中心或服務檯覈實賬目，以及處理過程中的密碼重置。
像這樣的系統與用戶的電子郵件一樣安全。
當然，電子郵件通常在飛行和休息時缺乏加密。電子郵件帳戶通常可從無人值守的工作站和移動設備訪問。很多電子郵件永遠不會被刪除。
因爲電子郵件妥協的機會，隨着時間的推移而增加，時間限制是一個好主意。
但是，你應該假設有足夠的動力，攻擊者可以看到在途郵件。攻擊者的動機將取決於所涉及的應用程序，因此這是否是一個好主意......依靠。
如何使用OpenID？ – NullUserException 2010-08-27 17:24:15
只要有可能，我們允許用戶使用其他提供商（OAuth/OpenID），但對於我們典型的受衆（非技術人員），我們並不需要它。我們還發現，由於隱私問題，我們的用戶謹慎以這種方式將他們的帳戶鏈接在一起。 – notJim 2010-08-27 17:38:36