如何生成包含在URL中的25個字符串？它是完全隨機的，還是基於當前時間，還是基於用戶的電子郵件？它應該是隨機的並且不可猜測。

您應確保驗證頁實際呈現（不僅僅是發生了GET請求）。諸如chrome（和防病毒程序）之類的瀏覽器通常會加載URL，而無需用戶出於安全原因而明確地單擊它們以進行預取或掃描。

這可能導致惡意行為者（夏娃）想要使用他人的電子郵件（愛麗絲）創建帳戶的情況。夏娃簽約了，愛麗絲收到了一封電子郵件。愛麗絲打開電子郵件是因為她對自己未請求的帳戶感到好奇。她的瀏覽器（或防病毒軟件）在後台請求該URL，從而無意中激活了該帳戶。

我將在頁面​​上使用JavaScript來驗證實際呈現的頁面，並在電子郵件中包含一個鏈接，用戶可以在其中報告他們未創建此帳戶。

添加到Daisetsu的答案中（因為我還不能寫評論）。

創建表單並要求用戶創建密碼也不錯。這樣，用戶將需要輸入新密碼，並在提交新密碼後激活帳戶。它將解決後台防病毒檢查。

對於URL，只要是隨機字符串，就應該足夠。您一次擁有兩個相同內容的鍵的可能性很小。

檢查IP地址不是很好，因為某些ISP可能會輪換IP地址，因此您將阻止想要註冊但不能註冊的人。

您的電子郵件應包含激活碼，而不是鏈接。您不應在電子郵件中發送用於帳戶管理的任何鏈接。如果您（合法方）將電子郵件鏈接（尤其是帶有長字符串的隨機字符）鏈接到用戶，則將區分合法電子郵件與網絡釣魚嘗試變得更加困難。

激活碼應包含以下內容：可以輕鬆複製和粘貼的字符（無空格，“ +”，“-”等），也易於手動輸入。字母和數字有效。激活碼的安全性取決於它的不可預測性。就像使用cookie的會話ID一樣，您可以使用系統的安全隨機數生成器來推導該值。

激活碼應存儲在數據庫表中，每一行都有一個配置文件ID，即激活代碼 ^{* sup>，以及到期時間。您不想將配置文件ID或有效期放在cookie，URL或激活碼中。 ** sup>惡意用戶可能篡改該ID來接管另一個帳戶。您需要在服務器端進行驗證，因為您的安全策略不能盲目地信任客戶端數據。}

激活代碼應通過POST請求提交。完成其餘註冊後，自動將用戶重定向到帳戶激活URL（可以是 https://example.com/security/activate ）。如果他們不小心關閉了帳戶激活頁面，可以輕鬆再次訪問該頁面。

您不希望GET請求執行任何操作。如果沒有用戶交互（由於瀏覽器預取或電子郵件安全服務），鏈接可能會被訪問。此外，在URL中放置機密可能會洩漏敏感數據。 （通過引薦標頭或瀏覽器插件。）

不用擔心IP，它仍然可能會更改。 （與用戶代理相同。）

我不知道是否需要取消功能。我什至不使用未經請求的電子郵件中的取消訂閱鏈接，因為這可能是確定是否有人與電子郵件地址相關聯的一種方法。如果激活碼足夠長，可以抵抗暴力破解，或者如果您限制激活碼的嘗試次數，那麼僅讓激活碼最終失效，我看不出有什麼害處。

另一方面可以減少不需要的帳戶激活電子郵件的數量。您可以禮貌地限制發送到某個地址的電子郵件數量。每天最多說3個，每月最多說5個。 （我不知道那是太高還是太低。）作為非用戶，我只是將您網站的電子郵件自動刪除或自動標記為已讀。

有很多不需要的激活電子郵件時要考慮的變量。最有可能與用戶體驗有關的不僅僅是安全性。您可以提供“取消我的激活，並且從不發送電子郵件到該地址，因為我永遠都不會註冊”功能，但是這樣做存在明顯的問題。 （您仍然需要驗證此人的電子郵件。）

_{*散列激活碼也沒有什麼壞處。像密碼一樣，散列也並不重要，因為每個代碼都只能使用一次，不包含任何私人信息，由服務器隨機生成並過期。 sub>}

_{**您實際上可以防止使用加密MAC進行篡改，但是我強烈不建議大多數開發人員嘗試這樣做。密碼學很難正確解決。 sub>}

