CAPTCHAのプライベートアクセストークンへの置き換え

♪ ♪

こんにちは 今回は 私 Tommy Pauly が AppやWebサイトが Appleや業界全体の 不正防止プロバイダと 協力して CAPTCHAを迂回する方法を ご紹介します プライベートアクセス トークンが 不正防止のための いかに強力なツールか 運用するサーバで どうやって有効にするのか Appでどうやって 使用するのか これらについて お話しします

プライベートアクセス トークンの前に なぜ CAPTCHAが使われるのか この説明から始めましょう Webサイトで 新規アカウントを作成したり 既存のアカウントで サインインしようとすると このようなCAPTCHAに 遭遇することがありますね CAPTCHAは ボタンを押すだけの場合も 入力に苦労する場合も あります

こんな風に邪魔されるのは 嫌ですよね 私もそうです このCAPTCHAは 不正行為を 防ぐためのものです 不正行為でサーバの運営に

負荷をかけたくないですよね アカウントの作成や 製品の購入は 正当なユーザーからの 依頼の場合もありますが 攻撃者やボットからである 可能性もあります 残念ながら CAPTCHAのような 不正防止ツールが AppやWebサイトの 利用を厄介にしています 良質な体験と 不正防止の両立は 難しいことです

CAPTCHAは より時間がかかる 複雑な体験を引き起こします 攻撃を防ごうとして 大切な顧客を失うことにも なりかねません

CAPTCHAはプライバシー上の リスクもあります クライアントが信頼でき 簡単なCAPTCHAで済むか 判断するために サーバは クライアントの IPアドレスを使って クライアントのトラッキングや フィンガープリントに依拠しています このようなトラッキングは Safariや メールプライバシー保護 iCloudプライベートリレーの インターネットプライバシー の方向性に相反します

CAPTCHAがアクセシビリティ に深刻な問題を引き起こす 可能性もあります ボットからのアクセスを 防ごうとすることで 障害や言語の壁を持つ 生身の人間も ブロックしてしまうのです もっといい方法があります 初めて みなさんのサイトに アクセスする人でも AppやSafariなどの ブラウザで読み込めば ボットが真似しにくい アクションを既に 多数実行しています まず iPhoneやiPad Macで パスワードやTouch ID Face IDを用いて デバイスのロックを 解除しています Apple IDでサインインする 場合がほとんどです そして コード署名された Appを起動します

この情報があれば CAPTCHAに依拠したり トラッキングでプライバシーを 損なわずに サーバが正当なクライアントか 不正行為かを判断できます プライベートアクセス トークンは サーバがクライアントを 自動的に信頼するために iOS 16とmacOS Venturaに 新たに導入しました トークンの仕組みの 説明に移る前に 実際に使用している様子を お見せします 気に入っていただけると 思います Financial Timesの Webサイトの掲載記事を 読みたいとします 親切な機能に期待しましょう iOS 15搭載機種と プライベートアクセストークンに 対応したiOS 16搭載機種の 2種類で サイトを読み込みました まずは iOS 15の機種から サインインをクリックして アカウントとパスワードを 入力します しかし CAPTCHAが 表示されてしまいます 記事を読むために 文字の入力が必要ですね

プライベートアクセス トークンに対応した iOS 16の機種で 同様に実行すると そのまま素通りできます みなさんの時間を 大幅に節約し 顧客は信頼されていることに 感謝するでしょう IETFのPrivacy Pass ワーキンググループの 技術を使用することで キャプチャが回避できます Appleはこれを実現するため 業界各社と協力しています

このプロトコルを使用すると サーバは 新しいHTTP認証方法である PrivateTokenを使用して トークンがリクエストできます これらトークンは RSA Blind Signaturesを 使用して クライアントが 認証チェックを パスできたという事実を 暗号化しています この暗号は「リンク不可」の ため トークンを 受け取ったサーバは その有効性は確認できても クライアントの身元を 明かしたり クライアントを長時間 認識することはできません プロトコルの仕組みは こうです

まず iOSやmacOSで HTTPからサーバに アクセスすると サーバは PrivateToken認証 チャレンジを送り返して 信頼できるトークン 発行者を指定します

クライアントが トークンを取得する 必要があれば iCloud Attesterに トークンリクエストを 送信します このリクエストは ブラインドされており サーバチャレンジへは リンクできません Attesterはデバイスの Secure Enclaveにある 証明書を使用し 良好なアカウントだと 証明して デバイスを認証します

