先回答：臨時密碼應該是新產生、單一用途，並且可回收
替客戶、測試環境或交接帳號設定密碼時，不要從既有密碼改一兩個字元，也不要把同一組字串交給多人。先產生一組新的長密碼，限定一個帳號與一次交付使用，並在對方首次登入後更換或停用它。密碼本身只是驗證秘密的一部分；帳號權限、登入通知與多因素驗證仍要由服務端設定。
例如把測試帳號交給外包人員時，可先建立低權限帳號，設定一次性的交付密碼，再記下何時收回存取權。不要把正式管理員帳號當成「臨時帳號」，也不要把客戶的既有密碼貼進工單或聊天群組。NIST 的數位身分指南也將密碼視為驗證秘密，較高層級的保護需要其他驗證與系統控制；這裡的流程不是任何服務的合規保證。
用密碼產生器建立可交付的字串
開啟 密碼產生器（工具 ID：password-generator）後，先選擇足夠長度，再依目標服務是否接受符號、大小寫與數字調整選項。現有工具可選大寫、小寫、數字、符號與排除易混淆字元，並用瀏覽器的隨機值產生結果；產生後可複製。若對方需要人工輸入，排除 0、O、I、l、1 等相似字元通常較不容易抄錯，但不要為了好讀而把密碼縮得太短。
密碼強度與破解時間顯示只能當作工具內的估算，不是攻擊保護期限。網站的登入限制、密碼雜湊、多因素驗證、裝置安全與是否有人外流，都會改變實際風險。遇到服務明確規定格式時，以該服務的規則為準；產生器不能替你繞過不允許的字元或公司政策。
交付時把密碼和帳號資訊分開傳
最常見的失誤是把帳號、密碼、登入網址與權限說明全部放在同一則訊息。較好的做法是先用一個已確認的管道傳帳號與登入網址，再用另一個受控管道傳密碼，並要求收件人完成首次登入後回覆確認。若必須留工單紀錄，記錄「已交付、何時到期、誰負責回收」，不要把明碼留在內容裡。
交接給客戶時，可以先建立一個隨機識別碼，例如用 UUID 產生器 產生案件代號，讓雙方確認同一筆交付，而不是在訊息標題重複帳密。截圖或複製工單前，使用 個資遮蔽工具 處理 Email、電話與其他不需要傳遞的資料。這些工具無法驗證收件人的身分；收件地址或聯絡方式有疑慮時，先用既有聯絡資料回撥確認。
首次登入後要做的回收與驗證
請收件人在第一次登入後立即設定自己的密碼，並確認可以開啟必要功能、看不到不該有的資料。管理端接著檢查舊密碼是否失效、臨時帳號是否有到期日、是否啟用了服務提供的多因素驗證，以及是否留下可追查的權限變更紀錄。若是測試帳號，測試結束後應停用或刪除，不要讓它一直保留在正式系統。
交付完成後，不要只看「對方說可以登入」。實際核對帳號名稱、角色、首次登入時間與權限範圍；再刪除聊天草稿、剪貼簿內容或本機暫存的明碼。密碼產生器不會管理帳號生命週期，也不能阻止收件人再轉傳密碼。高權限、含個資或付款權限的帳號，應改用組織既有的身分與存取管理流程，並以服務的正式來源與主管機關要求為準。
常見問題
臨時密碼可以交給多位同事共用嗎？
不建議。共用後無法可靠追查誰使用過帳號，也難以在某一人離開後只收回其權限。應建立個別帳號或採用管理端支援的授權方式。
排除易混淆字元會不會讓密碼不安全？
可用字元集合會變小，因此應以更長的隨機字串補足，而不是同時縮短長度。重點是每次都新產生且不重複使用。
工具顯示很久才會被破解，就不需要多因素驗證嗎？
不是。該顯示是估算，無法涵蓋釣魚、外流、惡意程式或服務端設定。服務提供多因素驗證時，仍應依風險與組織政策啟用。
密碼傳出後發現寄錯人怎麼辦？
立即在管理端重設或停用該帳號與密碼，檢查近期登入紀錄，並依組織的事件通報流程處理。不要只再補傳一組新密碼。