Contents
パスワードの裏側…
パソコンのブラウザからも、そしてスマートフォンからも、
いろいろなクラウドサービスやウェブサービスを利用する時、パスワードを使って利用者の認証を行う方法が主流だと思います。
一方でクラウドサービスやウェブサービスのパスワードが、あちこちで大量に漏れているという現状があるんです・・・
パスワードは使わなければならないが、その使っているパスワードがどこかで漏れている・・・矛盾してますよね。
パスワードがいかに脆いものであるかをお伝えしていきます。パスワードの仕組みの理解と問題点を確認し、
重要なパスワード認証の鍵となっている二要素認証について考えていきましょう。

スマートフォンと連携した多要素認証…
最近では「多要素認証」が導入がすすんでいますね。
多要素認証とは、複数の異なる方法で認証を行う手法のことです。
最近では2つの異なる方法を使い認証を行う二要素認証もよく聞く話だと思います。
電話番号を最初に登録しておき、新規のパソコンなどからログインした際には、
スマートフォンに音声電話、あるいはメッセージで認証番号が届けられ、
その認証番号を入力しなければログインできないなどがよくありますよね。

例えば・・・
なんらかの理由でパソコン側からパスワードが漏洩したとしても、
パソコンとは違う通信経路であるスマートフォンに、ショートメッセンジャーや、
音声で届けられる認証番号を入手できなければ、ログインすることはできないようになっています。
大事なポイントは、直接関連していない2つの要素を使うという点です。
オンラインバンキングなどへのログインや送金時の最終確認の際には、
パスワードだけではなく、銀行から提供された使い捨ての認証コードを生成するセキュリティ・トークンを使い、
刻々とかわる数字やコードを入力するのが当たり前のようになって来ていますよね。
このような方法が有効であっても、セキュリティ・トークンを別途用意するようなことは、
コスト的にもそのセキュリティ・トークンを管理するのも、利用者にとっても負担となりますよね。
そこで、スマートフォンに簡単に使える使い捨ての認証コードを生成するアプリ 「Google 認証システム」というのがあります。

これはRFC6238というインターネットの標準化規約ドキュメントで示されているTOTP (Time-Based One-Time Password Algorithm、時間ベースのワンタイムパスワード)を実装しているので、
RFC6238のTOTPを採用しているクラウドサービスやウェブサービスで利用することが可能なんです。
Google、Facebook、Twitter、Dropboxなどで利用できます。
このRFC6238 のTOTPは仕組みさえきちんと理解していれば、オープンソースのライブラリ実装も豊富にありますし、導入するのも簡単なんです。
漏洩するパスワード
少なくともみなさん、まったくクラウドサービスもウェブサービスも利用していない、という人はまずいないと思います。
たとえばビジネスユーザのための世界最大のSNSであるLinkedInにアカウントを持っている方も多いのではないでしょうか?
そのLinkedInは2016年に164,611,595件のパスワードが漏洩を認めています。
2012年に既に外部からの不正アクセスでパスワード情報が漏洩しており、
4年後には、そのパスワード情報がダークウェブのようなアンダーグラウンドで流通していたのが発見されました。
ファイルをクラウド上に保管している。あるいはファイルのやりとりをするのに大変便利なDropboxを使う方もいらっしゃると思います。
Dropboxも2012年以降パスワード68,648,009件が流出していることが発覚しています。
2016年8月にすべての利用者のパスワードを強制変更するということもありましたね。

1つのパスワードを複数のサイトで使い回していると、
どこかのサイトがパスワード情報を流出させてしまえば、他のサイトすべてが漏洩したも同じ状況になってしまいます。
あとは不正にログインされるのが早いか、自分でパスワードを変更するのが早いか…。
どうすれば安全なパスワードになるのか
どうやってパスワードを作れば良いのでしょうか。
よくあるパスワードの仕組みを考えてみたいと思います。
パスワードの認証を使っているシステムでは、まず初回にパスワードを設定するか、管理者が設定したパスワードを使用することでしょう。
次回からそのパスワードを入力することによってシステムにログインしていきますよね。

