KNOWLEDGE - COLUMN ナレッジ - コラム

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

サイバー・セキュリティ・ソリューション(CSS)部
エバンジェリスト 松岡 政之     matsuoka2_274x380


こんにちは。CSS部エバンジェリストの松岡です。

当社HPイベントニュースでも発表されていますが、「第5回 BAPT主催 サイバーセキュリティ対策セミナー」で講演をすることとなりました。
私の講演では「人手からAI-SOCへ ネットワーク監視はSeceonにお任せ!」と題し、
組織にとって優先度の高いタスクに専念できる環境づくりのために、リアルタイムでネットワーク監視・解析をセキュリティ人材に代わって行うAIセキュリティソリューションの導入をご提案いたします。

AIによるネットワーク振る舞い検知製品Seceon OTM


私のほかにも多くのプロフェッショナルの方が講演されますのでご都合のつく方はぜひ参加申し込みいただければ幸いです。

【2019年3月5日(火) 】第5回 BAPT主催 サイバーセキュリティ対策セミナー


さて、今回の本題です。
1月25日に宅ふぁいる便で約480万件にも上るメールアドレスやログインパスワードの漏洩が発表されました。
近年、大騒ぎになった事例としては2015年の日本年金機構の事例で約125万件ですから、480万件という件数は日本国内でのサイバー攻撃による情報漏洩事件としてはトップクラスの件数ではないでしょうか。
このような膨大な件数になってしまった原因の一つとして、退会したお客様の情報も保持していたことが挙げられます。

個人情報というものは非常に価値があり、企業活動を行う上でも必要となる場面が多くあります。
しかし、サイバー攻撃による情報漏洩が対岸の火事でなくなった昨今、利用しなくなった個人情報を保持しておくことはもはやリスクでしかないと思います。

また、今回のケースでは件数にも驚きですが、漏洩したパスワードが暗号化されていなかったということがさらに驚きです。
昨今のシステムではシステム側で保持しているパスワードは復号できない形で暗号化(ハッシュ化)されているのが当たり前になってきているかと思います。

今回被害にあった宅ふぁいる便は1999年にサービス開始をしています。
確かにそのころはパスワードの暗号化という言葉は一般的に聞くこともなかったかもしれません。

実際、2000年代前半に当時フリーで配布されていたCGIゲームを改造してホームページに設置・公開していたことがありますが、管理画面からはパスワードが平文で丸見えでした。当時の私も何の疑問も持っていませんでした。

話を戻しますと、古くからサービスを提供しておりパスワードの暗号化対応を明確に謳っていないシステムはパスワードの暗号化がされていない可能性が推測できるということです。

それではパスワードが暗号化されていれば安全なのでしょうか。
その前に暗号化とは?というところから少しお話します。(当方暗号の専門家ではないので軽く触れる程度にとどめますが)

まず、一般的に暗号化というと、皆さんのPCやスマホ(クライアント)とサーバ間などの通信経路でデータを盗聴されないために使用される暗号が挙げられます。
この場合の暗号は、送信元で暗号化されたデータは送信先で復号化することで元のデータに戻せる可逆暗号です。

一方、パスワードの暗号化は不可逆暗号でハッシュ化といった方がわかりやすいでしょうか。
ハッシュ化とはデータをハッシュ関数で処理することで一見するとランダムな固定長のデータに変換することです。
同じハッシュ関数に同じデータを入力すると必ずおなじデータ(ハッシュ値)が得られます。変換されてできたハッシュ値は、基本的には元の値を割り出すことや、同じハッシュ値を持つ別のデータを生成することは難しいとされています。

基本的にはと書いたのは、安全でないハッシュ関数を用いるとPC等による計算で現実的な時間内で同じハッシュ値を持つデータを作ることができてしまいます。
有名なものとしてはMD5やSHA-0/SHA-1はすでに安全でないハッシュ関数とされており、現在ではSHA-256以上の利用が推奨されています。

では、パスワードは暗号化されていれば安全なのか、という問いに戻ります。
先ほどまでの話を加味すると、SHA-256等のまだ破られていないハッシュ関数でハッシュ化されていれば安全か、という話です。

この問いには、「はい」とは答えきれません。
例えば、不正に入手されたパスワードのリストがSHA-256でハッシュ化されていたとします。もちろん、現在のPCの計算速度ではこれを破る手法は考案されていません。

しかし、このパスワードリストに同じハッシュ値の物がたくさんあったとしたらどうでしょう。
先ほどのハッシュ化の話の中で同じデータを入力すると必ず同じハッシュが得られるという話をしたかと思います。

このことから、これらは同じパスワードを使っているということが推測できます。
すると、多くの人が使っている=よく使用されるパスワード(12345やpasswordなど)ということが想定されてしまいます。
よく使用されるパスワードだと推測できてしまえば候補はかなり絞られるため、ブルートフォース(総当たり)攻撃で突破されてしまう可能性が高くなってしまいます。

また、平文とハッシュ値のペアを記録した特殊なテーブルを使用してハッシュから平文を得る時間を短縮するレインボーテーブルと呼ばれるテクニックからも脆弱になってしまいますが、それは少し難しい内容なのでここでは割愛します。

これを防ぐために、パスワードハッシュ化の実装では一般的に以下の2つの手法が組み合わせて使われています。
①ハッシュ化する前にソルトを付与する
②ストレッチングを行う

①はハッシュ化する前のデータにソルトと呼ばれる乱数を付与する方法です。
これにより、同じデータでもランダムなソルトが付与されてハッシュ化されるので異なるハッシュ値を得ることができます。
②はハッシュ値の計算を何度も繰り返し行う方法です。
何度も(数千~数万回)ハッシュ値の計算を行うことで同じハッシュ値の元データを求めるまでの時間を長くすることができます。

さて、パスワードの漏洩事件を機にパスワードの暗号化について少し振り返ってみました。
私たちが利用しているサービスの向こう側でパスワードがどのように保存されているかについて興味を持っていただけたでしょうか?
利用者が意識を高めることで、サービス提供者側の安全意識にもより圧力をかけることができるのではないかと思います。

しかし、これらの手法を使い適切に暗号化を適用しているかなど、サービス利用者が安全性を判断するための情報が公開されているサービスは少ないのが現状です。
出来ればこういった手法を適用し安全に管理していることをきちんと公開しているサービスを利用していきたいですね。

それではまた、次回のエントリーでお会いしましょう。

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

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

メルマガ登録ボタン

松岡 政之

株式会社インフォメーション・ディベロプメント デジタルソリューション営業部 エバンジェリスト

この執筆者の記事一覧

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

ITエンジニアの現地作業 ミスを減らす!作業本番のポイントとは

NTTのIP網移行と、通信の未来とは

ITエンジニアの現地作業 ミスを減らす!事前準備のポイントとは