KNOWLEDGE - COLUMN ナレッジ - コラム

【エバンジェリスト・ボイス】なぜサーバに平文パスワードを入れるのか。

サイバー・セキュリティ・ソリューション(CSS)部
エバンジェリスト フェロー 関原 弘樹     顔写真2_1187x1313

日中は残暑の厳しい日もありますが、朝夕を中心にようやく涼しさを感じるようになり、ほっと一息というところでしょうか。この 9 月を振り返ってみると、いくつかの台風の上陸がありました。そのうちの一つは首都圏に猛烈な勢いをもって上陸し、数十年に一度レベルの被害をもたらしています。

また、先週には 8 年前の震災関連の事故に関する地裁判決のニュースがあり、天災の被害の恐ろしさを感じるなか、考えさせられることが少なからずありました。

画像①_634x269

リスクは経済活動に限らず、すべての活動から切り離せません。

発生可能性やインパクトが小さく、対策コストがその主体が生み出す価値を上回ってしまうような 特定のリスク“を受容する判断を下すということは合理的であり間違いではないですが、それは正しい情報を入手しての客観的な判断であるということが前提です。

判断の際は専門家の意見や集計されたデータが参照されますが、専門家自身あるいはその選択が利害関係と切り離されていることは稀なのではないでしょうか?

そして、集計されたデータは基準や軸を恣意的に操作することによりいくらでも結論を誘導できることは皆さんもご存知でしょう。

また、被害の拡大レベルが発生後の初動で決まるのは天災もサイバーセキュリティも同様です。天災の発生後、責任者がリーダシップを発揮しタイムリーに有効な対応を打っていかないと「天災後に人災化し被害が拡大した」とのそしりを免れません。

トップが直接現地入りするのがベストかどうかは一概に言えないと思いますが

事実の収集 情報の集約 責任者が判断 アクションの指示 事実の収集 情報の集約 責任者が・・・

のサイクルで一次対応をし、復旧フェーズに持っていくことが重要ではないかと考えています。
さて、これ以上は本コラムの趣旨から外れるのでこの話はここまでです…

リスクと天災については過去のコラムもご覧ください。

【エバンジェリスト・ボイス】 2018 年「災」と 2019 年「リスクコントロール」


■インターネットサービス提供事業者に対する「認証方法」に関するアンケート調査結果
少し前の話になりますがフィッシング対策協議会 ( 事務局は一般社団法人 JPCERT コーディネーションセンター ) が「インターネットサービス提供事業者に対する「認証方法」に関するアンケート調査結果(速報)」を公開しました。

外部サイト: インターネットサービス提供事業者に対する「認証方法」に関するアンケート調査結果(速報)


これはフィッシング対策協議会の認証方法調査・推進ワーキンググループがインターネットサービス事業者が採用している認証方法について以下の要領でアンケート調査を行い、その調査結果の一部を速報として公開したものです。

・実施期間: 2019 2 19 日 ~ 28
・調査対象:インターネットサービスを提供している事業者 ( 匿名 )
・回答者数: 308


■調査内容
いくつかの設問がありますが今回のコラムはこの 2 つの設問の考察をしてみます。

まずはこれです。

■インターネットサービスの個人認証を主にどのような方法で実施していますか?

画像③_518x323
出典:フィッシング対策協議会

この結果からは 3/4 のサイトはアカウント ID( メールアドレスが多いことから半分既知ですね ) に加えパスワードさえ知ることができれば不正アクセスが可能なことを示唆しています。

多要素認証( MFA )が必要なことは重々承知していながらコストや既存アーキテクチャの面から進んでいない現状が浮き彫りになっています。


次は参照先のページの設問をひとつとばしてこれです

■インターネットサービスにおけるパスワード管理は、何らかの方法で盗まれても問題ない読めない状態 (ハッシュ、暗号化など) で管理されていますか?

画像④_520x373
出典:フィッシング対策協議会

さすがに 85% 強の事業者がとりあえずは平文で読めない形でパスワードを管理しています(ただこれだけでは必ずしも安全とは言い切れません…)が、裏を返せば 15% 弱の事業者が個人認証用のパスワードを平文で管理しています。

これらの事業者のシステムではアカウント ID/ パスワードが格納されているサーバのアクセス権をたとえ一時的にであっても ( 正規の認証を迂回する方法でも ) ゲットできればリスト型攻撃に必要なアカウント ID とパスワードをまるまる入手できるということですね。


