2020年9月18日
※For the English version, please refer to here.

今回のブログではパスワードについて考えたいと思います。組織・システムにはどのようなパスワード要件を設けるべきかや、ユーザーはどのようなパスワードを設定するべきかについて様々な議論やガイドがあります。このブログで達成したいことはいわゆるパスワード要件について答えを示すことではなく、読者にパスワードについて考える機会を持ってもらうことです。

そこで考える話のたねとして、NIST(National Institute of Standards and Technology)やCIS(Center for Internet Security)などの団体が示しているパスワードポリシーに関するガイドから、パスワードの要件を整理しました。

さらに、では実態はどうかということで、31のWebサイトでアカウント作成またはドキュメントを調査することで、そのWebサイトで実際にどのようなパスワードの要件が定められているかを調査しました。
※ サンプル数が少なく、調査の妥当性には欠けます。あくまで参考であることご了承ください。

ぜひ自分のパスワードポリシーを思い浮かべながら読んでみてください。

なお、パスワードの要件の議論は、あくまで認証といういかにしてユーザー本人であることを確認するかという議論の一要素にすぎません。したがって、認証が強化できるのであれば別にパスワードにこだわる必要は無く、生体認証やワンタイムパスワードなどの他の認証方法もあります。

今回、読者にパスワードについて考える機会を持ってもらうことを本ブログの目的としていますが、広くは認証について考えてほしいと思います。認証を考えるうえでまずはパスワードを足掛かりとし、それからさらに他の認証方法についても手を広げるなどして、認証を強化するにはどうしたらいいかについて考えてもらいたいと思います。あくまでも本質は認証であることにご注意ください。

パスワードについてのガイドの整理

CIS Password Policy Guide(以下、CISPPG) [1]とNIST SP800-63B Digital Identity Guidelines(以下、NIST63B) [2]、内閣サイバーセキュリティセンターが発行しているインターネットの安全・安心ハンドブック(以下、NISCハンドブック) [3]に記載されていたパスワードの要件を表1に抜粋・整理しました。

表1：CISPPG・NIST63B・NISCハンドブックのパスワードの要件の抜粋・整理

NISCハンドブックについては、協力組織として総務省・経済産業省・IPAが記載されていたため、これらの組織についても当該ドキュメントのパスワードの要件を推奨しているものと考えました。そのため、IPAのサイトで示されていたパスワードの要件は古いものとして捉え、整理に含めませんでした。

また、これらのガイドはそれぞれ想定されている読者が異なると考えています。CISPPGはシステム開発者・ユーザーを問わず、広く一般的なものだと思います。NIST63B(NIST SP800シリーズ)は連邦政府機関向けのシステムの技術的要件ですが、NIST SP800シリーズはセキュリティの分野においてデファクトスタンダードとなっているため、広くサイバーセキュリティに関わる人向けのものだと思います。NISCハンドブックは一般的なユーザー向けのものです。そのため、単純にこれらのドキュメントを比較するのはナンセンスだとは思いますが、パスワードについて考えるためのコンテンツとして考えていただければと思います。

パスワードの最小文字数

パスワードの最小文字数を8文字としているケースが最も多く(と言っても3つ中2つですが)、これは一般的な認識と一致しているように見えます。ただし、CISとNISTはそれぞれ「多要素認証の場合」、「ユーザーが作成するパスワードの場合」というように条件付きであるため、一概には言えません。

なぜ一般的なパスワードの最小文字数が8文字なのか断言はできませんが、レガシーなシステムの場合、入力できる最大文字数が8文字だからという移植性の問題があることと、そうは言っても最低限度の強度のパスワードが欲しいというラインの妥協点として8文字が最小文字数であることのではないかと筆者は考えています。ユーザー向けであるNISCハンドブックでは8文字について触れられていない一方、開発者・技術者を対象読者に含むCISPPGとNIST63Bには8文字が最小文字数にあることもそれを裏付けているのではないかと思っています。

NIST63Bにある「自動生成されたパスワードの場合」というのは、システムが設定したパスワードをユーザーが使う場合のことを指しています。ユーザーがパスワードジェネレータを使って生成したパスワードのことを指しているわけではないと筆者は理解しています。
これは例えば、Zoomの例がわかりやすいです。図1に示すように、Zoomではミーティングを設定すると6桁の数字がパスコードとして自動で設定されます。まさにこれがNIST63Bの「自動生成されたパスワードの場合」を表していると思います。

パスワードの最大文字数

CISPPGとNIST63Bがパスワードの最大文字数を明示しており、それぞれ「制限なし」と「少なくとも64文字」です。NISCハンドブックはユーザー向けなので、明示されていないのは当然ではあります。CISPPGとNIST63Bは共通して基本的にパスワードの最大文字数を制限しない姿勢だと思います。

パスワードの文字構成

