サイバーセキュリティはじめました

ハニーポット（T-POT）の検証や攻撃の実験など、サイバーセキュリティに関して少しずつ勉強しています。

パスワードの定期変更は行うべき？行わないべき？

考察

これまでは、海外で「パスワードの定期変更は行うべきではない」といった話があり、一部で話題になっていましたが、最近、総務省やJIPDEC（Pマークの認証機関）が「パスワードは定期変更すべきではない」を発表しました。

 

個人的に、「なるほどな～」と思う反面、「本当に大丈夫？」という疑問もあります。そこで、なぜ、いま、パスワードの定期変更が見直されているのか、調べてみることにしました。

※極力、必要な部分を引用していますが、引用ミスにより正式な見解と異なる解釈となっている場合は、ご指摘いただけるとありがたいです。

 

パスワードを定期変更すべきではないという根拠

総務省

 総務省は、「国民のための情報セキュリティサイト」内で、以下のように明記しています。

  なお、利用するサービスによっては、パスワードを定期的に変更することを求められることもありますが、実際にパスワードを破られアカウントが乗っ取られたり、サービス側から流出した事実がなければ、パスワードを変更する必要はありません。むしろ定期的な変更をすることで、パスワードの作り方がパターン化し簡単なものになることや、使い回しをするようになることの方が問題となります。定期的に変更するよりも、機器やサービスの間で使い回しのない、固有のパスワードを設定することが求められます。

  これまでは、パスワードの定期的な変更が推奨されていましたが、2017年に、米国国立標準技術研究所（NIST）からガイドラインとして、サービスを提供する側がパスワードの定期的な変更を要求すべきではない旨が示されたところです（※１）。また、日本においても、内閣サイバーセキュリティセンター（NISC）から、パスワードを定期変更する必要はなく、流出時に速やかに変更する旨が示されています（※２）。

しっかりと、パスワードの定期変更はする必要ないと書かれています。

なお、これとは別にパスワードの設定と管理のありかたとして、以下を推奨しています。

(1) 名前などの個人情報からは推測できないこと
(2) 英単語などをそのまま使用していないこと
(3) アルファベットと数字が混在していること
(4) 適切な長さの文字列であること
(5) 類推しやすい並び方やその安易な組合せにしないこと

 

逆に、以下のパスワードは設定しないよう呼び掛けています。

(1) 自分や家族の名前、ペットの名前
　　yamada、tanaka、taro、hanako（名前）
　　19960628、h020315（生年月日）
　　tokyo、kasumigaseki（住所） 　　　
　　3470、1297（車のナンバー）
　　ruby、koro（ペットの名前）
(2) 辞書に載っているような一般的な英単語
　　password、baseball、soccer、monkey、dragon
(3) 同じ文字の繰り返しやわかりやすい並びの文字列
　　aaaa、0000（同じ文字の組み合わせ）
　　abcd、123456、200、abc123（安易な数字や英文字の並び）
　　asdf、qwerty（キーボードの配列）
(4) 短すぎる文字列
　　gf、ps

この他、電話番号や郵便番号、生年月日、社員コードなど、他人から類推しやすい情報やユーザIDと同じものなどは避けましょう。

 

 内閣サイバーセキュリティセンター（NISC)

 内閣サイバーセキュリティセンター（NISC)では、「情報セキュリティハンドブック」において、以下の通り明記されていました。

www.nisc.go.jp

　利用するサービスによっては、パスワードを定期的に変更することを求められることがあります。しかし、実際にパスワードを破られアカウントを乗っ取られたり、サービス側から流出したりした事実がないのならば、パスワードを変更する必要はありません。
　むしろ定期的な変更を要求することで、パスワードの作り方がワンパターン化し簡単なものになることや、使い回しするようになることの方が問題となります。定期的に変更をするよりも、機器やサービスの間で使い回しのない、固有のパスワードを設定しましょう。

ここでも、パスワードを変更する必要はないと書かれていますね。

パスワードの設定基準は、以下の通り記載されています。

パスワードは少なくとも英大文字小文字＋数字＋記号で 10 桁

数字のみだと→ 100 億通り
英大文字小文字＋数字＋記号（26 個として）だと→
　　　　　　　　　　　　約 2785 京 97 兆 6009 億通り

数字だけで10桁と、英大文字小文字＋数字＋記号で10桁では雲泥の差がある。そしてこれほど多量な組み合わせを調べるのは事実上不可能。

 

アメリカ国立標準技術研究所（NIST）

私の知る限りでは、ここが初めて「パスワードの定期変更は必要ない」と発表した機関ではないでしょうか。

具体的には、「NIST Special Publication 800-63B」にその記載が載っています。

※残念ながら、私は英語力が全くありませんので、翻訳はGoogle翻訳を使用しています。そのため、和訳に問題がある箇所があるかと思います。正確な和訳ができる方は、ぜひ、教えてください。

5 Authenticator and Verifier Requirements

5 Authenticator and Verifier Requirements

5.1 Requirements by Authenticator Type

