網站改版搬了會員資料，不代表原密碼可以直接沿用。本文用五項驗收問題，協助企業比較強制重設、相容移轉與首次登入升級的取捨，避免上線後大量登入失敗、客服塞車與帳號安全風險。
會員姓名、訂單與點數都已搬到新版網站，正式切換後，老客戶輸入原密碼卻一直失敗。客服開始代為改密碼，行銷活動帶來的流量卡在登入頁，甚至有人提議請舊廠商匯出會員密碼。這不是單純少搬一個欄位，而是改版最容易同時影響營收、信任與資安的交接點。
可以把會員搬家想成健身房換門禁系統。會員名單可以抄到新櫃台，但不能要求每個人交出家門鑰匙再複製。合理做法是確認舊卡能否被新機器安全辨識，不能相容時就發新卡，並先安排通知、驗證與人工協助。
密碼不是能解開來搬運的一般資料
安全系統不應保存可讀回的原始密碼，而是保存密碼雜湊，也就是把密碼經過單向計算後得到的比對結果。使用者登入時，系統用相同規則計算再比較，不需要知道原密碼。NIST（美國國家標準暨技術研究院）SP 800-63B 要求密碼搭配每位使用者不同的隨機值後再雜湊，並保存演算法與成本參數，也就是讓每次猜測更耗費運算資源的設定，讓日後能安全升級。
因此，廠商若說「可以把所有會員的明文密碼交出來」，反而是重大警訊。即使拿到雜湊值，新舊系統的演算法、參數或額外秘密不同，也未必能直接相容。若忽略這一點，上線後可能出現大量登入失敗、購物車放棄、客服重工；若為求方便降低保護，則會擴大帳號遭冒用與資料外洩後的風險。
用五個問題驗收廠商的移轉方案
- 舊系統實際保存什麼？ 要求廠商說明是不可逆的雜湊、使用哪一類演算法與參數、是否依賴另行保管的秘密，不必取得任何會員的原始密碼。若回答只有「有加密」，應繼續問清楚能否解密，以及誰持有解密能力。
- 新系統能否驗證舊格式？ 不是把欄位匯入成功就算相容。應用測試帳號在隔離環境驗證正確密碼、錯誤密碼、特殊字元與停用帳號，並確認登入後會不會升級成新格式。
- 不能相容時採哪種重設流程？ 強制重設較單純，但會增加客服與流失；分批或首次登入時轉換較順暢，卻需要更複雜的雙系統期限、監測與關閉機制。方案要有完成日期，不能讓舊驗證方式永久存在。
- 重設連結與通知能否安全送達？ OWASP（開放全球網頁應用程式安全計畫）建議重設代碼應隨機產生、限時且只能使用一次。企業還要驗證寄件網域、會員聯絡資料品質、退信處理與客服辨識流程，避免真正會員收不到，冒用者卻有機會反覆嘗試。
- 切換後舊登入狀態怎麼處理？ 密碼移轉完成不等於既有登入憑證已失效。應決定哪些裝置需要重新登入、舊站何時停止驗證、未完成重設者如何處理，以及異常登入由誰監看。
三種方案的差價買到什麼
最省開發的做法通常是全體強制重設密碼，優點是邊界清楚、舊格式可盡快退場；代價是通知量、客服量與短期登入流失。相容匯入能讓多數會員沿用原密碼，但前提是新系統確實支援舊格式，且匯入、保管與刪除過程都受控。
另一種是會員第一次在新站登入時，先用舊規則驗證，成功後立即改存新格式。OWASP 將這類登入後重新雜湊列為升級方式之一；限制是久未登入者仍保留舊格式，因此要設定期限，逾期改走安全重設。沒有哪一種永遠最好，應依活躍會員比例、交易頻率、舊格式強度、可接受中斷與客服量決定。
上線前走完一次真實會員旅程
先建立不含真實客戶資料的測試會員，分別模擬活躍會員、久未登入者、信箱已失效者、多因素驗證使用者與已停用帳號。多因素驗證是密碼之外，再用裝置或驗證器確認身分。從收到通知、開啟限時連結、設定新密碼、重新登入，到查看訂單與點數完整走一遍，記錄每一步的預期結果、失敗訊息、客服處理與回復方式。
不要只驗收「資料筆數相同」。還要比較可成功登入比例、重設信退信、客服案件與異常嘗試，並保留舊系統唯讀或回復方案到觀察期結束。會員多、交易不中斷要求高時，可先小批切換，再逐步擴大。
自行處理的邊界與接洽準備
企業可以自行盤點會員數、近半年活躍比例、登入方式、聯絡資料品質、預計切換日與客服容量，也可以要求廠商用測試帳號展示完整流程。不要自行下載、傳送或打開密碼雜湊檔，更不要用群組訊息交換相關檔案。
若舊系統無法說明密碼保存方式、會員同時使用社群登入或多因素驗證、切換會影響付款與訂單，或需要讓新舊驗證並存，就值得由熟悉身分驗證、資料移轉與營運切換的人共同設計及驗證。接洽邊境部署前，可準備新舊平台名稱、會員與活躍人數、登入方式、重設信寄送能力、客服時段、不能中斷的流程及合約中的資料交付範圍，讓討論直接進入可測試的移轉方案。