パスキー vs OTP vs SMS認証、自分のサービスにはどれを使うべき？
パスキー、OTP、SMS認証を、フィッシング耐性・実装の難しさ・ユーザーの使いやすさの基準で比較します。小規模なブログから決済サービスまで、状況別にどれを選ぶべきかお勧めします。
目次
ログインのセキュリティ強化策を検討するとき、最初にぶつかる課題は、パスキー、OTP、SMS認証のどの方式を導入するかという点です。3つとも多要素認証（MFA）機能を提供しますが、それぞれの運用の性格には違いがあります。
まずは選定基準を立てる
認証方式を検討するとき、セキュリティ性だけを基準に判断すると結論が偏るおそれがあります。サービス運営の現実的な制約も踏まえ、3つの基準を総合的に検討する必要があります。
- フィッシング耐性：偽サイトに騙されても認証情報が漏れないか
- 実装の難しさ：開発・運用・障害対応にどれくらいのコストがかかるか
- ユーザーの使いやすさ：利用者が最後まで使い続けられ、機種変更時にも復旧できるか
フィッシング耐性を最優先に考える明確な理由があります。現在起きているアカウント乗っ取りの事例の多くは、単純なパスワードの脆弱性ではなく、利用者が偽装されたログインページに直接情報を入力することで発生しています。この経路を根本から遮断できるかどうかが、認証方式どうしの最も大きな違いです。
3つの方式はそれぞれどのように動くのか
SMS認証は、サーバーが6桁の認証番号をSMSで送信し、利用者がそれを手入力する仕組みです。登録手順が簡単なので広く使われています。ただし、利用者が手で入力する過程でフィッシングサイトに情報が流出するおそれがあるほか、SIMスワップや番号の再割り当てといった通信網ベースのセキュリティ上の弱点もあります。こうした理由から、NISTなど主要な標準機関も、電話網ベースの認証を限定的なセキュリティ手段に分類しています。
OTPは一般的にTOTPを指します。Google Authenticatorのようなアプリが30秒ごとにコードを生成し、サーバーが同じシークレットキーをもとに検証する方式です。通信網を使わないのでSIMスワップの心配はありませんが、利用者がコードを自分で入力する必要があるため、リアルタイム中継型のフィッシング攻撃には依然として弱いです。
パスキーは、端末に保存された秘密鍵で署名する方式で、サーバーには公開鍵だけが保管されます。ブラウザがサービスのドメインを確認した後にのみ署名が行われるので、フィッシングドメインでは認証の手続きそのものが遮断されます。利用者が別途判断する余地がないことが、この方式の核心です。
表で一度に比較
| 基準 | パスキー | TOTPアプリ | SMS認証 |
|---|---|---|---|
| フィッシング耐性 | 高い（ドメインへの紐付け） | 中程度（コード入力型） | 低い |
| SIMスワップのリスク | なし | なし | あり |
| 実装の難しさ | 中〜上（WebAuthn、復旧設計） | 中程度（ライブラリを活用） | 低い（ただし送信サービスとの連携が必要） |
| 運用コスト | 低い | 低い | 送信ごとに費用が発生し、海外送信の問題もある |
| ユーザーの利便性 | 高い（生体認証、端末のロック解除） | 中程度（アプリのインストール、コード入力） | 高い（インストール不要） |
| 端末紛失時の復旧 | 設計が必要（同期、代替手段） | 復旧コードが必要 | 番号変更の手続きが必要 |
| 向いている対象 | 主力のログイン手段 | 2段階認証 | 手軽な本人確認、補助手段 |
表で注目したいのは、SMS認証の「実装の難易度が低い」という項目です。コードの生成と送信自体は簡単ですが、送信代行業者との連携、エラー処理、不正利用の防止、費用管理など付随する業務を考えると、単なる機能実装以上に運用面での検討が必要です。
パスキーの導入には反対の立場です。ライブラリのおかげで実装の難易度は大きく下がりましたが、核心的な課題は復旧プロセスの設計にあります。端末を紛失した際のアカウント復旧方法が用意されていなければ、セキュリティ強化とは別に、お問い合わせの急増は避けられないと考えます。
状況別に何を選ぶか
1人のブログや小規模コミュニティ管理者アカウントにはTOTPを優先して適用することをおすすめします。会員数が少なく運用人員も限られていることを考えると、外部への送信費用が発生しない方式が適しています。一般会員の場合は、ソーシャルログインやパスキーのオプションを提供するだけで十分だと思われます。
一般消費者向けサービス（ショッピング、コンテンツ、サブスクリプション）では、パスキーを基本のログイン認証手段として導入し、パスワードとTOTPは補助手段として残す構成が現実的です。既存ユーザーを一度に切り替えるのは現実的に難しいため、ログイン直後にパスキーの設定を促す方法で、少しずつ切り替え率を高めていく戦略が効果的です。
金融、決済、個人情報の機微なサービスでは、フィッシング攻撃による被害の規模を考えると、パスキーを最優先の認証手段として導入すべきです。業種ごとに規制や認証要件が異なる場合があるため、事前に関連基準をご確認ください。また、SMS認証は単独で使うより、補助的な確認手段として運用するほうがセキュリティ上安全です。
社内ツール、管理者コンソールでは、パスキーまたはハードウェアセキュリティキーをおすすめします。ユーザー数が少なく、端末を管理できる環境なので、導入の負担が最も小さい環境です。
SMS認証を必ず使うべき場合もあります。会員登録時に携帯電話の本人確認が必須である場合や、アプリをインストールできないユーザーが多い場合には、この機能をログインのセキュリティ手段ではなく「番号の所有確認」の用途に限定して運用してください。また、むやみな送信を防ぐために、送信回数と試行回数の制限ポリシーを必ず併せて適用してください。
導入の順序の提案
一度に1つだけ選ぼうとせず、段階を分けるほうがよいでしょう。
- まず管理者アカウントにTOTPまたはパスキーを必須にします。
- 一般ユーザー向けには、パスキーの登録を任意のオプションとして開放します。
- 登録率が蓄積されたら、ログイン画面の基本の流れをパスキー優先に変更します。
- SMSは復旧や本人確認などの補助用途にのみ残します。
各段階を終えるたびに、復旧の経路が実際に機能するかを自分で試してみてください。端末を紛失した状況を一度でも再現してみなければ、その経路が最も弱い箇所になります。攻撃者は強い認証を破る代わりに「復旧する」を押すからです。
正解は組み合わせ
フィッシング耐性の面ではパスキーが優れていますが、導入の手軽さではSMSが勝っています。TOTPは費用とセキュリティのバランスを保つ折衷案の役割を果たします。サービスのリスクレベルやユーザー環境を考慮し、パスキーを主認証手段、TOTPを代替手段、SMSを補助手段とする構成が、最も推奨される標準モデルです。
コメント 0
- コメントを読み込んでいます。
