錢包簽名是什麼？登入、交易簽署與 Permit 釣魚辨識教學

作者｜桑幣區識編輯團隊
發布｜2026/10/28
更新｜2026/10/28

使用 DApp 時，錢包有時請你簽名登入，有時要求確認交易，還可能出現 Permit 或一長串看不懂的資料。它們都叫「簽署」，但效果可能完全不同。

數位簽章能讓系統驗證特定資料是否獲得相應帳戶授權。重點不只是「是不是我按的」，而是你究竟同意了哪些內容、誰能使用這份簽章，以及能用到什麼時候。

本文以 Ethereum／EVM 常見操作為主，從實際判讀角度說明登入、訊息簽名、交易與資產權限的差別。其他網路及不同帳戶設計，需依各自規則理解。

Table of Contents

錢包簽名是什麼？

錢包簽名是由錢包配合金鑰或相應驗證機制，對特定資料產生可驗證的授權證明。

對一般由私鑰控制的帳戶而言，私鑰用來產生簽章；驗證者則能依相應規則確認簽署帳戶，而不需要拿到私鑰本身。智能合約錢包也可能透過合約規則驗證，不能把每種帳戶都想成同一把私鑰的模式。

正常簽署不是把助記詞交給網站。但若簽署內容允許資產移動，對方可能依有效簽章執行相應操作。

延伸閱讀：助記詞與私鑰有什麼不同？錢包備份、密語與還原教學

相關執行環境可閱讀智能合約完整介紹。

登入簽名、交易簽署與 Permit 有什麼不同？

類型	常見用途	是否立即上鏈	應核對的重點
登入訊息	證明控制帳戶並建立網站登入狀態	通常不需要	網域、帳戶、URI、用途、nonce、時間
結構化資料簽名	訂單、授權或其他協議資料	簽名當下未必上鏈	類型、驗證合約、網路、欄位及執行效果
Permit	依特定規格設定代幣額度	可由他人稍後提交	owner、spender、value、nonce、deadline
交易簽署	轉帳、呼叫合約、設定授權等	廣播後可進入鏈上流程	網路、目的地、資產變動、合約操作與費用

Permit 本身也可以採用結構化資料簽名，因此上表是依用途幫助判讀，不是互斥的技術分類。

不能單憑按鈕寫 Sign、沒有費用，或網站稱它是「驗證」，就認定只是登入。

Sign-In with Ethereum 是什麼？

Sign-In with Ethereum（SIWE）由 ERC-4361 描述，讓使用者透過標準化訊息證明對 Ethereum 帳戶的控制，供網站建立登入工作階段。

典型訊息包含請求的網域、帳戶地址、URI、版本、Chain ID、nonce 與簽發時間，也可能加入到期時間等資訊。

例如，登入某個服務時，應確認錢包顯示的網域與你預期使用的服務一致、簽署的是正確帳戶，且文字用途符合登入需求。

這不是「任何寫著 Sign in 的訊息都安全」。網站仍須正確驗證訊息及防止重放，使用者也要確認來源。即使不涉及直接轉幣，登入權限本身仍可能影響帳戶中的資料或操作。

personal_sign 與 EIP-712 是什麼？

personal_sign：常見訊息簽署方式

許多登入流程會使用 personal_sign 請求簽署可閱讀訊息。它提供特定訊息編碼方式，但不能只因使用這個方法，就斷定內容只有登入用途。

仍應閱讀完整文字，確認適用網域、目的與其他條件。

EIP-712：讓資料帶有結構與欄位

EIP-712 定義結構化資料的雜湊與簽署方式，方便應用呈現欄位，例如合約、金額、對象與期限。MetaMask 常見的請求方法為 eth_signTypedData_v4。

資料比較容易閱讀，不代表資料內容自動安全。EIP-712 本身也不替每個應用完整實作重放防護，仍需由協議處理 nonce、期限與驗證等規則。

此外，畫面上的應用名稱不等於已驗證身分。必須搭配網域、實際合約及所簽欄位判斷。

為什麼不用 Gas 的簽名也可能動用資產？

簽名是在證明你同意某份資料；資料是否稍後提交上鏈、由誰支付費用，是另一個問題。

例如，ERC-2612 Permit 可以讓有效簽章被提交到代幣合約，更新授權額度。簽署者未在當下支付 Gas，不代表這份資料無法影響資產。

類似地，某些市場使用鏈下訂單簽名，之後才依協議規則撮合或結算。是否會移動資產，還要看既有授權、驗證條件與應用設計。

延伸閱讀：代幣授權、Allowance 與撤銷教學。

Permit 與 Permit2 簽名畫面要看哪些欄位？

以常見 ERC-2612 Permit 為例：

