一個單獨的密碼不一定可以自己驗證。特別是，如果服務器能夠正確執行操作，則它不會存儲密碼本身，而是存儲根據密碼計算出的密碼哈希函數的輸出。密碼哈希函數（與單純的哈希函數相對）包括一些額外的功能，包括 salt （出於與安全性相關的很好的考慮）。然後，驗證密碼需要了解相應的鹽。由於鹽是特定於實例的（鹽的重點是不同的用戶擁有他們自己的鹽），因此需要用戶標識（用戶標識用作鹽的索引鍵）。

一方面，服務器不會知道密碼是否僅與任何帳戶匹配。

在安全的系統中，密碼先先加鹽然後散列。

在一個簡單的演示中，假設我有三個用戶：

 用戶名Passwordbob foobaralice foobarmaggie foobar  

設置了這些密碼後，會添加鹽並生成哈希：

 用戶名鹽哈希值哈希值bob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1alice 123456 123456foobar 17e9191daecc5b8be26779209769b275maggie ZXCVBN ZXCVBNfoobar 527cbp1b即使密碼可能匹配，它們也會以相同的方式存儲。這是一個重要的安全步驟，可防止在提取的密碼列表上使用Rainbow表。 
這使得無法僅憑密碼確定要登錄的帳戶，因為用途未知。這是因為用戶名被用作查找的關鍵字，並且沒有將其提供給服務器，在找到匹配項之前，如果不嘗試用戶表中的每個哈希，則無法匹配在第一步輸入的密碼。在配置正確的系統上，這可能太慢了，因為您使用的是慢速算法（請參見腳註）。
 
此外，如果系統告訴您密碼被盜，則可能會造成大量安全信息洩漏。 
 
 上面的示例僅用於說明目的，並使用MD5。切勿使用MD5哈希密碼-使用bcrypt，scrypt或pbkdf2。 sub> 

您基本上不是在問“有什麼理由我們沒有公共密碼和私人用戶名嗎？”

它們都是文本字符串。您實施唯一密碼的想法實際上只是在說用戶名是唯一的。您應用於文本框的標籤無關緊要。我們將專用的字符串稱為密碼，將唯一的字符串稱為用戶名或用戶ID，因為它是唯一的。

從安全角度考慮，並按登錄名/密碼的正常順序進行查看：如果您要求和都是唯一的，那麼您將對數據庫發起攻擊，因為將針對數據庫中的每個用戶檢查每個密碼，因為您需要密碼是唯一的。因此，這兩個唯一的行不通。這兩種非唯一性都不起作用，因為您不知道正在訪問哪個帳戶。這樣就只剩下一個唯一的字符串。如果您要製作一個唯一的文本字符串，不妨將其設為公共數據，並首先進行檢查（我們稱此數據為Login / ID / Username）。

讓我們想像一個比喻...

我是我的國王派出的使者，向城堡谷中的某座城堡傳遞信息。我知道我要去的城堡看起來像什麼，並給了我一個通行密碼告訴守衛，以便我可以進入城堡。

我有兩種選擇方法：

1. 就像您無疑會想到的那樣，執行此操作的常規方法是騎到我被送到的城堡，然後告訴他們要輸入的密碼。這首先是使用我的公共信息（城堡，任何想要查看的人都可以看到）以我的私人信息（密碼）登錄。

2. 但是有一種相反的方法做這個。我可以大聲疾呼，在整個山谷中高呼我的密碼短語，以供公眾聽。由於我打算參觀的城堡已經聽到了我的通行密碼（以及所有其他城堡以及該山谷潛在的邪惡居民），所以我要參觀的城堡應該知道會期望我。

   然後我繼續騎馬到正確的城堡，並穿越開放的吊橋。但是他們會讓任何人通過這個開放的吊橋！現在，我的私人信息已與世界共享，任何人都可以騎在城堡之間，然後用敞開的大門進入城堡。

   如果我不是在這裡自己大聲喊叫，山谷居民可以用自己的角站在山頂上，在山谷中大喊大叫，直到他們聽到吊橋開口的轟鳴聲；知道他們猜對了一個正確的密碼後，他們只需在城堡之間騎行，直到找到一個可以打開的城堡。

