對於較小的站點，您不想允許黑客枚舉您的用戶列表，但是對於Google，該站點如此之大，可以假設幾乎每個人都有一個或多個帳戶。因此，在普遍存在的閾值之後，將風險最小化。

對於大多數站點來說，不公開用戶名是否存在仍然是一個好主意，但是需要權衡新用戶註冊過程的風險。您要防止的是一個自動過程來枚舉您的列表。新的用戶註冊過程應包括某種形式的延遲或限制，以使腳本無法快速嘗試使用用戶詞典。這通常是通過發送包含註冊過程不成功的電子郵件來實現的。是的，仍然可以枚舉，但是有一個延遲和一個額外的步驟。

要考慮的另一件事是公共站點和私有站點之間的區別。 Google是一項公共服務，用戶名也是公共的（在帳戶發送的每封電子郵件中均已公開）。另一方面，內部公司站點是只有私人才能訪問的內部公司站點，是私有的，並且需要更嚴格的控制以防止枚舉。

傑夫·阿特伍德（Jeff Atwood）在登錄“話語”時，對此話題說了：

這是長時間討論的源頭。討論，當用戶以“忘記密碼”的形式輸入電子郵件地址時，是否有必要向用戶透露該電子郵件地址是否存檔。在許多網站上，以忘記密碼的形式輸入電子郵件地址後，您會看到以下消息：

如果帳戶與name@example.com相匹配，您應該會收到一封電子郵件，其中包含有關如何盡快重置密碼的說明。

請注意此處的“ if”，這是一個對沖工具，它可以顯示出給定電子郵件地址是否存在於所有安全隱患上。網站，只需將其輸入“忘記密碼”表單即可。

我們對選擇Discourse的安全默認設置非常重視，因此開箱即用不會受到利用，濫用或濫用垃圾郵件發送者。但是在經歷了現實世界之後，“我們又在這裡使用了哪封電子郵件？”我們自己在數十個Discourse實例上的登錄狀態，我們意識到，在這種特定情況下，用戶友好比安全更重要。

對於Gmail，您只需通過將電子郵件發送到 @ gmail.com 地址即可確定帳戶是否存在。如果該郵件退回，則說明該帳戶不存在。

許多電子郵件提供商都是如此。在此，用戶名不被視為秘密。如果用戶的電子郵件地址為 foo@example.com ，則每個人都知道 foo 在 example.com 上具有用戶名 foo的帳戶@ example.com 。

但是，對於大多數其他系統來說，洩露用戶名是違反隱私的行為。如果有人發現 bob@example.com 在 nostringsattacheddating.example.org 上有一個帳戶，則Bob的妻子愛麗絲可以嘗試使用用戶名 bob @ example註冊。 com 並告訴他們用戶名已被使用，則這是對隱私的嚴重侵犯。

請記住，電子郵件地址的根源是電子郵件提供商。如果已知 eve@example.com 在 example.com 擁有帳戶，則不會丟失任何隱私，因為誰是 eve @的參考點example.com 是。對於另一個使用電子郵件作為用戶名的系統，情況並非如此-非電子郵件網站上用戶名 mallory@example.com 的用戶將是相同的 mallory@example.com 在其他網站上註冊。有隱私權可以保護Mallory擁有哪些帳戶。

此外，洩露用戶名對攻擊者也很有用。這稱為用戶名枚舉漏洞。 如果攻擊者知道存在哪些用戶名，則他們可以進行密碼猜測攻擊。

作為攻擊者，如果我可以使用您的登錄名或忘記密碼的頁面來縮小我的用戶名，我會列出10000個目標到1000個目標。

它還允許攻擊者通過網絡釣魚將系統用戶作為目標。

很容易設計出無法執行用戶枚舉的系統。例如，註冊過程和忘記密碼的過程是相同的。

步驟是：

1. 系統一次詢問用戶名（電子郵件）頁面，沒有其他輸入字段。
2. 提交表單後，系統會要求用戶檢查其電子郵件帳戶。
3. 如果該帳戶存在，則電子郵件包含密碼重置鏈接。
4. 如果該帳戶不存在，則電子郵件中包含註冊鏈接。
ol>

作為獎勵，您在註冊時已驗證其電子郵件地址以防他們以後需要重設密碼。任何錯字都將意味著用戶根本無法註冊-這很不錯，因為用戶不會意外使用註冊到其他電子郵件地址的帳戶。

密碼和註冊鏈接均包含密碼安全的隨機ID，因此在未收到電子郵件的情況下無法遵循它們。只有擁有該帳戶訪問權限的人才能知道用戶名是否已註冊（Bob最好對Alice保密，以免他的電子郵件和筆記本電腦密碼-如果在Alice嘗試嘗試此過程的情況下，最好關閉任何通知聲音，對於他來說，最好將其關閉也是在同一房間）。

請參閱我的其他一些相關主題的答案：

• 如何防止在表單中發現電子郵件？
• 在您的註冊表中使用“不再可用的電子郵件”功能是否安全？
• 電子郵件驗證後應加上密碼基於登錄？為什麼？
• 忘記密碼的最佳實踐，可以洩露給定的電子郵件無效
• 是嗎可以在註冊Web應用程序期間為用戶生成密碼？

我敢肯定，這條規則是在“大鐵”時代發展起來的，當時所有帳戶都在大型公司或政府系統中。由於系統分發了帳戶名，因此使用註冊頁面查找帳戶名不是問題。因此，保留帳戶名稱列表對&是可行的。

