印度 HSBC 近日向網上銀行客戶發出電郵，通知客戶系統將於 2026 年 4 月 6 日起，自動將所有密碼轉為全大階格式，要求用戶屆時以大階字母輸入現有密碼登入，過程中無需重設密碼，多名網絡安全專家及軟件工程師隨即指出，銀行能在後台直接轉換密碼大細階而不要求用戶重設，技術層面幾乎只有一個解釋：印度 HSBC 的系統很可能未按照國際標準，以不可逆方式儲存客戶密碼。事件令外界對這家國際銀行的資訊安全架構產生嚴重質疑。
電郵內容與關鍵細節
印度 HSBC 官方發出的電郵中舉例說明，假如用戶原有密碼為「Test123」，系統轉換後用戶應由 4 月 6 日起輸入「TEST123」。換言之印度 HSBC 是在後台對密碼進行大細階轉換，用戶只需配合新格式輸入即可，整個過程不涉及密碼重設。
電郵同時指出透過生物辨識或安全權杖（Secure Token）登入的用戶不受影響，登入的用戶不受影響而毋需作出任何改動，有需要的客戶可前往分行或致電 HSBC PhoneBanking 查詢，Premier 客戶則可聯絡其專屬客戶經理。
值得注意的是印度 HSBC 官方網站的常見問題頁面一直清楚列明「Your password is not case sensitive」（你的密碼不區分大細階），這項紀錄證實印度 HSBC 的網上銀行系統在是次改動前，本身已採用不區分大細階的密碼驗證機制，而這一點正是安全專家最為擔憂的根源。
為甚麼銀行不應能夠轉換用戶的密碼
要理解這封電郵為何在技術界觸動安全警報，必須先了解銀行及所有負責任的網上服務應如何儲存用戶密碼，按照業界標準服務供應商在用戶註冊時，不會直接保存密碼原文，而是透過稱為「雜湊」（Hashing）的單向數學運算，將密碼轉化為一組固定長度的亂碼字串。用戶登入時系統會對輸入的密碼執行同一運算，再將結果與資料庫中儲存的雜湊值作比對。整個驗證過程中系統從不需要「看見」或還原用戶的原始密碼。
雜湊運算有一個關鍵特性：它天生區分大細階，以「Test123」為例，系統為其產生的雜湊值與「TEST123」產生的雜湊值完全不同，兩者之間不存在任何可逆的數學關係。在正確採用雜湊儲存的系統中，銀行無法得知用戶的原始密碼內容，自然也不可能在後台將密碼由混合大細階轉為全大階，再重新產生對應的雜湊值。銀行必須先取得密碼原文，才能實現這種轉換而這正是問題所在。
美國國家標準暨技術研究院（NIST）在 2024 年發布的 SP 800-63B 第 4 版修訂指引中，明確要求所有驗證系統必須以能抵禦離線攻擊的形式儲存密碼，並建議採用 Argon2id、bcrypt、scrypt 或 PBKDF2 等記憶體密集型雜湊演算法，配合為每位用戶獨立產生的鹽值（Salt），Open Web Application Security Project（OWASP）亦將 Argon2id 列為當前首選密碼雜湊方案。這些演算法均屬單向且區分大細階，且運算速度經過刻意放慢，目標是令暴力破解攻擊的成本大幅提高。任何符合上述標準的系統，都不會出現「銀行在後台自動轉換密碼大細階」的情況。
印度 HSBC 的密碼系統到底出了甚麼問題
綜合電郵內容及官網常見問題頁面的紀錄，安全專家認為印度 HSBC 的密碼儲存機制可能存在以下問題，第一種可能是密碼從一開始就以明文或可逆加密格式儲存，這代表銀行的資料庫中一直保留着用戶密碼的原始文字，系統因此能直接讀取密碼、執行大細階轉換，再以新格式重新儲存。在數碼安全領域明文儲存密碼屬於最嚴重的安全失誤之一，因為任何擁有資料庫存取權限的人員、以至成功入侵系統的攻擊者，均可直接讀取所有客戶的密碼。
第二種可能是系統一直採用不區分大細階的標準化雜湊，部分較舊或設計欠佳的系統，會先將密碼統一轉為小階（或大階）後再進行雜湊運算，令密碼在實際運作中不區分大細階。印度 HSBC 官網明確列出密碼「不區分大細階」的說明，與這種做法高度吻合。這種方式雖則好過明文儲存，但以現代安全標準衡量仍屬不合格，因為它大幅縮減了密碼的有效字符集。
印度金融科技論壇 TechnoFino 上，多名用戶及工程師對事件表達強烈憂慮，有用戶直言應立即更改印度 HSBC 密碼及所有使用相同密碼的帳戶，亦有技術人員懷疑銀行可能曾經歷未公開的安全事故，而是次密碼轉換可能是事後補救措施的一部分。
密碼安全強度因此被削弱
無論印度 HSBC 的後台系統屬於上述哪一種情況，這項改動本身都在削弱用戶密碼的安全強度，安全領域以「熵」（Entropy）衡量密碼的複雜度與不可預測性，其計算公式為 E = L × log₂(R)，當中 L 代表密碼長度，R 代表可用字符集的大小。
假如一組密碼同時包含大階字母（26 個）、小階字母（26 個）、數字（10 個）及特殊符號（32 個），可用字符池為 94 個，每個字符位置提供約 6.55 位元熵值，一旦系統將所有密碼轉為全大階，小階字母的 26 個字符選項即被移除，字符池縮減至 68 個，每個字符位置的熵值降至約 6.09 位元。以一組 10 位密碼為例，混合大細階版本的熵值約為 65.5 位元，全大階版本則降至約 60.9 位元而差距看似不大，但在暴力破解的語境下，每減少 1 位元熵值，攻擊者所需的嘗試次數便減半，4.6 位元的差距意味着破解難度降低超過 20 倍。
企業應如何審視銀行合作夥伴的安全管治
印度 HSBC 密碼事件對所有依賴網上銀行服務的企業而言，是一個值得深思的案例，企業在評估銀行合作夥伴時，除了考量利率與服務範圍，網絡安全管治能力同樣應列為核心指標。一家銀行處理密碼的方式，往往反映其整體資訊安全架構的成熟程度。
從供應商風險管理的角度出發，企業應主動向銀行了解其密碼儲存政策是否符合 NIST SP 800-63B 及 OWASP 的最新建議，包括是否採用記憶體密集型雜湊演算法、是否為每位用戶產生獨立鹽值，以及是否定期對密碼資料庫進行安全審計，印度儲備銀行（Reserve Bank of India）在 2024 年 7 月發布的《網絡韌性與數碼支付安全控制主指引》中，已要求所有受規管的支付系統營運商在 2025 年至 2028 年間分階段達到網絡安全基線標準，大型非銀行營運商的合規期限定於 2025 年 4 月 1 日，中型營運商則為 2026 年 4 月 1 日。印度 HSBC 的密碼處理方式是否符合這些監管要求，值得市場進一步審視。
企業資訊安全總監應藉此事件重新檢視自身組織的密碼管理策略，確保所有內部系統均採用符合業界標準的雜湊與加鹽機制，NIST 在最新指引中已取消對定期強制更改密碼及強制混合字符類型的要求，轉而強調密碼長度、即時比對已洩露密碼資料庫，以及推動 FIDO2 與 WebAuthn 等抗釣魚驗證標準。企業亦應考慮部署多重驗證（MFA）及無密碼驗證（Passwordless Authentication）方案，減少對單一密碼的依賴。
用戶應採取的即時行動
對於印度 HSBC 的網上銀行客戶，安全專家普遍建議在 4 月 6 日後立即設定一組全新的強密碼，而非沿用被系統轉為大階的舊密碼，新密碼應混合使用大細階字母、數字及特殊符號，長度建議不少於 14 個字符。假如用戶曾在其他網站或服務使用與印度 HSBC 相同的密碼亦應一併更改，因為密碼若長期以不安全方式儲存，代表該組密碼可能早已處於風險之中。
用戶亦應盡快切換至生物辨識或安全權杖登入方式，印度 HSBC 在電郵中確認這些選項不受影響，而它們在安全性上普遍優於純密碼驗證，值得留意的是要求用戶更改密碼輸入方式的電郵，本身就是網絡釣魚攻擊的常見範本。雖然是次通知經核實屬官方發出，但用戶日後收到類似訊息時，應直接致電銀行官方客服熱線求證，避免點擊電郵中的任何連結。
銀行認證體系的轉型壓力
印度 HSBC 密碼事件揭示了金融業一個長期存在的結構性問題：部分機構的核心認證系統仍然運行在過時的技術架構上，未能跟上密碼安全標準的演進步伐，隨着 NIST、OWASP 及各國金融監管機構持續收緊對密碼儲存與驗證的要求，銀行業正面對從傳統密碼模式向無密碼驗證過渡的壓力。
NIST 在 2024 年的修訂指引中已擁抱 Passkey 及可同步驗證器（Syncable Authenticator）等新興技術，反映認證方式正由「你知道甚麼」（密碼）逐步向「你擁有甚麼」（硬件權杖、流動裝置）及「你是誰」（生物辨識）轉移，印度儲備銀行在 2025 年 9 月發布的數碼支付認證新指引中，亦要求所有受規管實體在 2026 年 4 月 1 日前落實雙重認證要求，其中至少一個驗證因素必須為動態元素。對企業而言認證體系的升級不只是技術層面的議題，更直接關乎客戶信任與品牌聲譽。一封看似例行的密碼通知電郵，已足以令市場對一家國際銀行的資訊安全能力產生根本性懷疑。
來源：Reddit