Webシステムのログイン認証はパスワードだけで十分なのか？

Web

Webシステムのログイン認証とは

ログイン認証とは、Webシステムへのアクセス時に利用者が正当な本人であることを確認する仕組み
パスワード認証には、情報流出、使い回し、総当たり攻撃、フィッシングなどのリスクがある
MFA（多要素認証）は、異なる認証要素を組み合わせることで不正ログインのリスクを軽減する方法
メールによる追加認証は導入しやすい一方、メールアカウントの安全性や配信環境に依存するため、強固なMFAと同等ではない
ログイン試行回数制限は、パスワードの推測や繰り返しの認証試行を抑制するための対策
認証方式の選択では、安全性だけでなく利用環境、アカウント管理、認証手段の紛失時の復旧方法なども考慮する必要がある

Webシステムのログイン認証では、パスワードの流出や不正利用を想定した対策が重要になります。MFA（多要素認証）やメールによる追加認証、ログイン試行回数制限などを組み合わせることで、不正ログインのリスクを軽減できます。ただし、認証方法によって安全性や運用上の課題は異なります。システムの構成や利用環境に応じて適切な認証方法を選び、アカウント管理や認証できなくなった場合の復旧まで含めて設計することが重要です。

Webシステムの入口となるログイン認証

Webサイトのセキュリティを考えるとき、管理画面のログイン認証は重要な対策の一つです。

WordPressなどのCMSをはじめ、ECサイトの管理画面、会員システム、独自に開発された業務システムなど、多くのWebシステムにログイン機能があります。

一般的には、IDとパスワードを入力して本人確認を行います。

しかし、IDとパスワードが正しければログインできるということは、その情報を第三者に知られれば不正にアクセスされる可能性があるということです。

管理画面には、コンテンツの編集、商品管理、顧客情報の閲覧、注文処理、システム設定など、さまざまな機能があります。

特に管理者権限が奪われた場合、情報の改ざんや漏えいだけでなく、システムの設定変更や不正なプログラムの設置につながる可能性もあります。

そのため、ログイン認証は単にパスワードを設定すればよいというものではありません。では、どのような対策が必要なのでしょうか。

パスワード認証だけでは防げないリスク

パスワード認証には、いくつかのリスクがあります。

代表的なのが、パスワードの使い回しです。

あるサービスから流出したIDとパスワードが別のサービスでも使用されていれば、その情報を使ってログインを試みることができます。

これはパスワードリスト攻撃と呼ばれる手法です。

また、考えられるパスワードを繰り返し入力する総当たり攻撃や、偽のログイン画面へ誘導して認証情報を盗み取るフィッシングもあります。

複雑なパスワードを設定していても、フィッシングによって入力情報が盗まれれば、その複雑さは防御になりません。

そのため、パスワードには十分な長さと使い回しを避ける運用が必要ですが、それだけですべてのリスクを防げるわけではありません。

特にWebシステムの管理画面では、パスワードが第三者に知られた場合にも、不正ログインを防ぐ仕組みを考える必要があります。

MFA（多要素認証）でログインを強化する

その対策の一つがMFA（Multi-Factor Authentication）です。

MFAは、多要素認証と呼ばれます。一般的に、認証要素には次の3つがあります。

知識要素：パスワードやPINなど、本人が知っている情報
所持要素：認証用端末やセキュリティキーなど、本人が持っているもの
生体要素：指紋や顔など、本人の身体的な特徴

MFAとは、これらの異なる要素を組み合わせて本人確認を行う方法です。

例えば、パスワードを入力した後に、スマートフォンの認証アプリに表示されるワンタイムコードを入力する方法があります。仮にパスワードが流出しても、認証アプリを利用できなければログインを完了できないため、不正アクセスのリスクを減らせます。

ただし、MFAも万能ではありません。ワンタイムコードを偽のサイトに入力させるフィッシング攻撃などには注意が必要です。

一方、FIDO2/WebAuthnを利用したパスキーには、正規のWebサイトと認証情報を結び付けることでフィッシングへの耐性を高める仕組みがあります。

パスキーは、適切な構成であればパスワードを使用せずに多要素認証を実現することもできます。重要なのは、単に認証手順を増やすことではなく、異なる仕組みを組み合わせて本人確認の安全性を高めることです。

メール認証はMFAと同じなのか？

Webシステムでは、メールを使った追加認証も採用されています。

IDとパスワードを入力した後、登録済みメールアドレスへ確認コードを送信し、そのコードを入力してログインする方法です。

メール認証には、比較的導入しやすいというメリットがあります。専用の認証アプリを用意する必要がなく、普段利用しているメール環境で確認できます。既存のCMSや独自システムに追加する場合も、利用者の操作を大きく変更せずに導入できることがあります。

ただし、メール認証とMFAを同じものとして考えるべきではありません。

メールアカウントへのアクセスがパスワードだけで可能な場合、Webシステムとメールの両方が同じ攻撃によって侵害される可能性があります。さらに、メールアカウント自体が第三者に奪われていれば、確認コードも取得されてしまいます。

米国国立標準技術研究所（NIST）の認証ガイドラインでは、メールを帯域外認証の手段として使用することを認めていません。

つまり、メールによる追加認証はパスワードだけの場合より防御を増やせる可能性がありますが、独立した認証要素を用いるMFAと同等の安全性があるとはいえません。