5.1.1.2 Memorized Secret Verifiers

 

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (eg, periodically).However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

以下、Google先生の和訳です。

5 オーセンティケータと検証者の要件 

5.1オーセンティケータタイプによる要件

5.1.1.2暗証検証者の記憶

 

検証者は、記憶された秘密を任意に（例えば、定期的に）変更する必要はない（SHOULD NOT）。しかし、認証者の妥協の証拠があれば、検証者は変更を強制しなければならない。

ここでは、「（例えば定期的に）変更する必要はない。」とされています。

ただ、主語が異なります。NISTは「検証者は」つまり、サービス提供者が定期的に変更する必要はないとしています。つまり、NISTは利用者が定期変更したければ、してもいいよというようにも読めます。

一方、総務省や内閣サイバーセキュリティセンターは「利用者」向けの資料であるため、主語が「利用者」ですね。「利用者はパスワードの定期変更を行う必要はない」としており、内容が大きく異なりますね。

 

他に気になった点を引用すると、

 5.1.1.1 Memorized Secret Authenticators

 

Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.

 Google先生による和訳

5.1.1.1暗記認証者の記憶 

 

暗記された秘密は、サブスクライバーによって選択された場合、少なくとも8文字の長さでなければならない（SHALL）。 CSPまたは検証者によってランダムに選択された記憶された秘密は、少なくとも6文字の長さでなければならず、完全に数字である必要があります。 CSPまたは検証者が、選択された記憶された秘密を、侵害された値のブラックリスト上のその外観に基づいて許可しない場合、加入者は異なる記憶された秘密を選択する必要がある。 記憶された秘密の他の複雑さ要件は課されてはならない（SHOULD）。 これに関する理論的根拠は、 付録A 「記憶された秘密の強さ」に示されている。

 ここで、長さについて「Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. （少なくとも8文字の長さでなければならない）」と明言されていますね。

もう一つ気になるのが「No other complexity requirements for memorized secrets SHOULD be imposed. （記憶された秘密の他の複雑さ要件は課されてはならない）」という文です。

長さ以外の複雑さを要求するなということでしょうか？根拠が付録A「記憶された秘密の強さ」に示すということですので、付録Aを確認してみます。

付録A

A.2 Length


Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

（中略）

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

Google先生による和訳

A.2長さ


パスワードの長さは、パスワードの強度を特徴づける主要な要因であることが判明しています[Strength] [Composition]。短すぎるパスワードは、無差別攻撃だけでなく、単語や一般的に選択されたパスワードを使用した辞書攻撃にも適用されます。

（中略）
ユーザは、理由の中で、自分のパスワードを望みどおりに長くするよう奨励されるべきです。ハッシュされたパスワードのサイズはその長さとは無関係であるため、ユーザーが望む場合は長いパスワード（またはパスフレーズ）の使用を許可しない理由はありません。極端に長いパスワード（おそらくはメガバイト）は、ハッシュ処理に過剰な処理時間がかかる可能性があるため、いくらか制限があるのは妥当です。

 これは、最小桁数は設ける必要があるが、最長桁数は（過剰な処理時間がかからない範囲で）設けるべきではないと読み取れますね。それだけ、長さについては長ければ破られる可能性が低いということなのでしょう。

A.3 Complexity


As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

（中略）

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.

Google先生による和訳

A.3複雑さ
上記のように、構成ルールは、ユーザーが選択したパスワードを推測することの難しさを増やすために一般的に使用されます。しかし、研究者は、構成ルール[ポリシー]によって課せられた要件に、ユーザーが非常に予測可能な方法で応答することを示しています。たとえば、パスワードとして「パスワード」を選択したユーザーは、大文字と数字を含む必要がある場合は「Password1」、記号も必要な場合は「Password1！」を選択する可能性が比較的高くなります。
（中略）
ユーザーのパスワードは非常に予測可能であるため、攻撃者は過去に成功したパスワードを推測する可能性があります。これには、上記の「Password1！」の例のような、以前の違反の辞書の単語やパスワードが含まれます。このため、ユーザーが選択したパスワードと、許容できないパスワードの「ブラックリスト」を比較することをお勧めします。このリストには、以前の違反コーパス、辞書の単語、およびユーザーが選択する可能性が高い特定の単語（サービス自体の名前など）のパスワードが含まれている必要があります。ユーザーのパスワード選択には最小長要件が適用されるため、この辞書はその要件を満たすエントリのみを含める必要があります。
非常に複雑に記憶された秘密は、新たな潜在的な脆弱性をもたらします。記憶に残る可能性は低く、電子的に安全でない方法で書き留められたり保存される可能性が高くなります。これらの慣行は必ずしも脆弱ではないが、統計的にはそのような秘密を記録するいくつかの方法がある。これは、過度に長く複雑な記憶された秘密を必要としないという追加的な動機である。

 私個人の見解（あくまでGoogle翻訳を信用しての見解）としては、ユーザにパスワードの複雑さを要求すると、（全員ではないにしろ）記憶しやすい簡単なパスワードを選択する可能性が高くなり、逆に強度が低下すると読めました。