CISPPGとNIST63Bはパスワードに使用可能な文字と、パスワードに含めるべき文字の種類の両方について明示しています。NISCハンドブックはユーザー向けなので、パスワードに含めるべき文字の種類についてのみ示しています。
※ちなみに、NIST63Bでは推奨としてUnicode文字があり、そんな実装あるのかと気になって調べたところありました [4]。

パスワードの定期変更についてはパスワードの漏洩などの事態になった場合、すぐに変更するという点は共通しています。

パスワードに関するその他の要件については、それぞれのガイドで内容が少し異なりますが、推測されやすいパスワードを設定しないようしているのは共通しているように思います。

パスワードの実態調査

繰り返しになりますが、パスワードにどのような要件が設定されているかの実態を把握するために、31のWebサイトを調査しました。調査項目はパスワードの最小文字数、最大文字数、文字構成の3つです。調査ではWebサイトが提供しているサービスのアカウント作成画面でパスワードの条件の確認や、組織の公開されているパスワードポリシーの確認をしました。調査結果を表2に示します。
※あくまでアカウントの作成画面でパスワードの条件が記載されているか確認しただけで、アカウントの作成はしておりません。
※パスワードポリシーは、その組織で決めるものであり、本ブログの内容は組織のパスワードポリシーを非難するものではありません。

表2：パスワードの実態調査結果

最小文字数

パスワードの最小文字数別のサンプル数のグラフを図2に示します。

パスワードの最小文字数は次の4・6・8・10・12・15文字の6パターンに分かれました。6・8文字に集中していてばらつきはあまりない印象です。

8文字については、一般的な認識ともNIST63Bの要件にも合致していると思います。

6文字についてはNIST63Bでは自動生成されたパスワードの場合に少なくとも6文字と示されていますが、今回のケースはNIST63Bの条件と違うので当てはまりません。他のガイドで6文字を最小文字数として設定している可能性もありますが、6文字に設定している理由ははっきりとはわかりませんでした。個人的に6文字がパスワードの最小文字数として一般的だとは思っていませんでしたが、実は割と一般的な数なのでしょうか。ただし、6文字及び4文字は前述したどのガイドの要件も満たしておらず、そういう意味で比較的脆弱だと思います。

10文字のケースについてはNISCハンドブックの要件と合致しています。これを設定していたサンプルの2件中1件はNISCハンドブックに文字構成含め準拠していました。12・15文字のケースについても文字構成を考慮してもNISCハンドブックのパスワード要件以上の強度があります。

ここで、最小文字数だけでなく構成文字も考慮して見たいと思います。仮にユーザーが各サンプルの最小文字数、必須の文字構成のみのパスワード要件にした場合、各ガイドに準拠しているサンプルはいくつあるのかを表3にまとめました。

表3：最小文字数と文字構成を考慮した各ガイドへの準拠状況

CISPPG(MFAあり)とNIST63Bについては準拠するのに必要なのは実質的に最小文字数8文字だけ(今回MFAは調査対象外で考慮しない)なので、全サンプルのうち6割が準拠していました。CISPPG(パスワードのみ)とNISCハンドブックについては1割程度かそれ以下が準拠しています。
4割程度はどのガイドの最低限のレベルにも準拠しないほどで、これらについては脆弱であると思います。
※本ブログではガイドへの準拠や強度を判断するにあたり、CISPPG(パスワードのみ)の文字構成の要件である「英字以外の文字が1文字以上必要」については数字を使うと想定しています。

最大文字数

パスワードの最大文字数別のサンプル数のグラフを図3に示します。

パスワードの最大文字数にはかなりばらつきがありました。この理由についてはシステムの仕様で決まっている部分もあるので、考察は難しいです。

明示が無いものについては制限なしと判断することもできますが、実際に設定してみるとシステム的に上限がある可能性を否定できません。そのため、制限がないと明示されていない限り、制限が無いとは言えないと判断し、明示無しと表現しています。

また、明示的されているものの中でNIST63Bの条件である「少なくとも64文字」を満たしているものはありませんでした。

ここで、最小文字数の時と同様、今度は仮にユーザーが各サンプルの最大文字数、必須の文字構成のみのパスワード要件にした場合、各ガイドに準拠しているサンプルはいくつあるのかを表4にまとめました。

表4：最大文字数と文字構成を考慮した各ガイドへの準拠状況

基本的には全体的に準拠できていましたが、CISPPG(パスワードのみ)とNISCハンドブックについては準拠していないサンプルがそれぞれ3件と2件ありました。
NISCハンドブックについては、文字構成を必須のものだけでなく英大文字・英小文字・数字・記号にすればすべてのサンプルが準拠できることになります。しかし、CISPPG(パスワードのみ)については文字構成を増やしても準拠していないサンプルが2つ残ります。そのため、このようなサンプルでユーザーがCISPPGに準拠しようとする場合、多要素認証を有効にする必要があります。

文字構成

パスワードの文字構成別のサンプル数のグラフを図4に示します。

