EC News ECサイトで見落とされがちなログインIDとパスワードのセキュリティ

こんにちは。株式会社セキュアスカイ・テクノロジーの西尾です。

第三回では、第二回の「パスワードリスト攻撃」に関連して、ECサイトで発生しやすいログインIDとパスワードに関する脆弱性の概要と対策についてやさしく解説していきます。

ECサイトで発生しやすい脆弱性を調査

みなさんはECサイトで発生しやすい脆弱性をご存じでしょうか？
今回は、過去に弊社が行った脆弱性診断の結果から、ECサイトで発生しやすい脆弱性を調査してみました。

過去5年間に弊社が行った脆弱性診断から、ECサイトでよく見つかる脆弱性と、ECサイトを含む全種類のサイトでよく見つかる脆弱性の上位5つを比較したものが下の表になります。

「※」が付いている項目は、弊社では脆弱性という扱いをしていませんが、セキュリティをより高めていただくために報告している項目です。

上表を見ると分かるように、全サイトと比較するとECサイトでは特に「登録済みのログインIDが判明」と「パスワードの認証強度が不十分」の報告数が多い特徴があります。

「登録済みのログインIDが判明」とは、ログイン時などのエラーメッセージから、Webサイトに登録されているログインIDが間接的に漏えいする脆弱性です。DB（データベース）などから直接的に窃取する攻撃とは異なります。

「パスワードの認証強度が不十分」は、アカウントを新規作成する際のログインパスワードの要件がかなり緩い場合に報告する項目です。

ここからは、この二つの脆弱性の概要と対策について詳しく解説していきます。

ログインIDが判明する脆弱性の概要と対策

WebサイトのDBから直接的にログインIDを窃取せずとも、Webサイトの機能を悪用することで間接的にログインIDを取得可能な場合があります。

もしログインIDが漏えいしてしまうと、そのWebサイトに登録されているログインIDに対してのみ不正ログイン試行を行えるため、攻撃成功率が高まります。

ログインIDを間接的に取得する方法は様々なケースが考えられるのですが、ここではログイン画面とアカウントの新規登録画面を例に説明します。また、ログインIDにメールアドレスを使用しているとします。

まずログイン画面では、以下のように未登録のログインIDを入力した場合と、登録済みのログインIDを入力した場合のエラーメッセージの差分を確認することで、Webサイトに登録されているログインIDが判明します。

上図の場合、「bbb@example.com」というログインIDが登録されていることが判明します。

また、アカウントロック機能が実装されているサイトでは、アカウントロックの挙動を確認することで、登録済みのログインIDが判明する場合があります。

上図の例では、エラーメッセージから「bbb@example.com」を入力した場合だけアカウントロックが発生していることが分かるため、登録されているログインIDが判明してしまいます。

次に、アカウントの新規登録画面で判明するケースを説明します。

こちらはログイン画面よりも簡単で、新規登録するログインIDを入力した際に、以下のようなエラーメッセージが出力されることによって登録されているログインIDが判明します。

このような方法でログインIDが判明すると、攻撃者はWebサイトに登録されているログインIDを狙い撃ちした不正ログイン試行を行えるようになり、不正ログインの攻撃成功率が高まります。

また、メールアドレスをログインIDとして使用していた場合、漏えいしたメールアドレスに対してフィッシングメールが送信されるなど、悪用される範囲が拡大するため、より注意する必要があります。

間接的なログインIDの漏えいを防ぐには、ケースに応じた対策を講じる必要があります。

ログイン画面のエラーメッセージについては、ログインIDの登録有無に関わらず、「ログインIDまたはパスワードが違います。」というようなメッセージを一律で表示するようにしましょう。

アカウントロックについても、ログインIDの登録有無に関わらずアカウントロックを行い、同じエラーメッセージを表示するようにしましょう。または、アカウントロックが発生しても画面上では通常のログインエラーを表示し、本人のメールアドレス宛にアカウントロックが発生した旨を通知する方法も有効です。