A.5 Summary


Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.

 Google先生による和訳

 A.5要約


長さと複雑さの要件は、ここで推奨されているものを超えると、記憶された秘密の難易度を大幅に高め、ユーザーの不満を増大させます。その結果、ユーザーはしばしばこのような制限を回避することができます。さらに、ブラックリスト、セキュアハッシュストレージ、レート制限などの他の緩和策は、現代のブルートフォース攻撃を防止する上でより効果的です。したがって、複雑さの追加要件は課されません。

やはり、推奨された長さと複雑さの要件を超えると、ユーザから見てパスワードの設定や管理が困難になり、その制限を回避するための簡単なパスワードをつけて強度を下てしまうと読めますね。

 

なお、NIST Special Publication 800-63Bは、パスワード部分だけでも非常に多くの文面が割かれており、その中でパスワードを強固に守るための様々な方策が書かれています。

そのため、単純にパスワードの定期変更をしなくてもいいというわけではなく、それらの対策をすべて講じれば、パスワードの定期変更は不要であると読み取ることができます。

規格の改訂

JIPDEC（一般財団法人　日本情報経済社会推進協会）

Pマーク（プライバシーマーク）の認証機関であるJIPDECは、「JIS Q 15001:2006」をベースにした「個人情報保護マネジメントシステム実施のためのガイドライン-第2版-」を一部改訂しました。

その内容は、以下の通りです。

Ⅱ．技術的安全管理措置として講じなければならない事項と望ましい手法の例示

１．個人情報へのアクセスにおける識別と認証

(5)　識別情報の設定および利用はルールに従っていること。

①パスワードの有効期限を設定している。

②同一又は類似パスワードの再利用を制限している。

①最低パスワード文字数を設定している。

②パスワードの設定方法（文字、数字、記号を必ず混ぜて設定する等）を定めている。

③一定回数以上ログインに失敗したIDの停止等の措置を講じている。

④パスワードの設定変更をする場合には、類似パスワードの再利用を制限している。

⑤複数のサービスで同一のパスワードを使いまわさないことを求めている。

⑥漏えいした、または漏えいのおそれがあるパスワードは、速やかに変更することを求めている。

　※赤字は追加された項目、青字は削除された項目

パスワードの定期変更は削除され、パスワードの使いまわしなどの制限が追加されています。

 

NISTとその他の相違点のまとめ

※ここから先の内容は、ここまでの情報をまとめてみた結果の私見です。

パスワードの定期変更を行わない理由

NIST

パスワードの定期変更よりも有効なパスワード保護の手段（例えば、ログイン試行回数の制限やパスワードの長さの制限、パスワード拒否リストの導入など）があり、それらを採用することで、パスワードの定期変更を利用者に求めなくてもよい。

その他

定期的にパスワードを変更すると、パスワードの作り方がパターン化してしまい、簡単なパスワードになってしまう。また、パスワードの使いまわしにつながるため、利用者は定期的な変更を行うべきではない。

 

パスワードの長さ

NIST

最低でも8文字以上を要求するべきで、利用者が望むのであれば長いパスワードを許可するべき。

その他

総務省：極端に短くないパスワードを設定する。

内閣サイバーセキュリティセンター：10桁以上のパスワードを設定する。

 

パスワードの複雑さ

NIST

複雑なパスワードを利用者に要求すべきではない。

その他

総務省：(1) 名前などの個人情報からは推測できないこと
　　　　(2) 英単語などをそのまま使用していないこと
　　　　(3) アルファベットと数字が混在していること
　　　　(4) 適切な長さの文字列であること
　　　　(5) 類推しやすい並び方やその安易な組合せにしないこと

内閣サイバーセキュリティセンター：パスワードは少なくとも英大文字小文字＋数字＋記号で 10 桁

 

結論

ここでは、NISTが正しいような書き方になってしまっていますが、結局は「何をもって強固なパスワードか」が重要なのであって、ブルートフォース攻撃や辞書攻撃を受けても突破されないパスワードが強固なパスワードだと思うんですよね。

 

北河拓士さんのTwitterからパターンを見てみると、

 このようになるようです。小文字記号数字で12桁くらいのパスワードを作っておけば、かなりの強度にはなりそうですよね。

けど、覚えにくいのであれば、5万語の単語から無作為に４つや５つ選択しても、十分強固なパスワードになるのです。さらに、5万語の辞書から３つと家族の名前をつなぐだけで、攻撃者がパスワードを特定する可能性が限りなく低くなりそうです。

 

もちろん、それだけの桁数が入力できなければならないので、その点はシステム提供者が改善してもらう必要がありますが、利用者目線でいえば、大文字小文字記号数字のうち〇個使用するというパスワードは不要なのかもしれませんね。

もちろん、桁数に制限があるのであれば、その桁数で最も有効なパスワードが小文字記号数字の組み合わせになるかもしれません。

そのため、ユーザからすると、利用するシステムの制限によって使い分ける必要があるということではないでしょうかね。

 

次の記事

tk-secu.hateblo.jp