現在，我們正在處理自註冊網站，因此無法對帳戶列表保密。另外，無論如何，如今有這麼多人公開其帳戶名稱。在這種情況下，試圖隱藏事實是名稱失敗而不是密碼是沒有意義的。

知道哪個用戶名不存在並不重要，因為攻擊者還可以從註冊頁面檢查它。 Google不允許攻擊者進行暴力破解之類的攻擊來獲取用戶名列表。

首先提示輸入用戶名然後提示輸入密碼的原因更為重要：它允許Google為使用無密碼驗證或其他實驗性登錄機制的帳戶提供不同的用戶界面，而無需事先透露帳戶正在使用它。

類似於在輸入密碼後才顯示Google的2Factor身份驗證用戶界面的方式：攻擊者甚至在破解第一個因素後才知道涉及第二個因素。

結合其他有關用戶名洩漏的相對無風險的答案，在我看來，這實際上是一種安全改進。

電子郵件地址與用戶名不同。用戶名是（可能是）半私人信息，但是電子郵件地址是可公開公開和可公開路由的。想一想郵政郵件，如果經常知道它的郵寄地址，但是儘管通常也可以通過多種方式在網上查找，但當前的有效收件人列表不一定要設計成公開的。對於Google之類的公司，他們擁有Google +，YouTube，Google網上論壇等，這些地址已經使許多人熟知。

查詢電子郵件服務器並確定是否給定的電子郵件也很簡單。地址存在，使用telnet或許多網站都會為您完成。保護以其他方式可以輕鬆訪問的信息幾乎無濟於事。這就是為什麼某些站點將用戶名的電子郵件地址分開的原因。對於電子郵件提供商，給普通用戶使用不同的登錄名和電子郵件地址實際上沒有任何意義（也許我們當中那些對安全性更偏執的人會喜歡該功能）。

切換到兩步登錄可減少將用戶密碼輸入搜索字段或用戶名字段的可能性。這些字段通常被記錄下來，並且日誌在各地都具有關聯性，因此不太可能得到保護。因此，如果日誌受到黑客或國家/地區的攻擊，則攻擊者可能能夠將用戶的IP地址與其用戶名相關聯，然後注意到類似“ m7p @ 55w0rd !!!！”的內容。

在風險管理方面，密碼暴露的風險遠大於用戶名枚舉的風險。 Google可能具有更強大的反欺詐和異常跟踪功能，以應對與已知用戶名相關的風險。

我認為， FAIR簡介（pdf）中的Tire Swing示例是理解這一點的一種好方法。已知用戶名的風險計算會受到其他控件和因素的影響。您是否停止暴力攻擊，需要多因素身份驗證，還如何獲得此信息？在這種情況下，實際上，您可以在您可以控制的風險（監視所有登錄名）與舊表格中難以控制的風險（用戶將密碼鍵入錯誤的區域）之間權衡取捨。

我要大步走出去，說他們可能有一些機制可以確保它不是開放的用戶存儲庫。

我們在上實現了類似的系統我們的小網站使用支持redis的解決方案。

最初會向用戶顯示一個簡單的電子郵件/密碼，並帶有用於登錄和註冊的按鈕。輸入他們的電子郵件並繼續前進時，將檢查是否存在匹配項，如果匹配，則將刪除註冊按鈕。如果沒有，則將提供完整的註冊表。

在給定閾值之後，我們跟踪ip子網和黑名單的嘗試次數。黑名單不會影響他們使用該網站的能力，它只是恢復為登錄/註冊選項的標準行為。 >

是的，他們已經建立了防止濫用的系統。 Google擁有廣泛的“異常檢測”機制，可在您的活動可疑時提供錯誤或驗證碼：最著名的例子是Google搜索和NoCaptcha ReCaptcha的阻止。

您允許em>知道該帳戶是否存在並不意味著每個人都可以，也不意味著您可以實際猜測其他人的用戶名。嘗試讓我們知道您被阻止多久之前，這是一個有趣的測試。

幾乎每個人都已經已經這樣做了

我注意到，新的gmail登錄名先詢問用戶名，然後再確認該用戶名是否存在，然後再詢問密碼輸入。

Google已經具有此功能。當您嘗試註冊新的Google帳戶時，它必須檢查用戶名是否已經存在。

這是否違反傳統的安全原則，即不洩露有關用戶名是否存在的信息，以阻止嘗試許多可能的用戶名的攻擊類別？

如果他們沒有檢查，您將如何正確認證？多個具有相同用戶名的人對網站的完整性不利。當然，在許多情況下，您可以使用唯一的電子郵件地址，並允許多個人使用相同的姓名。

就像我之前說過的那樣，幾乎每個人都已經以某種方式做到了這一點。這裡沒有什麼可擔心的。如果您想降低用戶名的大量枚舉，只需在幾次嘗試後添加一個驗證碼即可。

Captchas並不能真正阻止大量郵件發送的騙局

垃圾郵件發送者經常向電子郵件地址發送大量垃圾郵件。儘管Google可能會將電子郵件推送到垃圾郵件文件夾中，但這並不能阻止通過非退回電子郵件進行枚舉。

創建一個使用數千個不同IP地址的群發郵件程序，然後嘗試通過不接收退回郵件進行枚舉是很簡單的。您甚至可以發送隨機垃圾。請記住，如果您的目標是驗證電子郵件地址是否存在，那麼幾天后就不會收到錯誤電子郵件就足夠了。