對於使用安全實踐的任何事物，暴露和威脅評估都是您必須針對自己獨特的環境和用例進行評估的內容。現有的答案為該評估提供了很多接觸點，以及避免發生問題的指針-例如 GET 觸發的動作。相反，我將更多地關注UX的“用戶”部分。我還將觸及頁面上散佈的許多評論。

使用電子郵件觸發的操作“驗證”的確切原因也是要考慮的因素。如果您只是確認這是一個有效的電子郵件地址，那麼幾乎所有的操作就足夠了。驗證電子郵件，創建帳戶的意圖以及接收電子郵件的用戶是發起帳戶創建的用戶，需要付出更多的努力。

您應該不要必須採取的是發送提醒電子郵件。假設用戶有意創建了該帳戶，使用了一個有效的電子郵件地址，並希望將該帳戶用於提供帳戶的任何目的，那麼他們將尋找電子郵件，並會盡快進行激活過程。如果鏈接，代碼或任何其他內容在等待電子郵件時因其他事項而陷入歧途，則在使用它們之前可能會過期。在這種情況下，允許他們重新發送驗證電子郵件即可。但是，提醒電子郵件很可能是垃圾郵件觸發手段，而不是給用戶帶來好處。

作為用戶，我很高興有可用的選項來激活/驗證我的帳戶。我遇到的最常見的選項集是，該電子郵件提供一個鏈接，我可以單擊或剪切&粘貼，和，然後可以在我的頁面中的表單字段中輸入確認代碼網站上的“帳戶設置”區域。確認碼很少是，除了5到9位數長的整數外。

作為用戶，給我最自信的驗證電子郵件是那些在URL中具有加密外觀的哈希的電子郵件（ / verify？l = lgGS2SBjMTU4NjkwNjYxMjI5MDBhZDk2YjEyMzMzYzNjNhZmQxOb ），這使我對對我來說唯一的頁面，然後我必須輸入用於創建帳戶的密碼。使用哈希可以確認鏈接是在電子郵件中收到的，沒有被猜測或強行使用，因此可以驗證電子郵件是否有效。在執行任何其他操作之前，該唯一頁面的提供允許服務器將發送給它的電子郵件標記為“有效”，而無需確認帳戶的創建。與某些防病毒，惡意軟件檢測或預取操作相反，輸入密碼可確認另一端有演員。密碼的有效性在一定程度上確定了電子郵件的收件人和帳戶的創建者是同一個人。

建議的30分鐘時限確實有點嚴重，而如果威脅評估表明24小時內的暴露是不可接受的，則24小時可能會太大。我認為2個小時對幾乎所有用戶的環境都足夠。如果重新發送驗證的功能可用，則尤其如此。即使使用與遠程POP帳戶建立14 kb / s連接的移動設備，也應該能夠在120分鐘內完成交換。

使用JS來以某種方式驗證人為行為可能會出現問題。 JS可以關閉，並且比許多Web開發人員想知道的更多。其次，即使在瀏覽器中啟用了JS，廣告攔截器 仍可以基於每個站點或每個源來阻止JS。我在全球範圍內阻止了許多JS來源，包括Google的分析腳本，並為一些網站（例如Stack Exchange）添加了白名單，在這些地方我願意使用我的數據來支持它們。

