部署一個使用身分驗證的應用程式時，安裝流程常會一併加入預設憑證（default credentials），這些帳號通常帶有預設的使用者名稱與密碼。問題出在部署的管理員若沒有在服務對外開放前重新設定這些帳號的憑證，門就等於一直開著。

更嚴重的情況是應用程式含有硬編碼憑證（hardcoded credentials）——只有重新編譯應用程式才能改掉。這些憑證可能是開發期間為了除錯而加入、發行前忘了移除，也可能是刻意植入的惡意後門。

def process_authentication()
{
  string username = read_string();
  string password = read_string();

  // Check for debug user, don't forget to remove this before release
  if(username == "debug")
  {
    return true;                                  /* 直接通過驗證 */
  }
  else
  {
    return check_user_password(username, password);
  }
}

程式先從網路讀取使用者名稱與密碼，接著比對硬編碼的使用者名稱 debug。一旦命中就自動通過身分驗證流程，否則才走正常的檢查。

要利用這種預設帳號，你需要做的往往只是用 debug 這個身分登入。但在真實世界的應用程式中未必這麼直接：登入流程可能還要求來源 IP 位址在允許清單內、要求在登入前先送出某個魔術字串，諸如此類。

分析協定時，這類後門的線索通常藏在驗證程式碼的分支裡：任何在正常憑證檢查之前就提早回傳成功的路徑，都值得追下去。