文字の構成条件は多い順に英数、明示無し(制限なし)、英大小数記・英数記号・その他・英大小数の6パターンでした。あまりばらつきは無いように思います。

その他については、英大文字・英小文字・数字・記号の4種類から3種類を使う、のように数種類の中からユーザーに使う文字種類を選択させる形式のものです。何種類の中から選ぶか、そこからユーザーが何種類選択するかはサンプルによって違いがありました。

明示無し(制限なし)に関しては、全てではありませんが、いくつかのサンプルで数字のみを記入してアカウント作成確認画面までエラー無かったことを確認したため(制限なし)を付与しています。

まとめ

ここまで読んでみてどうだったでしょうか。筆者としては実態の調査結果を見て、最小文字数以外はどの組織も要件がバラバラだと感じました。これはパスワードの要件について正解があるわけではないことの表れだとも思いました。したがって、本末転倒ではありますが、あらためて結局は組織やユーザーが自分自身で自分のパスワードポリシーを決めるしかないのだと思いました。

例えば、組織が比較的緩い要件であるNIST63Bに沿うのであれば、パスワードの最大文字数と文字構成についてユーザーに対して強制するべきではありません。

しかし、結果的にユーザーが脆弱なパスワードを設定してしまい、それが理由で情報が漏洩した場合、組織にも責任があると判断されてしまうのが実状としてあります [5], [6]。そのため、組織がパスワードの登録に条件を設けようとする理由もわかります。NIST63Bにはパスワードのブラックリストを設定することなど、脆弱なパスワードが設定できないような措置が明記されています。

ただし、パスワードの使いまわしへの対策は難しいです。使いまわされたパスワードが他の組織から漏洩したとして、それに気づいて自組織で対応するのは困難です。また、パスワードの条件を厳しくしすぎると、ユーザーは似たようなパターンのパスワードを使用するという指摘もあり、パスワードの条件のバランスは判断が難しいです。

そのため、組織はパスワードの要件の設定において、組織の活動を続けるうえでのコストとリスクのバランスを考えながらパスワードの要件を設定したり、場合によっては多要素認証を導入するといった選択をすることになります。

ユーザーとしては利便性を考えると簡易なパスワードを設定したくなりますが、仮にパスワードが破られた場合のリスクを考えれば、安易に簡易なパスワードにはできません。かといって複雑なパスワードは覚えづらく、ここでも組織の場合と同様にコストとリスクのバランスを考えてパスワードを決める必要があります。
※パスワードの管理や作り方についての議論もありますが、ここではいったん対象外とします。

ユーザーはまずは取り組み始めやすいNISCハンドブックに沿ってみるというのもいいと思います。ただし、最低10文字で文字構成は英(大小)数記号という条件にこだわる必要はありません。同等の強度があれば文字数を増やして英数のみというようにしてもいいでしょう。大事なのは運用可能なパスワードを設定することだと思います。

ここで、筆者が組織・ユーザーそれぞれの立場だったらどうするかを考えてみました。

筆者が組織の立場であれば、状況によって判断は変わります。

不正ログインによって漏洩する可能性がある情報(資産)が重要で、かつお金をかけられる場合、パスワードの要件はNIST63Bに準拠し、加えて多要素認証を導入します。繰り返しになりますが、あくまで本質は認証であり認証の強化ができればパスワードにこだわる必要はありません。したがって、多要素認証を追加で導入したほうが認証はより強化され、リスクは小さくなると思うからです。

コストをあまりかけられない場合、多要素認証を導入する選択肢は取れないと考え、パスワードの最小文字数と文字構成はCISPPG(パスワードのみ)に合わせ、最大文字数はNIST63Bに合わせて64文字にします。確かにユーザーの利便性は下がりますが、それによってアカウント作成をやめてしまうユーザーはいないでしょうし、最低14文字にしている組織は調査結果から比較的少ないと考えられるので、パスワードが他の組織で設定されているパスワードと被ることは少ないのではないかと思ったからです。

加えて、そもそも不正ログインによって漏洩する可能性がある情報(資産)があまり重要ではない場合は、パスワードを強力にすることよりもユーザーの利便性を考慮してNIST63Bに準拠するようにします。

次に、筆者がユーザーの立場の場合です。

自分で適切なパスワードの強度を考慮するので、自由にパスワードを作らせてほしいと思います。そういう意味で、パスワードの最大文字数に上限を少なくとも30文字程度以上にはしてほしいと思いますし、文字構成について強制してほしくないと思います。パスワードの定期変更も面倒なので強制してほしくありません。
したがって、できれば組織はNIST63Bに沿ってもらえると嬉しいなと思います。

このように読者の方がパスワードについて考えを巡らせてもらえたら、と思います。

本ブログが少しでもみなさんの役に立ち、安心・安全な社会に少しでも寄与することを願っています。

参考文献

執筆者の他の記事を読む