T13 · ウォレット接続

現実の問題

企画担当が言います。「ウォレットログインを追加しよう。WeChat ログインと似たものでしょう。」

DApp を開き、右上の「Connect Wallet」を押し、ポップアップを確認するとアバターが現れます。確かに似て見えます。

しかし分解すると、少なくとも 3 つのまったく異なる動作からできています。

• ブラウザー拡張がアドレスをページへ渡す。何の検証も行われていません。ページがアドレスを「教えられた」だけです。
• ページが署名を要求し、ユーザーが確認する。何を証明し、誰へ証明したのでしょうか？
• ログイン直後に「承認」という別のポップアップが出るサイトもあります。ユーザーはログインの続きだと思って確認します。これでウォレット内のあるトークンをすべて渡してしまうかもしれません。

どれもポップアップで、確認を押すため似ていますが、結果はまったく違います。一つ目は何も起こらず、二つ目の最悪の結果はアカウントのなりすまし、三つ目は資金の喪失です。

ユーザーが区別できないのは、製品側も区別できていないことが多いからです。 本章では、3 つを明確に分けます。

思考実験

一つの鍵を、3 つの道具として考えます。

入社時に受け取った社員証が、次の役割をすべて持っているとします。

1. 入館カード。かざすとゲートが開き、「社員である」とだけ証明します。
2. 署名印。書類へ押すと、「読んで承認した」と証明します。
3. 白紙小切手に署名できるペン。署名すると経理が支払い、しかも紛失届を出すまで、同じ署名で繰り返し換金できます。

現実には、この 3 つを一体化しません。カードをなくせば再発行し、印をなくせば公証の手続きをし、白紙小切手はそもそも渡されません。

Crypto ウォレットの秘密鍵は、3 つを一つにまとめます。同じ鍵で入館し、印を押し、繰り返し換金できる小切手へ署名できます。違いは鍵ではなく、署名する紙に何が書かれているかです。

そして「繰り返し換金できる小切手」は、チェーン上の状態を持ちます。一度渡すと、取引を送って取り消すまで有効なままです。ページを閉じても、キャッシュを消しても、パソコンを変えても残ります。Web2 のログインにはない種類のものです。

問いは、ユーザーが署名中の紙を理解できるか、になります。

あなたが決める

DApp のログインを作ります。4 つの方法からどれを選びますか？

結果を観察する

4 つの選択肢が示すのは、接続、認証、承認は異なる動作なのに、画面ではどれもポップアップに見えるということです。

特に 2 つの欄を見てください。「誰も検証しない」は最も見落としやすい欄です。取得したアドレスは偽装でき、表示には使えても認可には使えません。「期限なし」は、ページを閉じても残る唯一の欄です。承認には取り消し入口が必要で、それは製品の一部であるべきです。別の場所をユーザーに探させてはいけません。

表にない注意点もあります。「チェーンへ送らない」と「危険がない」は別です。 オフチェーン署名自体が承認の証票になる場合があります。実例では、ユーザーの取引送信を必要としない深刻なフィッシングを見ます。

モデルを作る

ログインを、役割が単一の 5 段階へ分けます。

署名する内容がすべてを決める

署名要求は 3 種類あり、リスクには桁違いの差があります。

3 番目はブラインド署名です。意味不明な文字列を確認すると、何が起きるか分かりません。製品がそれを要求するなら、設計に問題があります。

2 番目は安全そうに見えるため、さらに注意が必要です。spender がアドレス、value が 78 桁の数値なら、すべてのフィールドを「見た」ユーザーでも、「見知らぬアドレスに全残高を動かす権利を 1 年間与える」とは読み取れません。

正直な表示の基準は、生データを出すことではなく、読んだユーザーが結果を説明できることです。 両者は大きく違います。

ログインメッセージの形

純粋なテキストで示します。形式よりフィールドの意味が重要です。

example.com が、このアドレスでのログインを求めています：

0x<自分のアドレス>

署名すると example.com へのログインに同意します。
この署名は取引を送らず、資金操作の権限も与えません。

Chain ID: <チェーン ID>
Nonce: <バックエンドが生成した一度限りの乱数>
Issued At: <発行時刻>
Expiration Time: <有効期限>

各フィールドが別の攻撃を防ぎます。ドメインはサイト間の再利用、アドレスは他人の署名によるなりすまし、Chain ID はチェーン間の再利用、Nonce は同じサイトでの再利用を防ぎます。Nonce は使用直後にバックエンドで無効にします。有効期限は盗まれた署名を使える期間を制限します。

「取引を送らず、資金操作の権限も与えません」は、ユーザーへの約束です。表示を見て実際にその通りだと確認できるたび、信頼が増します。ログインへ承認を一度でも忍び込ませれば、業界全体の信頼を損ないます。

セッションの寿命

検証後は、Web2 と同じ普通のセッション資格情報を発行します。ただし Crypto 特有の失効条件が 3 つあります。

type WalletSession = {
  address: string;      // 認証済みアドレス
  chainId: number;      // 認証時のチェーン
  issuedAt: number;
  expiresAt: number;
};

// 直ちにセッションを破棄する 3 条件：
// 1. ウォレットのアカウントが変わり、現在のアドレスが session.address と異なる
// 2. ウォレットのチェーンが変わり、単一チェーンの業務で chainId が一致しない
// 3. ウォレットが切断された

最初は特に見落としやすいものです。ウォレットで別アカウントへ変えても、ページのセッションは古いままです。B の画面で A のデータを操作することになります。変更イベントを監視し、アドレスが変わったら、静かに切り替えるのではなく、直ちにセッションを破棄して再認証を求めます。

承認は必要な時に、必要な額だけ、取り消し可能に

承認はチェーン上の取引です。設計で問うのは 3 点です。

1. いつ求めるか？ ログイン時ではなく、初めてその機能を実際に使う時です。
2. いくら承認するか？ 無制限ではなく、その操作に必要な額です。一回のクリックを省く代わりに、永続的なリスクを残さないでください。
3. どう取り消すか？ 自製品で与えた承認を一覧にし、ワンクリックで取り消せるページを用意します。

3 番目が Lab の半分です。「別ツールで取り消せる」と考えるチームも多いですが、自分の製品が作ったリスクの出口は、自分の製品が提供すべきです。

何と呼ぶか

実践

AI Lab

第 1 段階：
Crypto ウォレットの署名フィッシングの典型を列挙し、各形態について説明してください。
- 攻撃者はどの種類のデータへ署名させるか
- ユーザーはウォレットのポップアップで実際に何を見るか
- 署名後に攻撃者は何ができ、ユーザーの追加操作は必要か
- ユーザー側から識別できる兆候はあるか

第 2 段階：
これは自分のログインと承認の画面文言、ポップアップ内容です（実際の内容を貼る）。
各形態と照合し、正直に表示できているか、ユーザーが誤解する可能性があるか調べてください。
一般論ではなく、具体的な修正を示してください。

実例

変数を一つ変える

持ち帰る問い

章末チェック