みなさん、こんにちは。
ソリューションSecの長谷川です。

突然ですが、皆さんが普段使っているさまざまなWebサービスやアプリのパスワードは、本当に安全なものと言えるでしょうか？
よく、パスワードは「複雑なもので使い回さないほうがいい」とか「定期的に変更したほうがいい」と言われています。

言わんとすることは分かるのですが、昔と違い様々なサービスが登場し
さらにはスマホが普及したことによって、一人ひとりが多くのサービスに登録していることは珍しくありません。
人によっては100を超えるサービスに登録していることもあるので
そうなったときに全部覚えておくのはまず難しいです。

そんな中で、開発者はユーザーにパスワードを登録してもらう際に
パスワードが決められたルールに基づいて設定されているか？をプログラムでチェックする必要があります。

では、そのルールをどのように決めたらいいのでしょうか？

推奨されるパスワードのルール

IPA 情報処理推進機構では、安全なパスワードの条件について
下記のように記載しています。

• 最低でも10文字以上の文字数で構成されている
• パスワードの中に数字や、「@」、「%」、「”」などの記号も混ぜている。
• パスワード内のアルファベットに大文字と小文字の両方を入れている。
• サービスごとに違うパスワードを設定している。

多くのサービスでは、「8文字以上」「英字と数字の組み合わせ」などのルールが一般的ですが
安全性の観点からは、もう少し強めの条件が推奨されています。

8文字は安全じゃないのか？

先にも述べたように、パスワードは8文字以上というルールはよく見受けられますが
IPAではなぜ10文字以上と推奨しているのでしょうか。

その理由は単純でブルートフォースアタック（＝総当たり攻撃）において
文字数が長ければ長いほど安全であることと、近年はハードウェアの進化により
このブルートフォースアタックに必要な時間が昔に比べて短くなってきているからです。

では、実際にどれくらいの時間がかかるのでしょうか？
Hive Systemではブルートフォースアタックでパスワードの解読にどれくらいの時間がかかるのかの調査結果を公表しています。
その結果は下記のようになっています。

なお、実際の解読速度はパスワードのハッシュ化方式や、
攻撃に使用されるハードウェアの性能によって大きく異なります。
2025年はパスワードハッシュをbcrypt(10)、ハードウェアをRTX 5090×12台という状況で試算しているとのことです。

見ての通り、文字数が長くなることで仮に数字だけのパスワードだったとしても
10文字以上になってくると、最低1日はかかるみたいですね。

とはいえ数字だけでは弱いので、上の表で見れば最低でも8文字以上の数字＋小文字＋大文字が望ましいようには見えます。

ただ、あくまでもブルートフォースアタックでの場合ですので
そもそもパスワードが流出してしまった場合は意味がないのですが・・・。

Laravelでのパスワードのバリデーションルール

Laravelのバリデーションでは、Passwordに特化したバリデーションルールを
Passwordルールオブジェクトを使用して設定することが出来ます。

// 最低８文字必要
Password::min(8)

// 最低１文字の文字が必要
Password::min(8)->letters()

// 最低大文字小文字が１文字ずつ必要
Password::min(8)->mixedCase()

// 最低一文字の数字が必要
Password::min(8)->numbers()

// 最低一文字の記号が必要
Password::min(8)->symbols()

これらを活用することで、より良いパスワードのバリデーションを設定しましょう。
また、uncompromisedメソッドを使うことで、公開されているパスワードのデータ漏洩によるパスワード漏洩がないことを確認することもできます。

// 同一のデータリークにおいて、パスワードの出現回数が3回以下であることを確認
Password::min(8)->uncompromised(3);

このメソッドは内部的にはHave I Been Pwnedのサービスを利用して判定しているようです。

安全なパスワード設定をもとめることについて

ここまで述べてきたように、やはり複雑で推測されにくいパスワードを設定することが望ましいといえます。しかし、利用者の立場からすると、それは必ずしも歓迎されるものではないかもしれません。

たとえば、同じパスワードを複数のサービスで使い回しているかどうかをサービス側で判定することはできません。とはいえ、近年ではパスワード管理ツールや、ブラウザの自動生成・保存機能の普及により、複雑なパスワードを扱うハードルは大きく下がっています。

このような背景を踏まえると、「複雑なパスワードはユーザーに負担を強いる」という懸念は、以前ほど大きく考えなくてもよいのではないかと思います。

もちろん、サービス運営側としては「厳しすぎるパスワード要件がユーザーの離脱を招くのではないか」という懸念もあるでしょう。しかしながら、情報漏洩などのセキュリティインシデントが発生した場合の損害は、ユーザー体験の一時的な不満をはるかに上回るものです。

そのため、一定のパスワード強度を求めることは、サービスの信頼性維持のためにも正当な判断であるといえるでしょう。

終わりに

パスワードの強度に関しては、ただルールを押しつけるのではなく、なぜそのルールが必要なのかを利用者に伝える工夫も、開発者として大切な視点だと感じています。

今後も、安全で信頼されるサービスを目指すためのヒントを共有していければと思います。最後までお読みいただきありがとうございました！