_本記事では、Darnell Andries、Sofia Celi、Rafael Ebron、François Marier、Agustín Ruiz、Szilard Szaloki、エンジニアリング・リサーチチーム、そして多くの素晴らしいメンバーによる取り組みを紹介します。_

本日、 _Braveアカウント_ を発表します。メールエイリアスをはじめとするBraveサービスへのサインアップを実現する、まったく新しい仕組みです。他のサービスとは異なり、パスワードの取り扱い方法は、これまでのどのログインフォームとも違います。

Braveアカウントを基盤とするサービスにサインインする際、パスワードそのものがサーバーに送信されることはありません。暗号化された状態でも、ハッシュ化された状態でも、「一時的にメモリに保持してから破棄」されることもないのです。パスワードは一切送信されないため、Braveがパスワードを安全に保管しているかどうかを信頼する必要がありません。サインアップ時も、ログイン時も、Braveはあなたのパスワードを知ることができません。仮に誰かが明日Braveのパスワードデータベースをすべて盗み出したとしても、パスワードが漏れる可能性は極めて低いのです。

どうすればこれが実現できるのか。暗号技術、具体的には [OPAQUE](https://eprint.iacr.org/2018/163) と呼ばれる暗号化プロトコル（最近 [IRTFによって](https://www.rfc-editor.org/rfc/rfc9807.txt) 標準化されました）を活用しています。Braveはこの新しい暗号技術を世界で初めて採用した組織のひとつです。

## 現行のログインの仕組みが抱える問題

通常のWebサイトにログインする際、何が起きているかを考えてみましょう。ブラウザはTLS接続を確立し、転送中のパスワードを暗号化します。これにより、ネットワークを監視している第三者にパスワードが見えることはありません。では、パスワードがWebサイトのホストサーバーに届いた後はどうなるでしょうか。サーバーは本人認証のために、パスワードの何らかの表現形式（多くの場合ハッシュ値）を保持している必要があります。そのため多くの場合、反対側（アプリケーションに届く前のロードバランサーやCDNの段階）で接続が復号化され、実際のパスワードが平文の状態でそこに存在することになります。サーバーはそのパスワードを [bcrypt](https://ja.wikipedia.org/wiki/Bcrypt) や [Argon2](https://ja.wikipedia.org/wiki/Argon2)（ハッシュに近い仕組み）にかけ、保存されている表現形式と照合します。

「なぜブラウザ側でハッシュ化して、パスワードの代わりにハッシュ値だけを送らないのか」と疑問に思う方もいるかもしれません。その理由は、ハッシュ値がそのままパスワードになってしまうからです。データベースを盗んだ攻撃者は、保存されている値をそのままログインエンドポイントに送り返すだけで侵入できてしまいます。検証はサーバー側で、本物のパスワードに対して行わなければならないため、本物のパスワードを渡す必要があるのです。

しかしこの、パスワードが平文で存在する瞬間こそが、問題の本質です。その瞬間、サーバーはあなたのパスワードを知ることになります。そしてサーバーにアクセスできるものすべてが同様です。リクエストボディをディスクに書き出してしまうログの設定ミス、認証パスに含まれる侵害された依存ライブラリ、悪意のある内部関係者、メモリをスキャンする攻撃者、そのどれもがパスワードを知り得ます。パスワードマネージャーもTLSもここでは役に立ちません。この設計上、秘密情報（パスワード）を渡すことが前提となっているからです。

そしてもうひとつ、情報漏洩のシナリオがあります。パスワードデータベースが流出すると、攻撃者はソルトが付いている場合もあるハッシュ値を入手し、GPUを使ってオフラインで [数十億回/秒](https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%82%AF%E3%83%A9%E3%83%83%E3%82%AF) という速度で総当たり攻撃を開始します。さらに悪いことに、古いプロトコルの多くではソルトが公開されていたり予測可能だったりするため、攻撃者は漏洩が起きる前からコストのかかる処理を済ませておくことができます。 [事前計算テーブル](https://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%A4%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%86%E3%83%87%E3%83%BC%E3%83%96) を構築しておけば、データベースが流出した瞬間に数百万件のアカウントを一気に解読できるのです。これは仮定の話ではありません。 [2012年のLinkedIn情報漏洩](https://krebsonsecurity.com/2016/05/as-scope-of-2012-breach-expands-linkedin-to-again-reset-passwords-for-some-users/) では、 [パスワードデータベース](https://haveibeenpwned.com/Breach/LinkedIn) がソルトなしの [SHA-1](https://ja.wikipedia.org/wiki/SHA-1) という高速ハッシュで保存されており、ユーザー間でエントリに実質的な差異がない状態でした。当初の流出規模は650万件とされていましたが、4年後に全データが表面化すると1億1700万件にのぼり、そのほぼすべてが数日以内に解読されました。同じパスワードは同じハッシュ値になるため、解読作業はクラッキングというよりデータベースの検索に近いものでした。そして、多くの [人がパスワードを使い回している](https://dl.acm.org/doi/10.1145/3176258.3176332) ため、一社のミスが、複数のサービスにわたる実際のユーザーの被害へと波及します。

## OPAQUEの登場

OPAQUEは、拡張パスワード認証鍵交換（ [aPAKE](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement)）プロトコルです。Jarecki、Krawczyk、Xuによる学術研究から生まれ、IRTFクリプトフォーラム研究グループのPAKE選定プロセスで標準化候補に選ばれ、2025年7月に [RFC 9807](https://www.rfc-editor.org/info/rfc9807/) として公開されました。強力な [普遍的合成可能性モデル](https://en.wikipedia.org/wiki/Universal_composability) に基づく形式的なセキュリティ証明も備えています。

基本的な考え方はこうです。クライアントとサーバーが暗号的なやり取りを行い、クライアントはパスワードを _一切明かすことなく_、自分がそのパスワードを知っていることを証明します。そしてやり取りが完了すると、双方が新鮮な秘密のセッションキーを共有し、クライアントはサーバーへのログインが可能になります。このやり取りは楕円曲線暗号のおかげで非常に高速に処理されるため、ユーザーが体感できる影響はありません。

## 実際の仕組み

プロトコルには2つのフェーズがあります。少し専門的な内容になりますが、ここが本当に面白いところなのでぜひ読み進めてください。

**登録**

まずパスワードを設定しますが、デバイスとサーバーは [Oblivious Pseudorandom Function (OPRF)](https://en.wikipedia.org/wiki/Oblivious_pseudorandom_function) と呼ばれる処理を共同で実行します。具体的には、デバイスがパスワードをランダムな値で「ブラインド（隠蔽）」してサーバーに送信し、サーバーは自身が持つ秘密鍵を適用した結果を返します。その後、デバイスがその値のブラインドを解除します。得られる値はあなたのパスワードとサーバーの秘密鍵、 _両方_ から導出されたものですが、サーバーはあなたのパスワードを一切知ることなく、あなたもサーバーの秘密鍵を知ることはありません。「Oblivious（無自覚）」という言葉が示すのはまさにこのことで、両者はお互いの値について何も知らない状態のまま処理が完了します。

次に、デバイスはその値をメモリハード関数（Argon2id）にかけます。これにより、最悪のシナリオでも攻撃者の総当たり試行に高いコストを強いることができます。さらに、その結果をランダムなナンスと組み合わせ、認証用の鍵ペアを決定論的に導出します。パスワードのような秘密情報は、どこにも保存する必要がありません。

デバイスは導出した公開鍵、マスキングキー、そして小さな「エンベロープ（ナンスと認証タグのみを含む）」をサーバーに送信します。サーバーはそれを保存します。エンベロープには暗号化されたパスワードも暗号化された鍵も含まれておらず、あなたのパスワードなしでは意味をなさないデータのみが格納されています。

**ログイン**

再度パスワードを入力します。正しいパスワードを使えば、同じOPRFの処理によって登録時と同じ値が得られます。サーバーは保存しているエンベロープを返しますが、これはマスキングキーでのみ再現できるパッドとXOR演算によって隠蔽されています。そのため、盗聴者は実在するアカウントと存在しないアカウントを区別することができません。デバイスはエンベロープのマスクを解除し、内部のナンスを使って登録時と同じ導出処理を行い、同一の鍵ペアを再生成します。次に、デバイスはエンベロープの認証タグを検証します。パスワードが正しければタグの検証が成功し、デバイスは正しい秘密鍵を保持した状態になります。

続いて、デバイスとサーバーはその鍵を使って [認証付き鍵交換](https://en.wikipedia.org/wiki/Authenticated_Key_Exchange) を実行し、セッション鍵を共有しながら、互いに正当な相手であることを証明します。パスワードが誤っていた場合、導出される鍵は単純に「間違った鍵」となり、認証タグの検証も失敗するため、有用な情報や機密情報が一切ネットワーク上を流れることはありません。

## なぜこれでより安全になるのか

では、なぜこのプロトコルを採用したのでしょうか？パスワードを使うユーザーに、私たちが提供できる最高レベルのセキュリティを届けたかったからです。具体的には以下の通りです。

1. パスワード自体がネットワーク上を流れることは一切ありません。サーバーに平文が届かないということは、うっかりログに残ることも、メモリから盗み取られることも、内部の人間が覗き見することも、「一部のパスワードが平文で保存されていたことが判明しました」という2年後のお詫びブログが出ることも、すべてあり得ないということです。
2. パスワードの大規模な事前計算攻撃は無効化されます。導出処理の一部がサーバー側の秘密鍵に依存しているため、攻撃者はあらかじめパスワードの辞書を作っておくことができません。攻撃を仕掛けるには、データベースとサーバーの秘密鍵の両方を盗み出した上で、ユーザーごとに最初から、 [メモリハード関数](https://en.wikipedia.org/wiki/Memory-hard_function) に対して総当たりを行う必要があります。つまり、万が一漏洩が起きたとしても、攻撃者にとってはアカウント1件ごとに時間とコストがかかる、果てしない作業になります。
3. ログインはゴールではなく、スタートです。OPAQUEはクライアントに _エクスポートキー_ も提供します。これはあなたのパスワードから導出された強力な秘密鍵で、サーバーが知ることは決してありません。この鍵を使えば、すでに覚えているパスワード以外に何も管理しなくても、データをエンドツーエンドで暗号化することができます。

## OPAQUEにできないこと

OPAQUEは非常に優れた暗号技術ですが、いくつか注意点もあります。

フィッシング攻撃をそれ単体では防げません。攻撃者が入力先のページやアプリを制御している場合、プロトコルが実行される前の段階でパスワードを盗み取られてしまいます。

弱いパスワードを強くすることはできません。「password123」のようなパスワードはオンラインの総当たり攻撃に対して依然として脆弱です。だからこそBraveアカウントではレート制限を設けており、強力なパスワードの使用を推奨しています。

サーバーが完全に乗っ取られた場合、執念深い攻撃者はいずれオフラインでユーザーごとの辞書攻撃を試みることができます。OPAQUEによってその攻撃は劇的に遅くなり、ユーザー間での並列処理もできなくなりますが、完全に不可能にするわけではありません。

## なぜこれが本当に優れていて、ユーザーにとって有益なのか

多くのセキュリティ改善は、ミスが起きたときの被害をいかに小さく抑えるか、という発想に基づいています。OPAQUEはそもそも被害の原因となるものを取り除くという発想です。さらに、このプロトコルは「コンポーザブル（組み合わせ可能）」という特性を持っています。OPAQUEはセッションキーとエクスポートキーの両方を返すため、単なるログイン画面ではなく、パスワードを入口とした鍵合意プリミティブとして機能します。これにより、様々な応用が可能になります。

- エンドツーエンド暗号化ストレージ。暗号化キーはあなたのパスワードから導出され、私たちのインフラには一切触れません（ [WhatsAppがパスワード保護付き暗号化チャットバックアップを実装した](https://eprint.iacr.org/2023/843) 仕組みと概ね同じです）。
- デバイスの同期・復元を、なくしてしまうかもしれないコードではなく、自分が記憶しているものを起点に行えます。この仕組みを基盤とした新バージョンの同期も開発中ですので、続報をお待ちください。近い将来、同期とBraveアカウントを連携させることで、現在のQRコードによるペアリング不要で、ログインするだけで新しいデバイスにエンドツーエンド暗号化同期を導入できるようになります。アカウントなしの同期オプションも引き続きサポートされます。サービスを使うためにアカウントを作りたくない方も、これまで通りご利用いただけます。

Braveアカウントは、新しい [メールエイリアスサービス](/content/ja/privacy-updates/39-email-aliases/index.html) の基盤として機能します。今後も増えていくBraveの各種サービスを支えるプラットフォームとして、継続的に拡充していく予定です。

## はじめ方

Braveアカウントは本日より利用可能です。`brave://settings/getStarted` にアクセスし、バナーの案内に従ってアカウントを作成できます。

フィードバックは、日本語のユーザーサポート窓口( [jpsupport@brave.com](mailto:jpsupport@brave.com))までぜひご連絡ください。