高木浩光＠自宅の日記

■ SSLを要するモバイル環境でのパスワードマネージャの使い方に注意

Basic認証の話

この日記にSSLを導入した*1。基本的には自分用（編集時の安全を確保する）のもので、FirefoxとSafari（Mac OS版のSafari）からしか使えない*2*3。これにより、外出先の公衆無線LANからでも日記を編集できるようになった。

これまでは、自宅のコンピュータでしかログインしないようにして、http:// のままBasic認証を使っていた。パスワードが生のまま送信されるが、自宅の通信環境はまあ信頼できるので、（その先の通信路上で盗聴されるリスクがあるにしても）リスクは受容できると考えてきた。しかし、外出先で公衆無線LANを使うとなると、そのリスクは受容できない。6日の日記「公衆無線LANで使うと危ないiPod touchアプリに注意」にも書いたように、公衆無線LAN内の通信は簡単に傍受されてしまうし、偽アクセスポイントにつながってしまっても気付けない危険があり、https:// でのアクセスを必要としていた。

今回SSLを導入したので、このまま自宅のコンピュータを外に持ち出して公衆無線LANにつないでよいかというと、そうではない。なぜなら、たとえば、自宅でログインした後に、ブラウザを終了しないで、公衆無線LANにつないだとすると、ブラウザが覚えているBasic認証のパスワードが自動的に送信されてしまうからだ。

この危険は、「公衆無線LANに接続中は https:// でアクセスする」という使い方では防げない。なぜなら、たとえ目的サイト（たとえば自分の日記サイト）について https:// でアクセスするように心がけていても、その他のサイトではどうしてもどこかで http:// でアクセスせざるを得ない。その際に、通信路上でHTTPレスポンスを改竄されると、目的サイトの http:// 画面にリダイレクトさせられてしまう可能性があるからだ。そのときリダイレクトでジャンプした瞬間にパスワードが生で送出され、盗聴されてしまう。

したがって、公衆無線LANに接続することがあるかもしれないコンピュータでは、日頃から常に （Basic認証の）ログインは https:// で行うようにしておくのが正しい*4。

といっても、一般の利用者にとってこの話は難しすぎるので、一般向利用者けにBasic認証を提供するのはやめた方がよいだろう。

パスワードマネージャの話

これに類する話として、ブラウザのパスワードマネージャの使い方にも注意が必要である。

たとえば、mixiのログイン画面（図1）はどう使うのが正しいだろうか。

図1: mixiのログイン画面

図1（上）のログインボタンの下に「SSL(https)はこちら」というリンクがある。これをクリックするとアドレスバーが同図（下）のようになる。これはどう活用するのが正しいか。

「自宅パソコンから使うときは最初の画面のままログインしてもよいが、公衆無線LANで使うときは必ず『SSL(https)はこちら』をクリックして、https:// の画面（図1下）になったのを目視確認してからパスワードを入力するようにする。」

この理解は正しい。Webサイト運営者側はそのつもりでこのようにしている。

しかし、問題はWebブラウザに搭載されているパスワードマネージャ機能の使い方である。

自宅の安全な通信環境で、http:// の画面でログインしたとしよう。初めてログインしたときは、ブラウザの上部が図2のようになり、入力したパスワードをパスワードマネージャに記憶させるか否かを尋ねられる。

図2: パスワードマネージャの「このパスワードを記憶させますか？」

ここで「記憶する」ボタンを押して、パスワードをブラウザに覚えさせた場合どうなるか。これを押すと、次回以降、ログイン画面で図3のように、自動的にユーザ名とパスワードが入力欄に挿入されるようになる。

図3: パスワードマネージャによりパスワードが自動的に挿入された様子

これは、このページにアクセスしただけでこのように自動挿入されるようになっている（Firefox、Safari、Google Chrome等の場合）。

ということは、この操作をしたコンピュータは、公衆無線LANなどでの接続を許すと、パスワードを盗まれるということだ。

画面上では「・・・・・・・」と表示されているが、これは見た目がそうなっているだけで、入力欄にはちゃんとパスワードの文字列が挿入されていて、ページ内のJavaScriptから参照すればパスワード文字列を読み出せる状況になっている。通常ならば、サイト運営者以外にはそのような読み出しはできないわけだが、公衆無線LANで接続している場合は違う。通信路上に介入した盗聴者によって、画面のHTMLを改竄されれば、パスワードを読み出すJavaScriptを埋め込まれてしまう。

というわけで、どうすればよいかというと、次のようになる。

• 自宅にいるときに信頼できる通信環境だからという理由で http:// の画面でパスワードを入力することはあるにしても、そのコンピュータを公衆無線LANなど信頼できない通信環境に繋ぐ可能性もある場合は、普段から、http:// の画面で入力したパスワードをパスワードマネージャには記憶させないよう注意する必要がある。
• https:// の画面で入力したパスワードについては、パスワードマネージャに記憶させてもよい。

