NTTコミュニケーションズ

Bizコンパス

あなたのパスワード漏れています~今どきのユーザー認証事情
2019.04.29

利用者・開発者・運営者が知っておくべきパスワードの裏側

あなたのパスワード漏れています~今どきのユーザー認証事情

著者 すずきひろのぶ (鈴木裕信)

 パソコンのブラウザからも、そしてスマートフォンからも、いろいろなクラウドサービスやウェブサービスを利用する時、パスワードを使って利用者の認証を行う方法は今日でも主流だ。

 一方でクラウドサービスやウェブサービスのパスワードが、あちこちで大量に漏れているという厳しい状況がある。つまり、パスワードは使わなければならないが、その使っているパスワードがどこかで漏れている、という矛盾ともいえる状況にある。

 今回は、パスワードがいかに脆いものであるかを示し、パスワードの仕組みの理解と問題点を議論した上で、今日重要なパスワード認証の鍵となっている二要素認証について考察してみる。

 

漏えいし続けるパスワード

 少なくとも読者諸氏において、まったくクラウドサービスもウェブサービスも利用していない、という人はまずいないであろう。たとえばビジネスユーザのための世界最大のSNSであるLinkedInにアカウントを持っている方も多いであろうし、筆者もアカウントを保持している。

 そのLinkedInは2016年に164,611,595件のパスワードが漏えいを認めている。2012年に既に外部からの不正アクセスでパスワード情報が漏えいしており、その4年後に、そのパスワード情報がダークウェブのようなアンダーグラウンドで流通していたのが発見され、初めて知ることとなった。

 ファイルをクラウド上に保管、あるいはファイルのやりとりをするのに大変便利なDropboxを使う読者も多いのではないだろうか。Dropboxも2012年以降パスワード68,648,009件が流出していることが発覚し2016年8月にすべての利用者のパスワードを強制変更するという手段に出た。

 もっとも衝撃的だったのが2019年1月に知られることとなった”Collection #1”と呼ばれるアンダーグラウンドで流れていたデータセットである。これにはメールアドレスとパスワードの組み合わせが772,904,991件含まれている。

 過去にどのような漏えいケースがあったのか興味のある方はhaveibeenpwned.com の漏えいサイトの一覧に掲載されているので、自分の目で直接確認するのが良いだろう。もちろん、ここに掲載されているケースは氷山の一角である。

 ここからもわかるように、1つのパスワードを複数のサイトで使い回していると、どこかのサイトがパスワード情報を流出させてしまえば、他のサイトすべてでリスクが発生してしまう……というよりアウトである。あとは不正にログインされるのが早いか、自分でパスワードを変更するのが早いかの問題になってしまう。

 ちなみに日本国内ではセキュリティ関連組織や企業が協力して「STOP! パスワード使い回し! キャンペーン 2018」 (期間 2018年8月1日~ 2018年8月31日)という啓発活動をおこなっていた。

 

どうすれば安全なパスワードが生成できるのか

 それでは利用者側はどうやってパスワードを作れば良いのか。ここでは利用者からみたパスワードの仕組みを考えてみる。パスワードの認証を使っているシステムでは、まず利用者が初回にパスワードを設定するか、あるいは管理者が設定したパスワードを事前に取得する。次回からそのパスワードを入力することによってシステムにログインする。

 この時、パスワードは十分な乱雑さをもつことを求められる。パスワードと呼ぶので、認証をパスするための「単語(ワード)」だと類推してしまうが、もし辞書にあるような単語を使えば、「辞書攻撃」によっていとも簡単に見つけられてしまう。

 攻撃に耐える強度を持つためには、英数字だけならば12文字以上のランダムな組み合わせたパスワードでなければ心許ない。よく「”password”という文字であれば”a”を”@”に、”o”を数字の”0(ゼロ)”に置き換える」というような説明がブログなどに書かれているのを目にするが、これは今どきの高速なコンピュータの前では焼け石に水である。人間が規則性を決めて変更しているような変換のバリエーションなど、高速な計算能力の前では無意味に等しい。

 ランダムな文字列を生成するためには、最近ではパソコンのセキュリティ管理ツールではパスワードマネージャーが用意されておりパスワードの生成・管理を行えるものもあるので、そのようなツールを使うと良いだろう。

 筆者はWindows 10にUbuntuをインストールしているので GNU/Linuxと共通なパスワード生成コマンド「pwgen 」を利用している。またパスワードでも自分でいちいち覚えるようなことはせず(覚えようとしてもそもそも無理である)、パスワードはWebブラウザのパスワード管理を利用している。もちろんすべてのサイトのパスワードは異なるものを使っている。

 