新規登録画面の対策は難しく、ユーザが任意のログインIDを設定できる場合は、どうしてもログインIDの重複チェックを行う必要があります。
システム側でランダムに生成したログインIDを割り当てることで対策可能ですが、ユーザの利便性を下げてしまう可能性があります。

ログインIDにメールアドレスを利用している場合は、入力されたメールアドレスの登録有無に関わらず同じメッセージを返し、そのメールアドレスに対してその後の処理を行うためのURLを送信することで対策可能です。

また、上記の対策と合わせて、基本的な不正ログイン対策も実施しておきましょう。具体的な内容は、第二回の記事の「セキュリティ対策の具体例」をご参照ください。

ログインIDの漏えいを防ぐだけではなく、たとえ漏えいしても悪用できないように、二重三重のセキュリティ対策を施しておくことも重要です。

不十分なパスワード強度の概要と対策

不十分なパスワード強度とは、ログインパスワードを設定する際に求められる条件が全くない、もしくはかなり緩いパスワードポリシーのことを指します。

パスワードポリシーが設けられていないと、例えば「1」などの非常に単純なパスワードを設定することが可能になり、総当たり攻撃などで簡単に突破される危険性が高まります。

ここまで弱いパスワードを設定できるWebサイトは珍しいだろうと思われるかもしれませんが、筆者が実際に脆弱性診断を行っている中でも、パスワードポリシーが全くないものを数回見つけたことがあり、条件があっても「1111」などの単純なパスワードを設定可能なWebサイトとは数多く出会っています。

パスワードポリシーの設定は意外と見落とされる点だと思われるので、この機会に皆様が運営されているECサイトについても見直していただければと思います。

では、実際にどのようなパスワードポリシーを設ければ良いのでしょうか？

これには様々な議論やガイドラインがあり、代表的なものとしては米国国立標準技術研究所（通称：NIST）が公開している「電子的認証に関するガイドライン」 ^※１があります。

しかしながら、パスワードポリシーは各Webサイトの特性やリスクを考えて決める必要があるため、最終的にはサイト運営者自身で考えていただく必要があります。
ここでは、パスワードポリシーを考える際のヒントを紹介します。

まず、パスワードの要件に最も用いられるのが、文字数と文字種です。

下の表を見ると分かるように、文字数と文字種が増えるほど、パスワードの組み合わせの総数は大幅に増加していきます。パスワードの組み合わせの総数が多いほど、総当たり攻撃で破られにくくなります。

パスワードの組み合わせの総数を多くしておくために、最小文字数はできるだけ設定しておくことを推奨します。最小文字数についても様々な議論がありますが、一般的には8文字以上に設定しているものが多いように思われます。

それとは逆に、最大文字数や利用可能な文字種に対しては、できるだけ制限をかけない方が良いと思われます。ユーザによっては長いパスフレーズ（例：MyPasswordIsVeryStrong）を設定する可能性もあり、あえて制限をかける必要性はないと思われます。

また、パスワードポリシーは厳しく設定すれば良いわけではありません。
例えば「大文字・小文字・数字・記号を最低1文字以上入れる」という要件が設定されている場合、要件を満たすパスワードを考えることが面倒くさくなり、かえって「Password1!」などの単純なパスワードが設定される可能性が高まります。

複雑なパスワードを複数覚えるのも難しいため、パスワードを使い回すユーザも増えると思われます。

結論としては、厳しすぎない最低限の要件を設定しつつ、最大文字数や文字種の制限はできるだけかけないようにパスワードポリシーを考えると良いと思います。

文字数と文字種以外の要件としては、以下のようなものもあります。

以上の内容を参考に、それぞれのWebサイトに合ったパスワードポリシーを考えていただければと思います。

ただし、どんなに強固なパスワードでも、ユーザが複数のWebサイトで使い回していれば、パスワードリスト攻撃で突破される可能性があります。

セキュリティは一つ一つの対策を積み重ねていくことが基本であるため、コストとリスクのバランスを考えながら、アカウントロック機能や二要素認証、ログインの監視などを検討し、総合的なセキュリティ対策を行っていきましょう。