また、メール認証には運用上の課題もあります。メールの配信が遅延すればログインに時間がかかります。メールサーバーに障害が発生すると、認証コードを受信できず、管理画面へ入れなくなる可能性もあります。メール認証を採用する場合は、安全性だけでなくメール配信の信頼性も考える必要があります。

ログイン試行回数の制限も重要になる

ログイン認証を強化する方法は、MFAやメール認証だけではありません。ログイン試行回数の制限も有効な対策です。

例えば、短時間に何度もパスワードの入力を間違えた場合、一時的にログインを制限する仕組みがあります。これにより、パスワードを繰り返し推測する攻撃を難しくできます。

ただし、ログイン試行回数を制限すればよいという単純な話でもありません。例えば、一定回数の失敗でアカウントを完全にロックしてしまうと、第三者が意図的にログインを失敗させることで、正規の利用者をログインできない状態にする可能性があります。また、IPアドレスだけを基準に制限しても、複数のIPアドレスから攻撃される場合には十分な効果を得られません。

そのため、アカウント単位の試行回数管理、時間による制限、段階的な待機時間などを組み合わせる方法があります。

管理者への通知やログの記録も、異常を把握するために有効です。ワンタイムコードについても、有効期限、使用回数、入力試行回数、再送回数などを適切に管理する必要があります。

ログイン試行回数の制限は、不正アクセスを防ぐための対策であると同時に、正規の利用者の操作を妨げない設計が求められます。

WordPressと独自CMSでは導入方法も異なる

実際のWeb制作・運用では、どの認証方式を選択するのかという問題があります。

WordPressの場合、MFAに対応したプラグインなどを利用して認証を強化することができます。一方、独自CMSでは、そのような機能が標準で用意されていない場合もあります。

認証アプリへの対応には、初期登録、秘密情報の管理、認証コードの検証、端末変更時の対応などを実装する必要があります。メール認証の場合も、認証コードの生成、送信、検証、有効期限、再送、試行回数制限などの仕組みが必要です。

ここで重要なのは、どの方法が簡単かということだけではありません。例えば、管理者が少数で機密情報を扱うシステムであれば、認証アプリやパスキーなど、より強固な認証方法を優先することが考えられます。

一方、既存システムの仕様や利用者の環境によっては、メールによる追加認証を現実的な改善策として検討する場合もあります。

ただし、その場合もメール認証の限界を理解し、試行回数制限などの別の対策と組み合わせる必要があります。

また、管理者全員が同じアカウントを共有している場合、認証を強化するだけでなく、利用者ごとにアカウントを分けることも検討すべきです。

誰がログインしたのかを把握できなければ、不正な操作や問題が発生した際の調査が難しくなります。認証の仕組みだけでなく、アカウントの管理方法も重要になります。

認証を強化した後の運用まで考える

認証を強化すると、運用上の新たな課題も生まれます。例えば、認証アプリを使用しているスマートフォンを紛失した場合、どのようにログインを復旧するのでしょうか。担当者が退職した場合、登録された認証方法を誰が変更するのでしょうか。メール認証を使用していてメールが届かない場合、どのように対応するのでしょうか。こうした問題を事前に考えておく必要があります。

特に認証方法の再設定や解除は、通常のログインとは別のリスクがあります。本人確認が不十分なまま認証設定を変更できれば、攻撃者が正規の認証手順を回避できる可能性があります。そのため、認証方法の変更時には再認証を求める、復旧用コードを安全に管理する、管理者による変更履歴を残すなどの対策が重要です。

さらに、認証方式を導入した後も、利用者の追加・削除や権限の見直しが必要になります。セキュリティを強化するための機能が、運用できない仕組みになってしまっては意味がありません。技術的な安全性と日常的な運用を両立させることが、Webシステムの認証設計では重要だと考えます。

ログイン認証はシステムを守るための第一歩

Webシステムのログイン認証では、パスワードだけに依存しない仕組みが重要になります。MFAによる認証強化、メールによる追加確認、ログイン試行回数の制限など、複数の方法があります。

しかし、すべてのシステムに同じ認証方法が適しているわけではありません。扱う情報の重要性、利用する管理者の人数、既存システムの構成、運用負荷などによって適切な方法は変わります。

そして、ログイン認証を強化しても、Webシステム全体を守れるわけではありません。プログラムの脆弱性やサーバーの設定不備など、ログイン画面を経由しない攻撃も存在します。そのため、認証強化は重要ですが、セキュリティ対策の一部として考える必要があります。

パスワードだけで十分なのか。
どの認証方法を追加するのか。
ログイン失敗時にどのような制限を設けるのか。
認証できなくなった場合にどう復旧するのか。

これらを個別の機能としてではなく、一つの仕組みとして設計すること。Webシステムのログイン認証では、安全性だけでなく、継続して管理できる運用まで含めて考えることが重要だと思います。

参考文献・関連資料

執筆・編集：西部俊宏: 株式会社Webの間代表取締役。上場企業でのSEOやWebサイト構築実績多数。ECサイトのカスタマイズ経験も多数あり。; 会社概要はこちら

私たちは、ECを業務に合わせて設計・構築します。
カスタマイズ前提だからこそ、これまで実現できなかった要件にも対応できます。

「できない」を、実現するEC構築について