サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト 内山 史一
こんにちは。CSS部 エバンジェリストの内山です。
本エントリーでは、前回の私のコラム
(【エバンジェリスト・ボイス】改めて「パスワードの定期的な変更」を考える（前編）)
に引き続き、「パスワードの定期変更」をテーマに話を進めていきたいと思います。
前回ご紹介したパスワードの定期変更に関する総務省の見解は、「実際にパスワードを破られアカウントが乗っ取られたり、サービス側から流出した事実がなければ、パスワードは変更する必要はない」というものでした。この総務省の見解は、
2017
年
6
月に米国国立標準技術研究所
(
以下、
NIST)
のガイドラインで示された内容を受けて、「国民のための情報セキュリティサイト」
[1]
へ記載されたようです。
それでは、
NIST
の見解を確認する前に、まずは
NIST
のガイドラインについて紹介したいと思います。
【NISTのガイドラインについて】
NIST(National Institute of Standards and Technology：米国国立標準技術研究所
)
は、「アメリカの技術革新や産業競争力の強化を目的に、経済保障を強化して計測学・規格・産業技術を促進する」ことをミッションとする米国商務省配下の政府機関です。
NISTではコンピュータセキュリティに関して研究を行い様々な文書を発行しています。その中でも、
Special Publications (SP800
シリーズ
)
は、日本企業においても、自組織のセキュリティマネジメントやセキュリティ技術、インシデント対応等の強化・改善の参考にしていることが多い有益な文書です。
この SP800 シリーズの中で、パスワード認証を含む電子認証に係わるガイドラインとして発行された文書が、 SP800-63 ( 電子的認証に関するガイドライン ) です。
出典： NIST SP800-63 (Digital Identity Guidelines) [2]
SP800-63 は、以下 4 つのドキュメントで構成されています。
SP800-63-3 Digital Identity Guidelines ：ガイドラインの概要
SP800-63A Enrollment and Identity Proofing ：登録と身元確認
SP800-63B Authentication and Lifecycle Management ：認証とライフサイクル管理
SP800-63C Federation and Assertions ：フェデレーションとアサーション
これらは、米国政府機関向けのデジタル認証を実装するためのガイドラインであり、他国の政府機関や企業に対して強制力があるものではありません。しかし、本ガイドラインの内容は非常に信頼性が高く世界中から参考にされているため、事実上のデジタル認証における標準ガイドラインと言えるでしょう。
【パスワードの定期変更に関するNISTの見解】
ここからは、パスワードに関する要件が記載されている
SP800-63B
より、「パスワードの定期変更」に関する該当部分をピックアップしてご紹介します。
該当箇所は
SP800-63B
の「
5.1.1.2 Memorized Secret Verifiers
」
(5.1.1.2
記憶シークレット
Verifiers)
に記載されています。聞きなれない言葉かと思いますが、記憶シークレットはパスワードや
PIN(Personal Identification Number)
といったユーザーの記憶情報とご理解ください。
「パスワードの定期変更」に関する該当部分は以下のとおりです。
出典： NIST SP800-63B (Authentication and Lifecycle Management) [3]
日本語訳は、以下のとおりです。
----------------
Verifierは、記憶シークレットを任意で
(
例えば、定期的に
)
変更するよう要求すべきではない。
しかしながら
Authenticator
が危殆化した証拠がある場合は、変更を強制するものとする。
----------------
従来、サービスやシステムは、「例えば
90
日ごとに」といったパスワードの定期変更を義務づけてきましたが、サービス提供者はこのような定期変更を強制的に行うべきではないとしています。ただし、認証が突破され
ID
やパスワードといったアカウント情報が漏えいするような事態が発生した場合、強制的に変更を行うべきとされています。
その他、
SP800-63B
には以下のようなパスワード要件が記載されています。
●主なパスワードの要件
・利用者が設定する場合、 8 文字以上
・サービス提供者が設定する場合、乱数生成機によって生成した 6 文字以上
・少なくとも 64 文字以上のパスワード設定を許容する
・スペースを許容する
・ Unicode を許容する
・パスワードの複雑さに関する要件を課すべきではない
上記以外にも「秘密の質問」や「パスワード強度メーター」等、様々なパスワードの要件が
SP-800-63B
には記載されています。
ご興味のある方は、ぜひ原書をご参照ください。翻訳版もありますので、必要な箇所のみを参照したい場合は大変便利です。
【所有するアカウント情報が危険にさられていないか？】
NISTの見解では、サービス提供者がパスワードの定期変更を強制的に行うべきではなく、アカウント情報の漏えい等の事態が発生した場合に限り、パスワード変更を強制的に行うべきと示されていました。
そうすると、一般的には私達がパスワードを強制的に変更するタイミングは、サービス提供者からセキュリティ侵害に関する通知を受けたときになるでしょう。
これ以外に自分のアカウント情報が既知のセキュリティ侵害にさらされていないか確認したい場合、「
Firefox Monitor
[4]
」や「
Have I Been Pwned?
[5]
」にアクセスして自分のメールアドレスを入力して漏えいチェックする方法があります。
試しに「
Firefox Monitor
」で漏えいチェックしてみましょう。
チェックしたいメールアドレスを入力して「データ侵害を確認する」をクリックします。
入力したメールアドレスが、過去にデータ侵害によって漏えいしていると・・・・
ご覧のような画面が表示されます。
「この侵害について詳しく見る」をクリックすると、データ侵害に関する情報も確認することができます。
こちらがデータ侵害に関する情報です。
ちなみに侵害データの提供元が「
Have I Been Pwned?
」であることが分かりますね。
このような結果が出た場合、速やかにパスワードを変更しましょう。
他サービスで使いまわしている場合、各々のサービスで別のパスワードになるよう変更してください。都度、漏えいチェックをするのが面倒な場合は、「
Firefox Monitor
」にメールアドレスを登録することによってデータ侵害の監視をすることができます。
ご覧のとおり、「
Firefox Monitor
」の場合、個別アドレスごとの漏えい監視で、使いどころとしてはどちらかと言うと個人利用です。
一方、「
Have I Been Pwned?
」でも同様の機能はあります。「
Have I Been Pwned?
」の「
Domain search
」に自組織の所有ドメインを登録することによって、自組織のアカウント情報の漏えいが確認された際に通知を受けることができます。こちらは企業のセキュリティ担当者向けの機能です。
「
Firefox Monitor
」あるいは「
Have I Been Pwned?
」も、自身や自組織の要件に応じて有効にご活用いただければと思います。
余談ですが、「
Have I Been Pwned?
」は、
2013
年のサイト開設以降、セキュリティ専門家の
Troy Hunt
氏が個人で運営しております。この規模のサイトを今までたった一人で運営していたというから驚きです。
しかし、「
Have I Been Pwned?
」のサイト規模が大きくなりタスクも膨大になったため、現在は「
Have I Been Pwned?
」の買収先として見込みのある組織と非公式な話し合いを始めたそうです。
[6]
【パスワードの定期変更が不要になる前に】
今後の流れとしては、システムやサービスがパスワードの定期変更を求めることはなくなっていくものと思われます。
サービスの利用者である私達は、この流れに安易に乗っかるのではなく、自身の重要な情報を守るために以下のような対策を実施すべきです。
・他人に推測されにくく、ツール等の機械処理で割り出しにくい、安全なパスワードを作成する
・作成したパスワードを複数のサイトやサービスで使いまわさない
・サイトやサービスが多要素認証をサポートしている場合、積極的に利用する
・複数のサイトやサービスのパスワードを管理する、パスワード管理ツールを利用する
・マルウェア感染によるパスワード漏えいを防止するため、
OS
やソフトウェアを最新の状態に保ち利用する
特に安易なパスワード設定やパスワードの使いまわしは、ブルートフォース攻撃や辞書攻撃、パスワードリスト型攻撃といった攻撃手法による不正アクセスを招く危険性がありますので絶対にやめましょう。
ここで安易なパスワードがどのくらい危険か、パスワード解析ツールの「
John the Ripper
」を使って確認してみようと思います。
※本ツールは仮想の検証環境にてパスワードの脆弱性を検証するために利用します。自身の管理対象外のシステムに対し、絶対に本ツールを試さないでください。
手元の検証環境で以下のようなアカウントを作成してみます。（仮想環境の検証マシンには
CPU2
コアとメモリ
2GB
を割り当て）
パスワードは最悪のパスワードとして名高い「 123456 」を入れています。
<user> <password>
testuser1 / 123456
testuser2 / passw0rd
testuser3 / uchiyama
次に「
unshadow
」コマンドを使って、
"/etc/passwd"
と
"/etc/shadow"
を結合し、「
passwd_testfile
」を生成します。
解析時間を少しでも短くするため、「
passwd_testfile
」から解析対象外のアカウント情報は削除し、
testuser1
～
3
のみに編集します。
それでは、「
john
」コマンドで先ほど生成した「
passwd_testfile
」を解析してみましょう。
わずか数秒で
testuser1 / testuser2
のパスワードが解析されてしまいました。
（解析に時間がかかりそうなので、
testuser3
の解析処理を途中で停止しております）
こちらは解析結果です。仮に暗号化されていても安易なパスワードの危険性はイメージできたのではないかと思います。
重ねてのお願いになりますが、システムやサービスを利用するにあたっては安全なパスワードを設定するのは勿論のこと、前述の対策を実施するようお願いいたします。
さて、企業や組織のシステム管理者・セキュリティ担当者の方々には、自組織のシステムやサービスに対して、本エントリーで紹介した
SP800-63
をベースにパスワードの定期変更のみに留まらない包括的な見直しをご検討いただくことをお勧めします。
自組織のシステムやサービスにおいて、どの程度の電子的認証の強度が必要かを明確にするガイドラインを作成した上でギャップ分析を行って、システムやサービスの変更計画を立案すべきでしょう。
また、パスワードの定期変更を継続するケースとして、「共有アカウント」によるシステムやサービス利用が考えられます。利用者の人事異動や退職後もシステムやサービスへのアクセス権が残るのは、セキュリティ上のリスクが伴いますので、パスワードの定期変更を継続する必要があります。
しかし、そもそも「共有アカウント」は、セキュリティ侵害（内部不正含む）が発生した際、誰がアクセスしたか特定することが困難な状況を招きますので、利用自体を見直すべきでしょう。
前回と本エントリーの
2
回にわたりパスワードの定期変更をテーマに話を進めてきました。
パスワード認証は使いやすい認証方式と言えますが、人間の記憶に依存しているという課題があります。
近年、利用者は社内システムの他に様々なクラウドサービスを利用することになり、これに伴って各サイトやサービスごとにパスワードを管理する必要性がでてきました。
"水は低きに流れ、人は易きに流れる
"
という言葉にあるとおり、人は「面倒」とか「つらい」と思ったとき、頭では分かっていても、楽な方を選んでしまいがちです。
この機会にパスワードの長さやパスワードの複雑さの要件といったパスワードポリシーの見直しから始めてみては如何でしょうか。
それでは、次のエントリーでお会いしましょう！
============
脚注および参考情報
[1]
総務省 国民のための情報セキュリティサイト
[2]
NIST SP800-63 (Digital Identity Guidelines)
NIST SP800-63 (Digital Identity Guidelines)※翻訳版
[3]
NIST SP800-63B (Authentication and Lifecycle Management)
[4]
Firefox Monitor
[5]
Have I Been Pwned?
[6]
Project Svalbard: The Future of Have I Been Pwned
============
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
