パスワードのマスキング雑感

ヤコブ・ニールセンさんの所論をかいつまんで述べると（というか、本人が Summary を書いているので、それを訳すだけなのだが）、以下の通りとなっている。

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

ユーザがパスワードを打ち込むときに、入力のフィードバックとして中黒（bullets）の列が表示されるだけだと、ユーザビリティが損なわれてしまう。概して、パスワードをマスキングしてもセキュリティを上げることすらできず、寧ろログインを失敗するという面倒をもたらすのだ。

Jakob Nielsen, “Stop Password Masking“

ご存知だと思うが、マスキングは input タグの type 属性を “password” にすれば、ブラウザがよしなに計らって、文字を入力する際に、入力している文字そのものではなく、代わりに「・」や「＊」を（もちろん半角で）表示してくれるという仕組みだ。

そして、W3C の説明にも明記してあるとおり、<input type=”password” … /> はデータをサーバに送信する方法や送信するデータとは全く関係がなく、「ブラウザ側の見せ方」の問題にすぎないので、マスキングをする効用は、まさしく入力している当の文字列が何であるかを、入力している本人の他からは分かりにくくするという点だけにある。もちろん、キーロガーを仕掛けられていたら意味がないので、高いレベルのセキュリティが求められる場面では、銀行のオンラインバンキングシステムなどにあるとおり、ワンタイムパスワード生成器を使ったり、ユーザごとに発行される符丁コード表を使ったり、あるいはソフトウェアキーボードを活用する。

パスワードは、認められたエンティティ（ここではユーザと同義で考える）だけが知りうる情報であり、他者が恣意的に閲覧できたり変更できたり削除できてはいけない（したがって、アカウントの削除はエンドユーザ自身で行える方がよく、事業者が倒産したか何かでサービスを止める場合でも、本来は登録ユーザ自身にアカウントを削除させるような機能を提供するべきではある）。事業主体やエンドユーザにとってパスワードという情報は、もちろん機密性の評価が高い。したがって、上記の論説に「ショルダーハックを防ぐにはマスキングすることが有効であり、このやり方がディフォールトであったのには十分な理由がある」（Chris Kite, “Terrible Password Security Advice From Jakob Nielsen“）と反論が出るのは当然だろう。

ただ、カイトさんの結論にある「in Jakob Nielsen’s private office, on the penthouse floor of his ivory tower, password masking is probably useless（ヤコブ・ニールセンがオフィスを構える象牙の塔の最上階フロアでは、パスワードをマスキングしていなくても、たぶん誰も後ろから覗き込んだりはしないのだろうが）」という言い方をしてしまうと、話がこじれるだけだ（実際、この部分だけを取り上げて Twitter やブログでコメントしている人がたくさんおり、全くの無駄でしかない）。上記二人の所論を見ていると、「入力ミスを恐れるユーザはコピペするから、余計にセキュリティが損なわれる」とか、「入力ミスがあるからといって、マスキングに文句を言う人なんていなかった」という、＜おらが町では式＞のアドホックな水掛け論や、顔を真っ赤にツバを飛ばし合う「現場主義」へ話が退行する可能性がある。以下で述べるとおり、現場主義はマネジメントにとって必要だが、他社を説得する理由にはならない。

企業の情報セキュリティマネジメント（ISMS）の担当者という視点から言うと、例えば「シュナイアー氏が言うようにショルダーハッキング (肩越しで入力を盗む) なんて一般的なことではない」という場合の「一般」が何を指していようと、自社の業務フローや社内の業務を観察して、実際にショルダーハッキングのリスクがあると認められる場合には、セキュリティの専門家が「一般的でない」と言おうが、ユーザビリティの権威が何を言っていようと、我々は情報セキュリティ事象として報告する責任がある。逆に、一人暮らしの人が家庭で自分のマシンを使っている場合には、セキュリティの別の専門家が「危険だ」と言おうが、特にマスキングの必要を感じないだろう。上記のような両極端の対策が、会社と自宅で同一人物によって運用されていても、何の矛盾もない。

セキュリティの担当者は、或る管理策やセキュリティコーディング等を、「一般的であるかどうか」という、言ってみれば自社のマネジメントという観点からは信頼しかねる基準で評価することは慎むべきとされている（もしそんな ISMS 担当者がいたら、その会社は「自社」の情報セキュリティに関心などなく、単に JIS の認証書を額縁に入れて玄関に飾りたいだけの話なのだろう）。自社の情報資産が現実に脅威に晒され、脆弱性があると認められる限りは、それについて対応できる管理策を自分たちで立てなければならない。われわれ認証を受けている企業の担当者は、自社の業務が「一般的」であるよう JIS Q 27001:2006 によって強制されているわけではない。およそ「マネジメント」と名の付く仕事は、統計に反映されたり常識に沿うために存在しているわけではないのだ。自社の現場に照らして管理策を立てるべきと言えるが、それを理由に他社の管理策を評価できるものではない。したがって現場主義は、他社のマネジメントを評価するために濫用するのでなければ、保持すべき一つの原則と言ってよいだろう。

以上の話は、実は「ショルダーハックなんて、そうそう起きることではない」という意見への反論として述べたつもりだ。

マスキングの評価そのものについては、一部に「必要悪」と評する向きもあるようだが、僕はぜんぜん悪とは思っていない。そして、不必要悪だと言う人々は、マスキングをするからこそ、ユーザは入力しやすいように弱いパスワードを設定してしまうのだと言っている。しかし、タイピングを減らしたり覚えやすくするために弱いパスワードを設定してしまうことが多いのではないか。マスキングしようとしまいと、多くのユーザの行動は変わらないと思う。

そして、マスキングすると、あたかも情報が暗号化されているかのように誤解させることになるという意見についても、僕としては ID/PW のペアでログインする限り、寧ろ ID の入力欄もマスキングしろと言いたいくらいである。なぜパスワードだけが重要なのか。ID も、場合によってはメールアドレスを使うサービスもあるので、単なるニックネームのようなものとは違う価値をもつ場合もある。パスワードをハッシュ化した場合のコリジョンという問題があるため、パスワードだけでログインするというわけにはいかない。しかしそうであれば ID も重要なデータには違いなく、なぜ ID はショルダーハックに脆弱でもよいのかという議論が可能だ。