パスワードマネージャーのおすすめ

通常のマスターパスワードでログインする Bitwarden アカウントでは、クライアントがマスターパスワードやアカウントのメールアドレスなどを入力に KDF を実行し、Master Key を得ます。さらに HKDF で展開して Stretched Master Key を導出し、サーバーから取得した Protected Symmetric Key を開いて、User Symmetric Key を得ます。データの復号はクライアント側で実行します。これは概念的な流れであり、個々の項目の暗号鍵や別のログイン方式は省略しています。[01]

Master Password + account salt
    ↓ KDF（PBKDF2 または Argon2id）
Master Key
    ↓ HKDF（用途ごとの鍵素材へ展開）
Stretched Master Key
    + サーバーが保存する Protected Symmetric Key
    ↓ 端末内で開く
User Symmetric Key
    ↓ Vault 項目に関連する鍵と暗号文を復号
Vault の平文（認証済みデバイスで必要な時だけ使用）

区別しておきたいのは、「ログインの認証」と「Vault の復号」です。ログインでは通常、サーバーで検証できる派生ハッシュや MFA も使います。復号には、実際の対称鍵が必要です。マスターパスワードの変更、KDF パラメーターの調整、Vault の暗号鍵のローテーションは別の操作です。パスワードを変えれば、攻撃者が保存済みの古い暗号文が即座に無効になるとは考えないでください。[22]

KDF の入力は、人が覚えやすい一方でエントロピーが不足しがちなマスターパスワードです。ソルト（salt）と高コストの計算によって、攻撃者が推測のたびにコストを払う必要があるようにします。ソルトは通常、秘密にする必要がありません。目的は、同じパスワードでもアカウントごとに異なる出力を得ることと、事前計算した表を使い回しにくくすることです。

PBKDF2-HMAC-SHA256(P, salt, c, dkLen)
P      = マスターパスワード
salt   = 秘密ではないソルト
c      = 反復回数
 dkLen = 出力する鍵の長さ

Argon2id(P, salt, m, t, p)
m = メモリーコスト
 t = 時間／反復コスト
 p = 並列度

Bitwarden の文書に記載された既定値の参考：PBKDF2-HMAC-SHA256：600,000 iterations；Argon2id：32 MiB、6 iterations、parallelism 4。PBKDF2 は主に反復計算を増やし、Argon2id はメモリーも要求することで、大規模な並列推測を安価に行いにくくします。600,000 と 6 を直接比較することはできません。処理のモデルがまったく異なるためです。[02]

単純化したコストモデルでは、総推測時間 ≈ 推測回数 × 一回の推測コスト ÷ 有効な並列数となります。ただし GPU、メモリー帯域、KDF のパラメーター、ハードウェア構成によって結果は大きく変わります。ロック解除にかかった秒数から、信頼できる解析所要時間を直接算出することはできません。長く独立したマスターパスワードが、依然として第一の防御線です。

「AES-256」は鍵の長さを表すもので、暗号化プロトコル全体の安全性を示すものではありません。データそのものの暗号化に加え、完全性の検証も必要です。そうでなければ、攻撃者による暗号文の改変を確実に検知できない可能性があります。

• Bitwarden：AES-256-CBC + HMAC-SHA256。CBC が機密性を担い、HMAC が暗号文の完全性を追加で検証します。安全性は、適切な IV、鍵の分離、検証の順序にも依存します。
• 1Password：AES-256-GCM。GCM は暗号化と認証を統合した AEAD モードです。同様に nonce／IV の適切な管理が必要で、再利用してはならない nonce を再利用してはいけません。

CBC や GCM という名称だけで、製品全体のどちらが安全かは判断できません。エンドポイント、鍵管理、事故からの復旧も同じくらい重要なことが多いからです。[03][05]

TOTP は HOTP を基にしています。サイトと認証器はランダムな秘密のシード K を共有し、現在時刻をカウンター T に変換してから、HMAC の結果を短い数字へ変換します。[11]

T = floor((UnixTime − T₀) / X)
H = HMAC(K, encode_8_byte_big_endian(T))
OTP = DynamicTruncate(H) mod 10^d

K  = 共有された秘密のシード
T₀ = 基準時刻（通常は Unix epoch）
X  = 時間窓の秒数（通常は 30）
d  = 出力桁数（通常は 6）

RFC 6238 は HMAC-SHA-1／256／512 をサポートします。実際のサービスではシード、桁数、時間窓が一致していなければなりません。6 桁のコードの候補は全部で 10^6 通りしかないため、サーバー側にはログイン失敗のレート制限、時刻のずれへの対応、リプレイの確認が必要です。30 秒以内なら無制限に推測してよいわけではありません。

QR コードには、秘密のシードや、シードを復元できる設定 URI が含まれることがよくあります。通常のログイン用 QR コードだと思ってグループに共有しないでください。K を入手した人は、以後の時間窓のコードを自分で計算できます。