この時、パスワードは十分な乱雑さをもつことを求められています。
パスワードと呼ぶので、認証をパスするための「単語(ワード)」と考えてしまいますが、
もし辞書にあるような単語を使えば、簡単に割り出せてしまうことが多いでしょう。
よく「”password”という文字であれば”a”を”@”に、”o”を数字の”0(ゼロ)”に置き換える」というような説明がブログなどに書かれていますが、
割り出されないためには、英数字だけならば12文字以上のランダムな組み合わせたパスワードでなければ正直簡単にばれてしまうんです。
これは今どきの高速なコンピュータの前では無意味と言えると思います。
ランダムな文字列を生成するためには、最近ではパソコンのセキュリティ管理ツールではパスワードマネージャーが用意
されていますし、
パスワードの生成・管理を行えるものもあるので、そのようなツールを使うと良いと思います。
パスワードの管理のされ方とは…
安全なパスワードが用意できたとしても、そのパスワードを登録する相手側システム中ではどのように扱われているのでしょうか?
パスワードの文字列をデータベースに登録する方法があります。
ログインの際はアカウント名とパスワード文字列の組み合わせを与えると登録しているパスワード文字列を検索し比較するというものですね。
これでもパスワードの認証機能は満たせますが、大きな問題があるんです。

それは万が一にでもパスワードを登録しているデータベースの内容が外部に漏れてしまったら、
このシステムのセキュリティ崩壊してしまいます。なぜならシステムに登録しているすべての利用者のパスワードを使い放題だからです。
過去にも実際に漏洩したことによって、退会済みのアカウントも不正利用されたケースもありました。
しかも、ログイン情報として登録していたのがメールアドレスとパスワードの組み合わせのものだったために、
同じクラウドサービスやウェブサービス内でも同じものを使っていた人は、そちらのアクセスも容易にされていたこととなります。
システムの中のパスワードは暗号化されていて、パスワード認証のための情報が入っているファイルやデータベースが外部に流出したとしても、
一定の安全性を保つことが可能でなければなりません。
「パスワードを暗号化してシステムの中で保持する」と表現しているので、暗号化しているならば、
復号し元のパスワードがわかるだろうと類推するかもしれませんね。
この処理には一方向性ハッシュ関数が用いられ、パスワードは変換され、元に戻ることはありません。
利用者が入力したパスワードは一方向性ハッシュ関数で処理され、既に処理されたデータを比較し、
同等であることを確認することでパスワードが正しいかどうかを判断することができます。
さらにソルトと呼ばれる値がアカウント毎に付加された上で処理がおこなわれ、
パスワードが同じでも一方向性ハッシュ関数の出力値が異なるようになっています。
この手法は40年前には公知されているもので、
パスワードを組み込むようなシステムを設計・実装する技術者であれば当然知っていて当たり前のことなのです。
このようなパスワード管理をしていれば、たとえパスワードファイルが漏洩しても、
ランダムな英数字12文字からなるパスワードを見つけ出そうとすると
大量な計算資源を投入しなければならず、現実的にはこのようなアプローチからパスワードを解析するのは困難となります。
パスワードのみでの認証は限界を超えている…

ただ、現実を見ると、一定数の利用者は、ランダムな英数字12文字などではなく、
どこかで聞いたことがあるような文字列をパスワードに選ぶことが多いでしょう。
過去にパスワードが解析され、パスワードのリストには”12345”といったものや”password”、”ninja”という実に安易なパスワードが並んでいました。これではパスワードの役割を果たしませんね…。
このような安易なパスワードを受け付けるシステムもシステムですが…。
最悪なパスワードのランキングされているサイトがあり、その中に”ncc1701”というパスワードが入っています。
なんの脈略もない英数字の羅列に見えますが、これは知る人ぞ知る、ドラマ「スタートレック」に出てくる
宇宙船・初代エンタープライズのシップ・ナンバーなのです。
このように人がパスワードとして選ぶ方法では限界があることがわかります。
もちろん完全にランダムで十分に長い文字列をパスワードとして用意したところで、
パソコンやスマートフォンがマルウェアに感染していて使ったパスワードを検知して外部に漏洩させる可能性もあるわけですが…。
RFC6238のTOTPを使った二要素認証
これまでのパスワード認証方式では限界が来ています。ただ、パスワード認証方式を使わざるを得ないのが現状です。
今後はこれまでのパスワード認証方式に加えて、身近なスマートフォンと組み合わせることで、二要素認証が広まっていくとは思います。
そして新規でクラウドサービスやウェブサービスを開発あるいは導入することを考えているならば、Google認証システムでも採用しているRFC6238のTOTPを使った二要素認証を取り入れることをお勧めします!

最新の更新を
プッシュ通知で購読しよう
最近のコメント