認証

セキュリティ 技術情報 コラム

初投稿の担当者です。
今回は認証について整理しましたのでご紹介したいと思います。

当人認証（Authentication）

ここでいう認証とは当人認証（Authentication）のことです。
似た言葉として身元確認（Identity Proofing）がありますが、身元確認とは行政などが本人であることの確認を行い、その確認書類等をもって当社のような事業者が本人であること確認を行います。その後、その身元確認した人が、ある操作において、その本人であることを確認するための仕組みが当人認証となります。

今回、当人認証を設計、実装するにあたりシステム目線で重要ポイントを整理しました。

◯◯認証の違い

ニュースを見ていると二段階認証（2FA）、多要素認証、二要素認証、などいろいろな言葉が（ほぼ）同一の意味として使われていますね。それぞれの違いについて意識して整理してみます。

多要素認証（Multi Factor Authentication）

「知識（記憶）」「所持」「生体」の認証要素のうち、2種類以上を用いて認証を行うこと、です。

二要素認証（2 Factor Authentication）

上記の認証要素のうち、2種類だけの認証要素を用いた認証を指します。

二段階認証（2 Step Authentication）

認証を複数回行うことを指し、要素の数は問いません。

上記以外にも二経路認証（2 Channel Authentication）といったものもあります。ログイン時にログインパスワードで認証し、その後認証アプリ等でログインをする場合、二要素認証でもあり多要素認証でもあり、二段階認証でもあります。ログイン時にログインパスワードを入力し、取引時に取引パスワードを入力するのは二要素（多要素）認証ではなく二段階認証であると言えます。また、メールを使って認証コードを送信し、そのコードを入力する方法を所持認証とするケースが多いと思いますが、NIST SP800-63Bなどでの議論が続いている部分かと思います。SMS認証についても実態として日本では少ないようですが、SIMスワッピングのリスクについても少なくない意見があるように思います。

さて、各要素における設計時のポイントを紹介していきます。
各要素共通の設計として、認証が試せる回数に上限を設け、上限を超えた場合はロックする、あるいは正しい認証でも成功にしない、といった条件を必須とします。

パスワード

知識認証の代表格、大昔から使われている認証方法です。歴史が長い分、リスクと対策も時代と共に変化してきています。例として、パスワードは定期的に変更すること、パスワードは英字、数字、記号を組み合わせること、などがリスクあるものと認識され始めているかと思います。最近の議論では、使い回さないこと、長いパスワードとすること、などがスタンダードになっています。
設計時のポイントとしては、

  • 一定のルールを課すことは必要（最低桁数、パスワード強度メーターの提示、等）

  • 大切なこととしてパスワードをデータベース等に保存する際、不可逆化（ハッシュ化）をすること

  • 暗号化の方式としてはCRYPTREC暗号リストを参照するようにしています。これは外部犯によるデータ搾取に加え、内部犯行による流出リスクの低減を目的としています

TOTP認証（Time-based One-Time Password、認証アプリ）

30秒（デフォルト）毎に変化する認証コードを入力していただき認証する方法です。セットアップに一手間かかりますが、一度設定するとSMS認証やメール認証のような通信が発生しないため、SMSやメールの通信環境に影響されずに認証を行うことができる点がメリットです。また利用するパスワード管理アプリによっては自動入力されるので、SMSやメールを待つ認証方法に比べ、受信時の待ち時間分だけUXが良い場合もあります。

設計時のポイントとしては、

  • 一般的に出回っている認証アプリの登録時のデフォルトを考慮し時間間隔を30秒毎にすること

  • ワンタイムパスワードという用語を使う場合は同じ30秒の間に同じコードが入力された場合に2度目以降は拒否すること

  • 登録時のUXを良くすること（QRコードの表示だけでURLをクリックできるようにする、等）

  • 確認コードをコピペできるようにする場合は保存方法について丁寧な説明を心がけます

  • また、利用者には見えない部分として、30秒間しか表示されない認証コードですが、きっちりその時間が過ぎると認証NGとするのではなく、その前後の時間で入力された場合にも有効期間の幅を伸ばし認証成功とするか、といったタイムステップについても考慮します

SMS認証

所持する携帯電話にSMS（ショートメッセージ）で認証コード等を送り認証する方法です。

前述の乗っ取りや盗聴のリスクが言われていますが利用者にとっての手軽さから幅広く利用されている認証要素です。偽基地局や警察に偽装した電話番号のニュースもあるので事業者側でリスクのコントロールが難しい技術でもあります。

設計時のポイントとしては、

  • 再送間隔や認証コードの有効期間を適切に設定すること

  • セキュリティ的な安心感をもってもらうため0005共通番号への対応などを検討します

  • 当社は国内のみのサービスのため４キャリアへの直接接続としていますので、再送間隔や有効期間はメールよりは短いものとしています

メール認証

メールアドレス宛に認証コードを送付し認証する方法です。メールを起点としたサイバー攻撃が後を絶ちませんが、20年以上も前の技術をベースとし、ツギハギでセキュリティ対策が行われたものでメールプロバイダによりセキュリティ対策がバラバラであることが課題です。

最近のトレンドを踏まえたポイントとしては、

  • インフラ観点ではSPF/DKIM/DMARCへの対応

  • Google/Yahooのメール送信者ガイドラインを考慮すること

  • アプリケーション設計の観点では、SMSと同様に再送間隔や認証コードの有効期間を適切に設定するようにしますが、再送間隔や有効期間はSMSよりはメール世界が複雑怪奇であることも考慮し、SMSよりは長く設定しています

パスキー認証（FIDO2）

少し前までフィッシング耐性のある多要素認証、つまりAAL3相当の認証とは、ハードウェアトークン、またはクライアント証明書による認証など、導入に一定のハードルがある限られたものしかありませんでした。しかしFIDO2（パスキー）への対応を各メーカーが行ったことにより、ソフトウェアベースでのフィッシング耐性のある認証を提供できるようになりました。また、パスキーは同一エコシステム内でそのパスキーが共有されるため機種変更や紛失時のリカバリがOS側で対応することもできる技術となっています。

パスキー認証とは、唯一の秘密鍵が端末に存在し、その鍵が外に出ないこと（＝所持認証）、そして認証時には生体認証またはパスコード（＝知識認証）を使い、端末と事業者側の双方の確認を行うことから、中間者攻撃に強い仕組みです。

パスキーの導入に際して考慮すべきポイントは、

  • 理想としては、１つのパスキーを登録し、そのパスキー以外の認証を認めない（≒パスワードレス）形を目指したいところです

  • ただ実際には、登録時はOTPを用いた登録となることや、クロスデバイス（例えば
    WindowsとiPhone）でサービスを提供する場合には、２つめ以降のパスキーを許容することも検討します

  • 特に再設定（リカバリ）については、IALの要件も考慮する必要があるとNISTでは述べられており慎重な検討が必要です

  • UXの良さがそのままセキュリティ向上につながる構造を意識します。パスキーのように、一度登録すれば他のログインでも自然に使える仕組みは、ユーザーの負担を減らしながら、高い認証強度を維持することができます

今回は、「当人認証」の代表的な認証方式について、設計上のポイントを交えて紹介しました。セキュリティとUXの両立は難しく、正解がひとつとは限りませんが、利用者目線と最新のガイドラインを意識した設計が求められる時代です。ご参考になれば幸いです。

人材募集