なぜ、パスワードを平文で保存するのですか？【追記あり】：こうしす！ こちら京姫鉄道 広報部システム課 ＠IT支線（12）

情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第12列車は「サービス提供側のセキュリティ」です。

[原作：井二かける（OPAP-JP）, 作画：るみあ（OPAP-JP），＠IT]

「こうしす！」とは

ここは姫路と京都を結ぶ中堅私鉄、京姫鉄道株式会社。

その情報システム（鉄道システムを除く）の管理を一手に引き受ける広報部システム課は、いつもセキュリティトラブルにてんてこ舞い。うわーん、アカネちゃーん。

「こうしす！＠IT支線」とは

「こうしす！」制作参加スタッフが、＠IT読者にお届けするセキュリティ啓発4コマ漫画。

今回の登場人物

祝園アカネ

広報部システム課係員。情報処理安全確保支援士。計画的怠惰主義者で、有休取得率は100％。しかし、困っている人を放っておけない性格が災いし、いつもシステムトラブルに巻き込まれる

英賀保芽依

広報部広報課係員。天才的トラブルメーカーで、システム課やシステム子会社からは「アルティメットバグトリガー」として知られる。アカネの同期

山家宏佳（YAMAGA Hiroka）

広報部システム課　課長。かつて『ひとりSE』として、鉄道事業の単体黒字化という大きな実績を残した実力者。システム課の復活を取り付け、最年少での課長への飛び級昇進をしたものの、個性的な部下に振り回される日々を送っている。

第12列車：パスワード、平文保存、ダメ絶対！

井二かけるの追い解説

　今回の漫画は、サービス提供側のセキュリティについての話です。

　Webサービスの利用者を認証する目的でシステムにパスワードを保存する場合、必ず守らなければならない鉄則があります。

利用者のパスワードの平文保存はダメ、絶対。

必ずハッシュ化して保存する！

　ということです。

平文保存したパスワードが漏えいしたら

　ここでいうパスワードの平文保存とは、パスワードを暗号化も何もしない状態でそのまま保存することです。このような保存方式は危険です。なぜならば、万が一漏えい事故の際にパスワードも一緒に漏えいする恐れがあるためです。

　既に報じられている通り、2019年1月に大きなセキュリティ事故が発生しました。

参考リンク

「宅ふぁいる便」不正アクセスで480万件のユーザー情報流出　メアド・パスワードも（ITmedia NEWS）

　この事例では、パスワードが平文で保存されていたために、ユーザー情報と一緒にパスワードまで流出する事態となりました。

　この事例では、以下の二次被害が発生する恐れがあります。

1．漏えいしたユーザー名とパスワードを用いて、そのWebサービスに不正ログインされ、さらなる被害を生む

　宅ふぁいる便の事例の場合、不正ログインによりアップロードされたファイルも流出した可能性が考えられます。利用者が一番危惧しているのはこの点ですが、執筆時点では、流出があったのか、公式リリースでは触れられていません。利用者は最悪を想定しなければならない状況です。

2．漏えいしたユーザー名とパスワードを用いて、他のWebサービスに不正ログインされ、さらなる被害を生む

　利用者が複数のWebサービスで同じパスワードを使い回していることは、よくあるケースです。他のWebサービスへの不正ログインにより、情報漏えいだけでなく、金銭的な被害が発生する可能性も否定はできません。

　残念なことに、このような大きなリスクがあるにもかかわらず、パスワードを平文で保存しているWebサービスが多くあります。筆者も、有名なショップのECサイトや、有名企業の採用サイトで、パスワードを平文保存しているケースに遭遇したことがあります（残念ながら、その企業には一次面接でお祈りされました）。

　平成27年に200社弱の企業を対象に行われた総務省の調査では、28社が回答し、そのうち「全体で4割以上のサービスがパスワードのハッシュ化を行っておらず、特に無料のサービスでは7割がハッシュ化を行っていない」ことが明らかになっています。

参考リンク

ウェブサービスに関するID・パスワードの管理・運用実態調査結果（総務省）

平文がだめなら、ハッシュ化すればいいじゃない

　では、サービス提供者はどのようにパスワードを保存すれば良いのでしょうか。

　キーワードは「ハッシュ化」です。以下のようにパスワードからハッシュ値を算出することをハッシュ化といいます。

元のパスワード「32aetwomkjgds」

↓とある方式でハッシュ化

ハッシュ値「57d49e4a62b566fd82f305f1d8ed9e13d5c0c7c479b722108ef71a7ab2a09d36」

元のパスワード「5atewgf」

↓上記と同じ方式でハッシュ化

ハッシュ値「e6a420f5b7ed89d7f404b02411f4e53cf207cf2e6b0c0364b6731d1e5a0c6296」

　以下は、このハッシュ値の性質です。

• 同じパスワード、同じ方式であれば、ハッシュ値は同じになる
• 異なるパスワードであれば、同じ方式でも、ハッシュ値は異なる
• ハッシュ値から元のパスワードを復元することは非常に困難である

　「同じパスワード、同じ方式であれば、ハッシュ値は同じになる」という性質を利用すれば、パスワードを保存せずとも、パスワードのハッシュ値さえ保存すれば、認証処理には十分です。なぜなら、認証処理のたびに、利用者の入力値から同じ方式でハッシュ値を算出し、そのハッシュ値と、保存しているハッシュ値とを比較すれば良いからです。

ハッシュドパスワードの処理手順

　例えば、ユーザー登録時の処理を以下の手順で行います。

1. 利用者Aがパスワードとして「32aetwomkjgds」を登録する
2. システムはそのハッシュ値である「57d49e〜（略）」を保存する

　ログイン時の認証処理は以下の手順で行います。