http:// でログインしたときのパスワードマネージャの「このパスワードを記憶させますか？」の問いに対し、「このサイトでは記憶しない」を選択してしまえば、次回以降、この問いが出ることはなくなる。その場合でも、パスワードマネージャは http:// と https:// を別のサイトとして扱っているので、https:// の画面で入力したパスワードをパスワードマネージャに記憶させることはできる。

パスワードマネージャを使うことが許容される状況（そのコンピュータが自分専用）で、パスワードマネージャを使うつもりであるなら、いっそ、mixiのような構成のログイン画面では、自宅にいるときも含めて常に「SSL(https)はこちら」をクリックしてログインするようにするのがよいだろう。一度パスワードを記憶させれば2クリックでログインできる。

以上の話は、Firefox 3.0.5、Safari 3.2.1、Google Chrome 1.0での話である。

Internet Explorerの場合は、上記のような注意が必要でない。なぜなら、IEでは、パスワードマネージャにパスワードを記憶させても、ページを訪れただけでは自動入力されないからだ。ユーザ名を手作業で入力したときだけ、パスワードが自動入力されるようになっている。図4のように、ユーザ名入力欄でクリックすると、覚えているユーザ名をメニューから選べるようになっており、ユーザ名を選択すると対応するパスワードが自動入力される。

図4: IEのパスワードマネージャではユーザ名の入力を必要とする

したがってIEの場合では、http:// でパスワードをパスワードマネージャに記憶させても、公衆無線LANでつながっても、ユーザ名を入力しないようにしていれば、パスワードを盗まれることがない。https:// のページに移動してから入力すればよい。

こうした、ブラウザごとの挙動の違いは、最近Googleが公表した「Browser Security Handbook」という文書にもまとめられている。part 3の「Password managers」のところに表がある。「Password manager operation model」のところで、IEについては「needs user name」、Firefox等については「auto-fills on load」と書かれている。Operaは「needs UI action」となっていて、また別の方式のようだ。

ちなみに、Googleの「Android」については、「Are stored https passwords restricted to SSL only?」が赤字で「NO」と書かれている。これはどういう意味かというと、https:// の画面で記憶させたパスワードが、http:// のページにアクセスしたときにも自動入力されてしまうという意味だろう。

これは危ない。現状のAndroidでは（おそらく近々修正されるのだろうが）、パスワードマネージャは使用してはいけない（信頼できない通信環境も使う可能性がある場合には）。

■ 日本航空のEV SSL導入のナンセンス

先週、日本航空がEV SSLを導入したという話がニュースになっていた。

• JAL、国内航空業界で初めてフィッシング対策にEV SSL証明書を導入, RBB TODAY, 2008年12月15日

しかし、いったいどこのページに行けば、緑のアドレスバーで会社名を見ることができるのだろうか。

日本航空のログイン画面はトップページにあり、図5のように http:// のページになっている。

図5: 日本航空のログイン画面

これでは EV SSLが台無しだ。緑であることも会社名も確認できない。mixiのように https:// に切り替えるリンクも用意されていない。ここの利用者達はどういう想いでパスワードを打ち込んでいるのだろう？

このサイトには他にもログイン画面があって、航空券の予約で便を指定した直後で図6の画面が現れる。マイレージ会員はここでログインするようになっているのだが、ここの画面も http:// であり、EV SSLの緑と会社名も確認できない。

図6: 日本航空の別のログイン画面

ここで、自力でアドレスバーの http:// を https:// に書き換えてアクセスし、SSL接続を確認してからログインしようとしても、図7のようにエラーになってしまってできない。

図7: 自力で http:// を https:// に書き換えてアクセスしてみた様子

いったい何のために日本航空は EV SSLを導入したのだろうか？ わけもわからず買っただけなのではないか？ 同社の「SSLについて」のページにいろいろ書かれているが、何もわかっちゃいない。

これをニュースにしたRBB TODAYの記事もどうかと思う。

今回、JALマイレージバンク（JMB）会員のログイン時に「お得意様番号」および「パスワード」を入力するサイト、一般乗客が航空券の予約時に顧客情報（氏名・年齢・性別・連絡先、クレジットカード番号など）を入力するサイトに導入された。JALはこれまでも、ログイン時やチケット予約時に日本ベリサインのSSLサーバ証明書を利用していたが、今回のリニューアルに合わせ、より強固なEV SSL証明書を導入したもので、サイトのトップページにもEV SSL証明書が導入されたとのこと（httpsでアクセスした場合）。

JAL、国内航空業界で初めてフィッシング対策にEV SSL証明書を導入, RBB TODAY, 2008年12月15日

「（httpsでアクセスした場合）」と注釈を付けたくらいなのだから、この記者は、サイトの造りが駄目なのはわかっていたはずだ。わかっているならこんな記事を書いてはいけない。

関連：

• SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも, 2005年11月30日の日記