ol>

第一個選擇是通常如何進行。沒有理由更改該約定。替代方法是可行的，但是通過首先共享您的私人信息，您可以更輕鬆地在通過公共信息進行身份驗證之前猜測每個人的密碼，例如騎到每座城堡或嘗試向所有人公開帳戶名稱。在這個山谷中有成千上萬座城堡或網站上有帳戶，很可能有人會猜到一個簡單的密碼，然後將其與幾千個城堡或公共帳戶名稱中的一個簡單地匹配起來就容易得多。

出於安全原因，您沒有先讓Google輸入您的電子郵件。它輸入了您的電子郵件/用戶名，因此，如果您要登錄的工作或教育領域想要擁有自己的SSO / SAML登錄頁面

如果您首先要求輸入密碼，則在等待用戶名時必須將“秘密”值保持在某種狀態。對於Web應用程序，您通常需要以某種方式進行存儲，以便新過程可以讀取該值，因為用戶名將在第二個請求中出現。這在時間和獲取數據方面都增加了公開密碼字符串的機會。

首先要求用戶名，然後使用鹽分哈希進行密碼驗證（或沒有）權限可以立即訪問以驗證密碼所需的所有內容，並且系統僅需要在最短時間內使密碼本身可用。通常最好在盡可能短的時間內獲得敏感數據。

這是慣例。首先要求輸入密碼，您將最終訓練用戶在其他地方的用戶名字段中意外輸入密碼，這可能會導致通過日誌進行洩露。

請勿這樣做。 ：）

要添加；開發應用程序時，要確定標識與身份驗證/驗證的機制。 標識為1：很多，驗證/身份驗證為1：1

  1：1-與一個預選結果集匹配； 1：許多-與數據庫中的所有結果匹配 

像gmail這樣的用戶名是唯一的。這並非對所有應用程序都是強制性的，但可以肯定的是，與識別算法相比，驗證算法的壽命更加輕鬆。

考慮常用的用戶名，然後對gmail進行密碼驗證：

1. 輸入用戶名；

   gmail與所有其他唯一用戶名匹配唯一用戶名；是，請輸入密碼；

2. 輸入密碼。

   gmail只是將1個用戶名與以任何格式存儲的1個密碼進行匹配；沒有匹配項，身份驗證失敗。是的，請訪問您的郵件。

ol>

非常簡單的恕我直言。

從另一面看，是身份驗證（1：很多），匹配過程的gmail格式如下：

1. 輸入密碼； 並且正如@SilverlightFox明確指出的那樣，許多帳戶可以具有相同的密碼。

    匹配算法會將密碼與gmail數據庫中註冊的所有用戶名匹配。 

   過於保守的結果集可能是10個用戶名。

2. 輸入用戶名；
ol>

用戶名是唯一的還是可以相同的，將決定身份驗證過程運行的時間更多以及找到多少匹配項。如果超過1個匹配項，則必須實施三步登錄身份驗證。

兩步身份驗證使開發人員和算法的工作更加輕鬆。

在使用Google和大多數拆分身份驗證設置的情況下，系統基本上是在使用用戶ID來識別相關風險並確定應為用戶運行的適當登錄過程。

在大多數情況下，人員輸入的用戶ID僅是一種輸入。隨之而來的還有許多其他信息（例如您所訪問的IP地址，用戶正在使用的設備-生成並隨用戶ID一起傳遞的設備簽名）傳遞給風險確定引擎（在大多數銀行中）但可能並不總是使用），可以提供建議的登錄過程。除了該系統之外，還要檢查與用戶相關聯的登錄策略（例如，是否啟用了多因素）。根據最終決定，大多數時候您可能只會看到一個簡單的密碼屏幕，但在某些情況下，可能會要求您進行多次身份驗證過程（例如，基於電話的OTP等）。