登録先でパスワードはどのように管理されているのか?

 さて、安全なパスワードが用意できたとして、そのパスワードを登録する相手側システム中ではどのように扱われるのだろうか。

 まず思いつくのは、パスワードの文字列をデータベースに登録する方法だ。ログインの際はアカウント名とパスワード文字列の組み合わせを与えると登録しているパスワード文字列を検索し比較するというモデルである。

 たしかに、これでもパスワードの認証機能は満たせるが、大きな問題がある。それは万が一にでもパスワードを登録しているデータベースの内容が外部に漏れてしまったら、このシステムのセキュリティ崩壊してしまう。なぜならシステムに登録しているすべての利用者のパスワードを使い放題だからである。

 このケースが2019年1月に発生した「ファイル転送サービス『宅ふぁいる便』」の利用者個人情報漏洩である。ここでは今回のテーマであるパスワードについてのみ取り上げるが、この漏洩ケースでは4,815,399件のログイン用メールアドレスとログインパスワードの組み合わせが外部からの不正アクセスで流出している。その中には退会者42,501件も含まれる。

 もっと悪いことに、この流出したログインパスワードは、なんの加工もされておらず、そのまま使える文字列であったことだ。クラウドサービスやウェブサービスでは、ログインのためのアカウント識別名にメールアドレス、そしてパスワードの組み合わせを利用しているところは多い。

 もし、この流出した利用者がパスワードを使い回しているならば、「宅ふぁいる便」だけではなく、他のパスワードを使い回しているサイトに不正アクセスされるのは時間の問題となる。退会者は既に使っていたことを忘れているかもしれないが、しかしリスクは現役利用者と同じである。

 システムの中のパスワードは暗号化されていて、たとえパスワード認証のための情報が入っているファイルやデータベースが外部に流出したとしても、一定の安全性を保つことが可能でなければならない。「パスワードを暗号化してシステムの中で保持する」と表現しているので、暗号化しているならば、復号し元のパスワードがわかるだろうと類推するかもしれない。

 しかし、この処理には一方向性ハッシュ関数が用いられ、パスワードは変換され、元に戻ることはない。利用者が入力したパスワードは一方向性ハッシュ関数で処理され、既に処理されたデータを比較し、同等であることを確認することでパスワードが正しいかどうかを判断する。実装ではさらにソルト(Salt)と呼ばれる値がアカウント毎に付加された上で処理がおこなわれ、パスワードが同じでも一方向性ハッシュ関数の出力値が異なるようにしている。

 この手法は昨日今日生まれたものではなく、少なくとも1979年には公知のものとなっており、パスワードを組み込むようなシステムを設計・実装する技術者であれば当然知っていて当たり前の内容である。

 このようなパスワード管理をしていれば、たとえパスワードファイルが漏えいしても、ランダムな英数字12文字からなるパスワードを見つけ出そうとすると大量な計算資源を投入しなければならず、現実的にはこのようなアプローチからパスワードを解析するのは困難を極める。

 

パスワードのみでの認証は既に限界

 がしかし、現実を見ると、一定数の利用者は、ランダムな英数字12文字などではなく、どこかで聞いたことがあるような文字列をパスワードに選ぶ。 2012年に米Yahoo!から漏えいした45万件のパスワードを解析した結果が公表されており、そのパスワードのリストには”12345”といったものや”password”、”ninja”という実に貧弱なパスワードが並んでいる。これではパスワードの役割を果たさない。

 選ぶ利用者も利用者だが、このような脆弱なパスワードを受け付けるシステムもシステムである。 2012年当時のパスワードに対する利用者・開発者・運営者の認識がどのようなものであったのかが垣間見られる事例だといえよう。

 「Top 500 最悪なパスワード」というウェブページのリスト中に”ncc1701”というパスワードが入っている。なんの脈略もない英数字の羅列に見えるが、これは知る人ぞ知る、ドラマ「スタートレック」に出てくる宇宙船・初代エンタープライズのシップ・ナンバーなのである。このように人間がパスワードとして選ぶ方法では限界がある。

 もちろん完全にランダムで十分に長い文字列をパスワードとして用意したところで、パソコンやスマートフォンがマルウェアに感染していて使ったパスワードを検知して外部に漏えいさせる可能性もある。

 