1. 利用者Aがログインするとき、パスワード「32aetwomkjgds」を入力する
2. システムは入力された「32aetwomkjgds」から、そのハッシュ値を算出する
3. 上記の結果が「57d49e〜（略）」となり、ユーザー登録時に保存されたハッシュ値である「57d49e〜（略）」と一致することから、正しいパスワードが入力されたことを判断できる

　もし、パスワードが誤っていれば以下のようになります。

1. 利用者がログインするとき、誤ったパスワード「5atewgf」を入力する
2. システムは入力された「5atewgf」から、そのハッシュ値を算出する
3. 上記の結果が「e6a420〜（略）」となり、ユーザー登録時に保存されたハッシュ値である「57d49e〜（略）」と異なることから、誤ったパスワードが入力されたと判断できる

　このように、パスワードの平文保存を行わずとも、ハッシュ値の保存のみで認証処理を行えます。

算出方式が単純だと危険

　パスワードのハッシュ化は、「ハッシュ値から元のパスワードを復元することは非常に困難である」という性質から、万が一ハッシュ値が漏えいしても、直ちに二次被害が発生するリスクを低減できます。

　なお、実際には、ハッシュ値を計算する方式に工夫が必要です。

　既に述べたように、同じパスワードであれば同じハッシュ値となります。複数の利用者が同じパスワードを登録していた場合、ハッシュ値を単純に算出するだけでは、それらのハッシュ値は全て同じとなります。

　この状態で、もし利用者名とパスワードのハッシュ値が漏えいすれば、ある利用者が、別の利用者も同じパスワードを登録していることを知ることになります。その利用者は、別の利用者名と自分のパスワードを入力することで不正にログインするかもしれません。

　さらに、悪意のある攻撃者は、よくあるパスワードとハッシュ値の対応表をあらかじめ作成し、パスワードを特定しようとするでしょう。

　このようなリスクへの対策としては、同じパスワードでも異なるハッシュ値となるよう、パスワードにランダムな「ソルト」を付加してハッシュ化するという手法を用いるのが一般的です。

　また、脆弱（ぜいじゃく）なパスワードの場合、たとえハッシュ化していたとしてもオフライン総当たり攻撃などですぐにハッシュ値からパスワードを割り出される恐れもあります。

　割り出されるまでの時間を稼ぐためには、ハッシュ値のハッシュ値を繰り返し求める「ストレッチング」という手法を用います。

　また、極めてまれに、異なるパスワードでも同じハッシュ値となってしまう「衝突」と呼ばれる事象が発生することがあります。これを意図的に発生させる「衝突攻撃」と呼ばれる攻撃手法も存在します。従って、ハッシュ値の算出方式は、衝突が発生する確率が十分低い方式を用いなければなりません。

2019年2月13日17:50 追記：ソルトとストレッチングに関する説明を追加しました（編集部）。

ハッシュ化して保存されていないことを利用者が推測できるケース

　余談ですが、パスワードが平文で保存されているかどうかを利用者が確認できるケースがあります。

　漫画のように「パスワードを忘れた」ときの手続きを行った際に、以前登録した自分のパスワードがメールに記載されていたら、そのサービスではパスワードがハッシュ化されずに保存されています。

2019年2月8日13:40 追記：当初「平文で保存されています。」と記載しましたが、平文の場合のほか、復号可能な暗号化を施して保存されている場合も考えられますので、修正いたしました。ご指摘に感謝します。なお、本記事では割愛しましたが、復号可能な暗号化だけでは対策としては不十分です。暗号鍵もしくは暗号方式が脆弱な場合や、暗号鍵も一緒に漏えいした場合など、暗号化されたパスワードを復号して平文を得ることが容易な場合があるためです。

　このように脆弱なWebサービスを見つけた場合にすべきことは、SNSにさらす――ではなく、当該サービスの運営企業のセキュリティ関連窓口への連絡するか、情報処理推進機構（IPA）の脆弱性関連情報の届け出制度を活用する、です。

参考リンク

脆弱性関連情報の届出受付（IPA）

---

　最後に、繰り返しになりますが、Webサービスを設計するときは、必ず以下の点を守ってください。

利用者のパスワードの平文保存はダメ、絶対。

必ずハッシュ化して保存する！

よく分からないけど、ハッシュドポテトが食べたくなったよ

まあ、「ハッシュドポテト、芋に戻らず」ってことです（投げやりに）

参考リンク

ハッシュとソルト、ストレッチングを正しく理解する：本当は怖いパスワードの話

安全なウェブサイトの作り方（IPA）

こうしす！第3話Part1「セキュリティに完璧を求めるのは間違っているだろうか」（OPAP-JP公式）

Copyright 2012-2017 OPAP-JP contributors.
本作品は特に注記がない限りCC-BY 4.0の下にご利用いただけます

筆者プロフィール

作画：るみあ

フリーイラストレーター。アニメ「こうしす！」ではキャラクターデザイン・キャラ作画担当をしています。

原作：井二かける

アニメ「こうしす！」監督、脚本。情報処理安全確保支援士。プログラマーの本業の傍ら、ボランティアとしてセキュリティ普及啓発活動を行う。小説を出版することを夢見て、アカネとツバメが脇役として活躍する小説「NebulAI.HOSXI // アップデートは三世紀後に」を、サイバーセキュリティ小説コンテストに応募。中間選考を突破したものの、最終選考候補に残れず。傷心のまま今回の記事を執筆。

• Webサイト：IBUTA Kakeru Web Site
• Twitter：@k_ibuta

原作：OPAP-JP contributors

オープンソースなアニメを作ろうというプロジェクト。現在はアニメ「こうしす！」を制作中。

• Twitter：@opap_jp、@kosys_pr
• 公式サイト：Open Process Animation Project Japan (OPAP-JP)
• 貢献者一覧：こうしす！/クレジット