ファイルの二要素認証：追加セキュリティレイヤー

ファイルの二要素認証は、受信者が知っていること（ PBKDF2 経由で AES-256-GCM 鍵を導出するパスワード）と受信者が持っているもの（ Authy からの TOTP コード、メールマジックリンク、またはデバイスにバインドされた WebAuthn パスキー）を組み合わせます。攻撃者がパスワードをフィッシングしたりダウンロード URL を傍受したとしても、第2要素なしでは暗号化されたペイロードを復号できません。このパターンは、 WeTransfer スタイルのサービスで一要素共有を無効化するリンク転送、クレデンシャルスタッフィング、そしてほとんどの肩越し攻撃を防ぎます。

リンク1つのパスワードでは不十分な理由

共有ダウンロード URL は予想以上に漏洩しやすいものです。 Slack は自動展開してプレビューを生成し、 Gmail は7年間アーカイブし、企業プロキシはクエリ文字列全体をログに記録します。パスワードが別のメールに入っていても、両チャンネルが同じ受信トレイであることが多く、 Microsoft 365 の一度の侵害でファイルが渡ってしまいます。 Verizon DBIR 2025の実際のインシデントレスポンス事例の調査では、クレデンシャルベースのデータ窃取の68%が再利用されたパスワードを含むことが示されています。第2要素を追加することでこの連鎖を断ち切れます。 TOTP シードは受信者の認証アプリから外に出ることがないからです。

ダウンロードリンク上での TOTP の仕組み

送信者はbase32文字列と QR コードとしてエンコードされた160ビットの共有シークレットを生成します（RFC 6238）。受信者はそれを Google Authenticator 、 1Password 、または Yubico Authenticator でスキャンします。30秒ごとにアプリはシークレットと30で割った Unix タイムスタンプに対して HMAC-SHA1 を実行し、結果を6桁に切り詰めます。受信者がそのコードを入力すると、サーバーは現在のウィンドウと前のウィンドウを確認してクロックドリフトを許容します。コードが検証された後にのみサーバーは暗号化されたブロブをリリースします。復号鍵自体は受信者のパスワードから導出されクライアント側に留まります。

軽量な第2要素としてのメールマジックリンク

すべての受信者が認証アプリをインストールするわけではありません。あらかじめ宣言されたアドレスに送信されるマジックリンクが合理的なフォールバックです。送信者はアップロード時に jane@hospital.org と入力し、サービスはそのアドレスの SHA-256 ハッシュを保存します。 Jane がダウンロード URL をクリックすると、サーバーが10分間有効な128ビットのランダムトークンをメールで送信します。トークンをクリックするとファイルパスワードを入力するダウンロードページが開きます。トークンは彼女のメールボックスにバインドされているため、同僚に転送されたリンクは無効です — 同僚はメールチャレンジを受け取っていないためです。

定期的な受信者のための WebAuthn とパスキー

毎週ファイルを交換するチーム（例：PCI DSS 4.0 のエビデンスを受け取る監査人）では、パスキーがコードよりも優れています。受信者は初回使用時に FIDO2 クレデンシャルを登録します。秘密鍵は Secure Enclave または YubiKey 5C に保存されます。その後のダウンロードは TOTP の再入力の代わりにタッチで済みます。署名にオリジンが含まれているため、実際のダウンロードページをプロキシするフィッシングサイトは認証を再生できません。 Chrome 、 Safari 17 、 Firefox 122 はすべて、追加クリックなしでパスキープロンプトを表示する条件付き UI をサポートしています。

チャンクごとの大容量転送の保護

10GBの DICOM アーカイブや4GBの Adobe Premiere プロジェクトは単発ダウンロードモデルに収まりません。ペイロードを5MBのチャンクに分割し、それぞれを HKDF（RFC 5869）経由でマスター鍵から導出されたサブキーで暗号化します。チャンクを提供する前に、サーバーは2FA 成功後に発行された新鮮なセッショントークンを検証します。トークンは例えば30分後に失効するため、一時停止されたダウンロードは数日後に盗まれた Cookie から再開できません。これは Signal が音声ノートセグメントを処理する方法や Backblaze B2 がマルチパートアップロードにサーバー側認証を適用する方法と同じです。

レート制限、ロックアウト、オフライン攻撃の罠

TOTP は6桁のみのため、安易なエンドポイントでは攻撃者が100万通りの組み合わせを数秒で試せます。3回の誤入力後に指数バックオフを実施し、10回後にリンクをロックし、送信者に webhook を送信します。攻撃者にパスワードとコードのどちらで失敗しているかを教えないでください — 両方に対して同じ汎用エラーを返します。 TOTP 検証は絶対にクライアント側に置かないでください。シークレットをブラウザに送信すると目的が失われます。 Cloudflare Turnstile または hCaptcha の背後にある堅固なエンドポイントでサーバー側で検証します。

モデルを弱めないリカバリー

古典的な失敗は48時間の転送ウィンドウ中に受信者が電話を紛失するケースです。リンク作成時に印刷された20文字の base32 文字列として緊急コードを組み込むことで、メール依存なしのフォールバックを提供します。同様に重要なのは、第2要素が使用されなくても転送をダウンロード後に失効させることです。リカバリーコードを含む紛失したノートパソコンを1か月後に悪用できないようにするためです。 HexaTransfer などの一部のサービスでは、送信者がダッシュボードからリンクを無効化し、進行中のセッショントークンを無効にすることもできます。

ユーザー体験へのコスト

30秒の転送に2FA を追加することは重く感じられるため、リスクに合わせて調整します。誕生日のフォトアルバムにはスキップします。製品ローンチの500MBの .psd ファイルにはパスワードを要求します。GDPR第15条の情報開示データの2GBアーカイブには TOTP とマジックリンクの両方を要求します。階層化された UI（パブリック、パスワード、2FA、パスキー）により、送信者がドキュメントを読まずに選択できます。 SwissTransfer は単一のパスワードトグルを公開し、 Dropbox Transfer は Teams プランの背後に2FA を隠し、 Smash はメール検証を提供するが TOTP は提供しません。このギャップは埋める価値があります。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。