スマートフォンと連携した多要素認証の導入

 こうした状況を受け、最近では「多要素認証」が導入がすすんでいる。多要素認証とは、複数の異なる方法で認証を行う手法である。最近では2つの異なる方法を使い認証を行う二要素認証も珍しくはなくなってきている。

 まず電話番号を最初に登録しておき、新規のパソコンなどからログインした際には、スマートフォンに音声電話、あるいはメッセージで認証番号が届けられ、その認証番号を入力しなければログインできないなどが行われる時代になってきている。

 例えば、なんらかの理由でパソコン側からパスワードが漏えいしたとしても、パソコンとは違う通信経路であるスマートフォンに、ショートメッセンジャーや、あるいは音声で届けられる認証番号を入手できなければ、ログインすることはできない。

 ここでのポイントは、直接関連していない2つの要素を使うという点である。本当なのか冗談なのかわからないが、最初の画面で第一パスワードが求められ、そこを通過すると第二パスワードを求められるウェブサービスがあるという話を小耳に挟んだ。これでは利用者名とパスワードを2回入れることは同じ「要素」を2回しただけになり、2つの異なる「要素」を使ったことにならない。あくまでもこれは笑い話で、実際にそのようなシステムがないことを祈らずにはいられない。

 オンラインバンキングなどへのログインや送金時の最終確認の際には、パスワードだけではなく、銀行から提供された使い捨ての認証コードを生成するセキュリティ・トークンを使い、刻々とかわる数字やコードを入力するのが当たり前のようになって来ている。このような方法が極めて有効であっても、セキュリティ・トークンを別途用意するようなことは、コスト的にもそのセキュリティ・トークンを管理するのも、利用者にとっても負担となるであろう。

 そこで紹介したいのが、スマートフォンに簡単に使える使い捨ての認証コードを生成するアプリ 「Google 認証システム」だ。

 これはRFC6238というインターネットの標準化規約ドキュメントで示されているTOTP (Time-Based One-Time Password Algorithm、時間ベースのワンタイムパスワード)を実装しているので、RFC6238のTOTPを採用しているクラウドサービスやウェブサービスで利用することが可能である。

 筆者はGoogle、Facebook、Twitter、Dropboxなどで利用している。このRFC6238 のTOTPは仕組みさえきちんと理解していれば、オープンソースのライブラリ実装も豊富にあり、導入するのも容易であろう。

 

RFC6238のTOTPを使った二要素認証を提案したい

 2019年では、これまでのパスワード認証方式では限界が来ているとわざるを得ない。しかし現状では、まだまだパスワード認証方式を使わざるを得ない。

 今後はこれまでのパスワード認証方式に加えて、身近なスマートフォンと組み合わせることで、二要素認証が広まっていくことであろう。そして新規でクラウドサービスやウェブサービスを開発あるいは導入することを考えているならば、Google認証システムでも採用しているRFC6238のTOTPを使った二要素認証を取り入れることを提案したい。

※掲載している情報は、記事執筆時点(2019年4月23日)のものです。

すずきひろのぶ (鈴木裕信)

すずきひろのぶ (鈴木裕信)

80年代よりUNIXやネットワークのエキスパートとして活躍し90年代よりコンピュータセキュリティに携わる。現在は業務アプリケーションにSELinuxを適用し安全性を高める研究に従事。近著「マジメだけどおもしろいセキュリティ講義 事故が起きる理由と現実的な対策を考える (Software Design plusシリーズ)」絶賛発売中

この記事が気に入ったらクリック!

お気に入り登録

関連キーワード

SHARE

関連記事