在電子郵件中或確認頁面上包含“取消”帳戶的鏈接是浪費。在電子郵件中，它實際上適得其反，因為建議您單擊有關您不想要的帳戶的鏈接是一個好主意。相反，電子郵件中應包含文字說明，表示無所事事將導致帳戶無法確認，甚至可能被刪除。確認頁面上的取消鏈接甚至更糟，因為它獎勵不良行為。作為舊版Google snafu的一部分，我經常收到指向另一個Gmail帳戶的電子郵件，並且我認為相反的情況也適用於其他帳戶。 [[過去Google不會合併點綴和未點綴的用戶名，因此我的點綴用戶名和其他人的未點綴版本是不同的帳戶，但是Google偶爾會滑倒，反正我會收到他們的電子郵件:(]

您將“經過驗證”的電子郵件地址與激活鏈接緊密結合的程度取決於您的用例和威脅評估，當我在更改關聯的電子郵件地址後必須重新驗證我的帳戶時，我會感到有些煩惱。我對流程的接受程度與帳戶的“價值”成正比。對於我的銀行帳戶，PayPal等，我100％接受。但是在PcPartsPicker上，我大約接受該帳戶的15％

對於IP和/或用戶代理，請忽略它們。在這種情況下，我經常會查看站點並選擇使用移動設備創建帳戶。 strong>不是，但是可以打開電子郵件。如果我創建了一個帳戶，並得知需要以某種方式進行驗證或確認，並且電子郵件是提供的方法，我會等到我回家後，再在桌面上打開電子郵件，以便在其中檢查它。 IP和用戶代理將因此非常不同。但是，我的密碼將保持不變，並且足以驗證我作為原始帳戶創建者的身份。

請記住，電子郵件與時代廣場的Jumbo-tron一樣安全，並且相應地進行。

驗證電子郵件只需要幾件事即可，因為它們相當安全且易於使用：

1. 用戶必須清楚發生了什麼事。被解釋為什麼會收到此電子郵件（例如“ ...某人在我們的網站上註冊了BLAH帳戶，以確認...” ）排除了大多數愚蠢的錯誤，並可以合理地阻止釣魚郵件。希望您知道您是否剛剛在某項服務中註冊了帳戶（除非您完全癡呆了）。因此，收到一封說明了這一點的電子郵件就不足為奇了。另一方面，這樣的一封電子郵件知道您沒有在任何地方註冊（應該，希望）足夠可疑。如果不是這樣，並且用戶單擊通過電子郵件發送的任何隨機鏈接，則無論如何您將無能為力，也不知道您不認識的人可能會或可能不會收到哪些郵件。
2. 將相當長的隨機（非順序！）令牌（足夠長以確保它不可猜測且不會衝突）傳遞回服務器。該令牌也存儲在數據庫中以進行比較。它到底有多長以及具有什麼特定格式都沒有關係。它不需要人類可讀。任何大於20個左右的字符（假設使用base64編碼）都可以使用，但是我會使用40個字符來確定，因為它實際上並不會花費您任何費用。 240位偽隨機字符串幾乎可以保證是唯一且不可猜測的。為了方便起見，我實際上將其設置為鏈接，而鏈接可以確實是一個 GET 請求。是的，用戶不應該單擊鏈接，但是他們還是會這麼做（您不會對其進行教育！）。另一方面，與必須複製粘貼一些晦澀的字符串相比，用戶體驗要好得多。
3. 帶有“單擊以確認”按鈕的HTML表單，該按鈕重新對數據進行 POST ，這可以確保URL的推測性加載不會使事情發生（無意甚至惡意）擁有該郵件地址的用戶不知道。該表格應顯示合理數量的信息，以便用戶知道發生了什麼，並作為最後一次觸發“ WTF？”的機會。如果用戶沒有註冊該帳戶。
   如果您擔心使用機器人，則可以在表單中添加“我不是機器人”（個人，我認為多餘，但是您的里程可能會有所不同。）
4. 合理的到期日期（或時間）。什麼合理沒有人能給出一個明確的普遍答案。我說從4個小時到兩天的時間可能都不錯。通常，當您註冊某件東西時，會在5到10秒鐘內收到確認郵件，然後坐在計算機前等待確認。如果您使用的是典型的偏執狂模式公司郵件，則可能會更長一些，這種公司郵件需要花費幾分鐘來掃描每一封外部電子郵件。不過，您可能會打個電話，或者必須去中間的某個地方，因此讓令牌有效期為幾個小時或一天肯定不是錯誤的。同樣，郵件 可能會被延遲（很少見，但確實會發生）。另一方面，通過保留確認令牌（並阻止帳戶名稱！）數週來浪費磁盤空間是沒有意義的。 ，幾個月或幾年。這不僅浪費資源，而且一兩天之內沒有確認的人可能永遠也不會。或者，他們可以重新註冊一次。真的，什麼都不花錢。
ol>

根據您的問題，我假設以下假設，如果其中任何一個無效，我的答案也是如此：

1. 用戶在您的網頁上註冊並在此期間設置用戶名/電子郵件和密碼註冊
2. 電子郵件驗證的目的是確保用戶已使用正確的電子郵件地址進行了註冊。
3. 激活帳戶是唯一的目的，郵件鏈接呢。它不允許密碼重置或其他類似功能。基本上，它執行“ UPDATE用戶SET已激活= True WHERE令牌=％1”
ol>

在這種情況下，從安全角度來看，您的方法絕對正確。 25個字符可為您提供足夠的保證，以防止隨機碰撞和強力嘗試，一次性使用可防止嗅探和類似攻擊，而且無論如何，某人唯一能做的就是激活帳戶。

您可能想要如果出於性能原因有很多用戶，請包含用戶ID。（更新：不是真的，請參見下面的註釋）通過字符串標記查找用戶將導致表掃描，而通過ID，然後僅獲取和比較字符串就是索引查找。但是，這確實會公開用戶ID，您可能會或可能不想這樣做。