■なぜパスワードを平文で保存しているのか
今日ではパスワードの平文保存の危険性は万人が知るところとなっています。しかし、これらの 15% の時事業者はなぜ「あえて」「リスクを知りながら」「そのリスクを受容」しているのでしょうか??

いくつかのサイトを巡回し理由をピックアップしてみましょう。

画像⑤_712x688
出典: www.google.co.jp

 

理由 1
「パスワードを忘れたユーザのリクエストにサポートスタッフが素早く対応できるように」


ありがちですね。今のベストプラクティスは初回認証時に変更が必要な仮パスワードを新たに発行しユーザに送付するとなります。この場合の本人確認は登録メールアドレスや電話番号等になるでしょう。


理由 2
「システムが古く、影響範囲の調査を含めシステム変更が難しい」


セキュリティにおいて 20 年前の常識と今の常識にはかなりずれがあります。今日ではサーバはネットワークレベルでキッチリと防御しているのでサーバ内のパスワードファイルは平文でも問題ない!というわけにはいきません。このようなシステムはこれまでに何回もシステム改修・機能追加を実施していると思いますが、そのたびに認証機能の仕様は既存踏襲で進めているのでしょう。

リスクコントロールの観点からいうと多層防御を中心に、この脆弱性に対する補完コントロールを考えるのがセオリーです。しかし長期間にわたり改修を重ねたシステムは残されたドキュメントも不十分な場合が多く、どのパスワードをどのサーバにどのような形で保存しているか調査するだけでも一苦労ですし、下手にいじると場合によってはデグレ ( 品質改悪 ) の可能性もあります。

TCO(総保有コスト ) の観点からはそのシステムが生み出す価値が補完コントロールを含めた運用コスト以下であればシステムの終了も検討する必要があるかもしれません。


理由 3
「他システムとの連携の関係上、平文のパスワードを保持し送信する必要がある」


認証情報を切り出したうえで認証連携プロトコルを利用してトークンベースのやり取りにするか、面倒でもサーバ内で暗号化をするべきですが、②とも絡み、様々な理由でできないのでしょう。

リスクと対応コストのバランスに悩む部分ですが、当事者だけでは正しい判断が下せない部分もあります。第三者の意見を求めることも必要かもしれません。


■パスワードのハッシュ化
平文でパスワードを保存しないとしたらどのように保存するか?

一つは暗号化、一つはハッシュ化ですね。

暗号化は何らかの暗号鍵を持ち管理する必要があることがデメリットとなるので、パスワードの保存はハッシュ化を使用することが多いのはみなさまもご存知の通り。

これにはハッシュ関数が持つ以下の三つの特性のうち①を利用しています。

①ハッシュ値から元のメッセージを逆算できない(原像計算困難性、弱衝突耐性)
②同じハッシュ値をもつ 2 つのメッセージのペアをピックアップすることが非常に困難(強衝突耐性)
③メッセージを少しでも変えればハッシュ値は全く違うものになる

仮にハッシュ化したパスワードのリストが漏れてもシステムに入力する必要があるのは平文のパスワードであり、それは逆算できないのでとりあえずは安心ということになりますね。

パスワードのハッシュ化については危殆化していない適切なハッシュ関数を選定することが重要です。

その他ハッシュ関数やパスワードに関しては他のエバンジェリストも含め過去のコラムに記載していますので、お時間がある方はぜひご覧ください。

 

内山エバンジェリスト

【エバンジェリスト・ボイス】改めて「パスワードの定期的な変更」を考える(前編)

【エバンジェリスト・ボイス】改めて「パスワードの定期的な変更」を考える(後編)


松岡エバンジェリスト

【エバンジェリスト・ボイス】漏洩を機に振り返るパスワード暗号化


藤原エバンジェリスト

【エバンジェリスト・ボイス】キャッシュレス決済とセキュリティ


私のコラム

【エバンジェリスト・ボイス】暗号学的ハッシュ関数とブロックチェーン技術

今回はここまでです。

今年度のどこかのタイミングで攻撃者の視点でハッシュ化したパスワードへの攻撃について書くことができればと考えています。


ではまた、次回のエントリーでお会いしましょう。
 
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,

 

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。

メルマガ登録ボタン

関原 弘樹

株式会社インフォメーション・ディベロプメント フェロー / CISSP

この執筆者の記事一覧

関連するナレッジ・コラム

AIがプログラミングする時代の到来!?

残された攻撃の痕跡を追え! ~スレットハンティングのススメ~

DX推進に欠かせないデジタルリテラシーを身に付けよう