登録（registration）時には、認証器が特定の RP 向けの公開鍵・秘密鍵のペアを生成し、サイトが Public Key と Credential ID を保存します。ログイン（authentication）時には、サイトが予測できない Challenge を発行し、ブラウザーと認証器が Assertion を生成して、サーバーが検証します。[13]

登録：
  Authenticator → (private key, public key)
  Server        ← public key + credential ID

ログイン：
  Server → challenge
  Authenticator → signature over
    authenticatorData || SHA256(clientDataJSON)
  Server checks:
    challenge / type / Origin
    rpIdHash / UP・UV flags（ポリシーによる）
    signature / credential binding

Origin は WebAuthn API を呼び出すサイトのオリジンを表し、RP ID は資格情報を使用できる依拠当事者の範囲です。偽サイトが自由に本物のサイトの RP ID を名乗ったり、本物のサイト向けの有効なアサーションを取得したりすることはできません。サーバー側も確実に確認する必要があり、署名だけを検証して文脈を無視してはいけません。

「フィッシング耐性」は「すべてのアカウント乗っ取りへの耐性」ではありません。ログイン済みのセッション Cookie、悪意あるブラウザー拡張、弱い復旧フローなどは、別の侵入口になり得ます。[12]

パスキーは FIDO 資格情報を利用してログインする方法です。指紋、顔認証、デバイスの PIN を使う時は、通常は端末内で認証器を解除しているのであって、生体情報をサイトへ送っているわけではありません。

• Device-bound：資格情報が特定の認証器やデバイスに結び付いています。通常はハードウェアによる分離がより明確ですが、予備のキーが必要です。
• Synced Passkey：提供者が保護する同期の仕組みによって、複数のデバイスで利用できます。復旧は容易になりますが、同期アカウントとデバイスを特に慎重に保護する必要があります。

「秘密鍵は絶対にエクスポートできない」を、すべてのパスキーに当てはめることはできません。ログインできる仕組みと、パスワードマネージャーの Vault を解除する仕組みも、異なる場合があります。例えば、パスキーから Vault の復号用素材を導出するために、WebAuthn PRF のサポートが必要な設計もあります。[01][13]

1Password はデバイス上で約 128 bits のエントロピーを持つ Secret Key を生成し、Account Password とともにアカウントの暗号鍵を保護します。これはアカウントの通し番号でも、もう一つ暗記するパスワードでもありません。Secret Key は認証済みデバイスや適切な Emergency Kit に保存します。[04]

SRP（Secure Remote Password） はログイン時の本人認証に使うもので、Vault のデータ暗号化とは別です。設計上の目的は、利用者が入力した元の Account Password を受け取ることなく、サーバー側でパスワードの証明を検証できるようにすることです。[19]

攻撃者がサーバーの暗号化データだけを入手した場合、Secret Key がないことはオフライン攻撃への追加の障壁になります。しかし、認証済みデバイスも支配している、Secret Key を入手した、復旧資料を得た、といった場合には、「サーバー側だけの漏えい」という安全性の推論をそのまま適用できません。

Bitwarden の Base domain は実効的な登録可能ドメインを参照し、Host はホスト名を制約し、Exact は URI 全体の完全一致を要求します。機密性の高いサブドメインでは Host／Exact に変更した方がよい場合もありますが、Exact はパスやクエリー文字列の変更で一致しなくなる可能性があります。Android や iOS では、照合できる情報が OS の API に制限される場合もあります。[18]

Bitwarden の「Autofill on page load」は既定で無効です。公式にも、侵害されたサイトがこの利便性を悪用できることが説明されています。手動で入力を開始する、URL を確認する、不審な iframe を避けるといった行動には意味があります。ただし、認証情報を実際に悪意あるページの入力欄へ渡してしまったら、URL の照合だけで、その欄をページ内のスクリプトが読み取ることを防ぐことはできません。[09]

クリップボードの自動消去タイマーは、情報が残る時間を短くするだけです。あらゆるクリップボードの読み取りを防ぐセキュリティサンドボックスと考えてはいけません。

デバイス間の同期は主に現在のデータを一致させるもので、アカウントがロックされたり、すべての端末を失ったりした時に過去のデータを取り戻せる保証ではありません。Bitwarden では、Password protected encrypted JSON は別途設定したパスワードで保護され、別のアカウントにもインポートできます。一方、Account restricted は元のアカウントの暗号鍵に依存するため、別アカウントへの災害復旧の唯一の備えには適していません。[16]

通常の暗号化 JSON エクスポートには、添付ファイルが含まれません。添付ファイルを含む ZIP エクスポートも、別途暗号化コンテナーで保護する必要があります。拡張子が ZIP だから暗号化されているとは考えないでください。Vault にログインできない時でも、復旧資料にアクセスできる必要があります。

最も簡単な実地確認は、オフラインで保管した復旧コードが見つかること、バックアップを復号できること、テスト環境にインポートできることを確認し、添付ファイルを別途チェックすることです。必要なら隔離環境で行い、テストのために共有コンピューターへ本物のマスターパスワードを入力しないでください。