このAttesterは デバイスが通常通りか 侵害された可能性が あるかを認識するために レート制限の実行や デバイスのファームの一部として 使用される場合もあります

クライアントが認証 できると Attesterは トークンリクエストを 発行元に送ります

トークン発行者は リクエスト受領時に クライアントの情報は 何も知りません iCloud Attesterを 信頼しているため トークンに署名するのです

クライアントは 署名された トークンを受け取り 元のサーバが 検証できるように 「アンブラインド」処理で 変換します

最後に 署名されたトークン をサーバに提示します サーバは発行者により 署名を確認できますが トークンからクライアントの 特定はできません プライベートアクセス トークンを サーバで採用するには ステップが3つあります まず トークンの 発行元を選択します 次に クライアントの 認証を行う場合は HTTP認証チャレンジを 送信します クライアントのトークンを サーバが承認します トークン発行者は トークンに署名する 信頼できる プロバイダで 既存のCAPTCHA プロバイダや Webホスティングサービス CDNとも呼ばれる コンテンツデリバリ ネットワークである 可能性があります iOS 16とmacOS Venturaの ベータ版では 既にテスト可能な 2つの トークン発行元があります プライバシーパスの規格を 策定しているCDNとして FastlyとCloudflareがあり すでに発行者サービスを 公開しています 他のCAPTCHAプロバイダや Webホスティングサービス CDNも Appleのデバイス上で 対応可能予定です register.apple.comで 今年中に可能になる予定です

特定のトークン発行者を 利用するからといって クライアントがアクセス しているWebサイトが 特定されないようにするのが プライバシー上 重要です よって 各トークン発行者は 最低でも数百台のサーバと 連携する 大規模な サービスでないといけません

クライアントがサーバに アクセスする際 PrivateTokenスキームで HTTP認証チャレンジを 送信することで トークンが要求できます 方法は2つあります 既存のCAPTCHAまたは 不正防止プロバイダと連携して そのスクリプトに チャレンジを組み込み 自動的に処理させるか これらのチャレンジを サーバから 直接送信するかを 選択できます

Webサイトの一部として 行う場合 チャレンジは メインURLのサブドメイン であるファーストパーティ ドメインから行い サイトに埋め込まれた サードパーティドメインは 使用しないでください

クライアントから トークンが返ってきたら 発行者の公開鍵を使って 正当性の確認が必要です クライアントがトークンを 複数回提示しようとする リプレイ攻撃を防止する チェックの実施も可能です トークンは1回限りの 利用を想定しています リプレイ攻撃を防ぐには それ以前に送信された トークンを記憶しておくか チャレンジで送信された 固有の値にトークンが 署名することを義務付けます

サイトは この認証 チャレンジに反応しない レガシークライアントと 連携する必要があります 認証はメインページのロード をブロックするのでなく クライアントを信頼する 選択肢となることが重要です SafariとWebKitでアクセス するWebサーバは 自動的に動作しますが App内で直接使用もでき Apple IDにサインイン しているデバイス上で iOS 16またはmacOS Venturaを使用します このApple IDは認証にのみ 使用され トークンを受け取る サーバと共有されません WebKitやURLSessionを使って App内で HTTPによって サーバと通信する時は トークンが利用できます Appがフォアグラウンドに あるときにチャレンジを 受け取ると システムが トークンを送信します

URLSessionを 使用しているなら プライベートアクセストークンを 動作させるために 明示的に何か 行う必要はありません URLSessionは PrivateToken HTTP認証スキームを 使用したチャレンジに 自動的に応答します Appが フォアグラウンドにない時や デバイスにApple IDで サインインしていない時など トークン取得に エラーがある場合は チャレンジを含む 401 HTTP レスポンスを Appが受信します これにより Appは トークンチャレンジの取得が 確認でき ユースケースに応じて 正しいエラー処理ができます 利用可能な場合は CAPTCHAを避けることで AppやWebサイトの ユーザー体験が向上します トークンチャレンジの送信と 検証を サーバで可能にし Appでは URLSession またはWebKitを使用して プライベートアクセストークンを 自動的にサポートしましょう みなさんが作られるCAPTCHA フリーな体験を楽しみにしています