欄位	判讀方式
owner	是否為你本次要使用的帳戶
spender	哪個地址獲得使用權限，是否符合預期應用
value	授權額度，不一定等於目前餘額或本次花費
nonce	用於協議的簽章使用順序與防重放判斷
deadline	簽章可被接受的期限，不能直接當成額度到期日
domain／chainId／verifyingContract	核對適用環境及驗證合約，依實際格式顯示

若畫面只顯示最小單位的大整數，要連同代幣 decimals 換算。看不清楚時不要自行猜測，也不要把極大額度當成固定小額付款。

Permit2 則可能有不同的權限層級與欄位。其 AllowanceTransfer 支援額度與到期時間，SignatureTransfer 用於一次性簽名轉移；簽章期限、額度期限與已使用狀態不能混成同一件事。

詳細規則以代幣或應用官方文件為準，不把一套欄位解讀套用到所有 Permit 變體。

簽名釣魚如何發生？

常見情境是網站宣稱「登入」、「領取空投」或「安全驗證」，實際要求簽署的是授權、可執行訂單或其他有資產效果的資料。

簽章取得後，攻擊者可能稍後才使用。使用者當下沒看到資產變少，仍可能誤以為什麼都沒發生。

以下情況值得停下核對：

預期只是登入，畫面卻出現 spender、代幣額度或出售條件。
網域、帳戶、網路或驗證合約與本次操作不符。
要求在短時間內反覆簽署，卻不說明每一步用途。
宣稱撤銷或修復，實際內容卻增加權限或轉出資產。
只顯示難以理解的雜湊或資料，無法確認授權效果。

這和地址投毒有所不同：地址投毒主要誘導錯誤目的地，簽名釣魚則著重讓你授權並非原本打算同意的內容。

簽署前怎麼檢查？六步判讀流程

第一步：先說清楚本次目的

自己先確認這次是登入、付款、交換、掛單還是設定權限。只有先知道預期結果，才能判斷請求是否合理。

若準備在 DEX 交換代幣，授權與交換可能是不同步驟；若只是登入，則不應因網站催促就接受無關的資產額度。

第二步：核對網站與帳戶

從可信入口開啟服務，核對網址及實際簽署帳戶。網站標誌、訊息中的名稱或看似熟悉的地址，都不足以單獨證明來源。

第三步：辨識請求類型

看是訊息、結構化資料、交易，還是其他帳戶權限。不同錢包版本與帳戶模式的名稱可能不同，不能只看確認按鈕。

第四步：閱讀對象、金額與期限

確認收款人或 spender、代幣合約、額度、網路與相關期限。訊息有多頁就展開完整內容，不以頭尾幾碼取代完整核對。

第五步：比較預覽與預期結果

如錢包提供模擬或資產變動預覽，可作輔助，但不能當成所有未來執行效果的保證。鏈下簽名可能當下不轉幣，卻在日後具備用途。

第六步：無法解釋就拒絕

拒絕尚未完成的請求，不會因此讓你失去私鑰或自動轉出資產。回到官方文件確認需求；不要為了解鎖登入或領取資格，關閉警示後盲目重試。

硬體錢包與清晰簽署能解決所有問題嗎？

硬體錢包協助隔離金鑰，並在裝置上確認簽署資訊。清晰簽署則希望讓使用者理解操作，而不是只看到不透明資料。

但裝置不能替你決定該不該授權某個 spender。即使簽章來自真正裝置，如果你確認的是惡意內容，協議仍可能接受。

「盲簽」通常指無法充分看清楚並理解簽署內容的情境。不同產品功能與用語不同，不應把開啟某個設定當作所有 DApp 的例行步驟。

已經簽了可疑訊息，怎麼辦？

先保留資料，辨識簽了什麼

記錄網域、時間、帳戶、網路及可取得的簽署內容。若有交易雜湊也一併保存；不要為了找紀錄再次進入可疑網站或重新簽名。

鏈下簽名不一定有 TxID，鏈上沒有新交易，也不表示簽章未被網站取得。

依權限類型處理

實際情況	後續核對方向
登入工作階段	透過服務官方功能登出或終止相應工作階段
已生效代幣額度	查詢並處理對應網路、代幣與 spender
未使用 Permit、訂單或其他簽章	核對協議是否提供 nonce 失效、取消或其他有效方式
私鑰或助記詞外洩	視為控制權問題，不能只靠登出或撤銷單一額度處理

不存在能取消所有錢包簽名的通用按鈕。尤其不能假設 approve(0) 會讓先前未使用的 ERC-2612 Permit 一定失效；若其 nonce 仍有效、其他條件也成立，該簽章可能重新設定額度。

Permit2 的底層代幣授權、應用額度與未使用簽名，也可能需要分層判斷。只撤掉某層權限，不代表其他簽名已永久作廢；未來重新授權前仍需確認。