パスワードを殺す時が来た ― それが私たちを殺す前に

パスワードを入力する時間です。複数の画面がトリガーとなります。

このひらめきは、3 つのソフトウェアを使用して 2 つのデバイスで 1 つの Rhapsody 音楽サービスと格闘していたときに得られました。

RhapsodyのAndroidスマートフォンアプリを起動すると、予期せずパスワードの入力を求められてしまいました。ああ、アプリがアップデートされたので、改めてログインする必要があるんだ、と思いました。タップタップ。

拒否されました。うーん。ノートパソコンのRhapsodyウェブサイトで同じパスワードを入力しました。問題なし。SonosオーディオシステムコントローラーアプリケーションのRhapsody部分も問題なし。

Androidに戻って、またタイプ。「サインインに失敗しました。」Rhapsodyアプリをアンインストールして再インストール。「サインインに失敗しました。」Droid Incredible 2を再起動した。「サインインに失敗しました。」

これは「ラプソディ」ではありませんでした。

困惑した私は、Rhapsodyのテクニカルサポートにメールを送り、パスワードを「123456」に自動リセットしてもらいました。アプリとウェブサイトの両方に無事ログインし、以前のパスワードに戻したところ、とんでもないことに気付きました。パスワードに使っていた1文字の記号はウェブサイトでは使えたのですが、アップデートしたAndroidアプリでは使えなくなっていたのです。

Rhapsody サポートに報告したこの件に関する詳細なレポートは、一言で言えば「何だこれ？」です。

「この問題は認識しております。開発チームが対応に取り組んでいます。特殊文字をしばらく使用してからお試しください」と、ほぼ読み書き可能な返答が返ってきました。

私は長年、パスワードの適切な管理に努めてきました。ウェブサイトが登場した初期の頃は、分かりやすいパスワード（例えば「123456」）を避け、実在する単語ではないアルファベット文字列を使うことを意味していました。私は時間をかけて段階的に、以下の点に取り組んできました。

• 少なくとも 1 つの大文字を追加して、ブルート フォース攻撃を阻止するための複雑さを高めます。
• 各 Web アカウントに固有のパスワード要素 (他の人にはわかりにくいが、自分にとっては覚えやすいもの) を追加して、1 つのパスワードが公開されてもすべてのパスワードが公開されることを回避します。
• 各パスワードに少なくとも 1 つの数字または特殊文字を追加して (サイトでの要求が増えています)、さらに複雑にして Hulk-force 攻撃を阻止します。
• 2 要素認証を追加して (Facebook、Gmail、Twitter などのアプリ/サイト/サービスで利用可能な場合)、不明なデバイスがアカウントにサインインしようとしたときに、信頼できるデバイスで追加のパスコードを生成または受信することを要求します。

しかし、この進化はパスワードを無意味なものへと追いやってきました。複数の画面やデバイスから同じサービスにアクセスする時代に入り、複雑さの危機を生み出しています。その要因は、内部の一貫性と人間の記憶の両方にあります。

Rhapsodyは、最近になって苛立たしいほど一貫性がなくなった唯一のサービスでした。ヒルトンは、HHonorsロイヤルティプログラムのサイトではPINの先頭にゼロがあっても問題なく入力できるものの、同じアカウントで予約する一部のホテルブランドのウェブサイトでは入力できないことが分かりました。医療機関のウェブサイトと、それにリンクされたAndroidアプリでも、同様のパスワードルールの不一致が見られました。

また、関連性のないサイト間でルールが異なる場合があることについては、もはや触れる必要もありません。パスワードやユーザー名に特殊文字の使用を必須または禁止しているサイトもあれば、そうでないサイトもあります。そのため、包括的なニーモニックスキーマを作成することは事実上不可能です。XX日ごとにパスワードのリセットを強制する企業や政府のサイトも同様です。

パスワードに関する不満を、Forrester Researchのセキュリティとリスク担当主席アナリストであるEve Malerさん（別名@xmlgrrl）にTwitterのダイレクトメッセージで伝えました。するとすぐに返事が返ってきました。「本当に、これはギークとそれ以外の人々を結びつける唯一の問題です。飛行機の隣の席の人とこの件について何度話したか数え切れません！」

「私が目にするもう一つの苛立たしい状況は、同じ組織が運営する複数のアプリで、ユーザーに異なるログインアカウントを要求することです」とマラー氏は続けた。「政府機関はしばしばこの罪を犯しています。これらのサイロをすべて統合するには、バックエンドで膨大な作業が必要ですが、そうしないことで生じるコストは日々増大しています。」

また、パスワード「ロッカー」（ロッカーベンダーと一貫性のないパスワードルールを蔓延させるサイトとの共依存関係のように思える）や、パスワードを自動で、場合によっては安全性に欠ける形で保存するウェブブラウザは、真の解決策だとは考えていません。単一障害点とプライバシーの緩い伝統を組み合わせることに強いこだわりがない限り、Facebookの認証情報を使ってあらゆる場所でログインするのは絶対に避けるべきです。

1967年にダスティン・ホフマンにささやいた先見の明のある人物が言うように、未来は生体認証かもしれない。米国国立標準技術研究所（NIST）の最近の報告書は、「パスワードはあなたが知っていること、生体認証はあなたが何者であるか、そして暗号識別装置はあなたが持っているものである」と定義している。

例えば、Lenovo ThinkPad T430に内蔵されている指紋リーダー。最初は半信半疑でしたが、その精度、スピード、そしてシンプルさに感銘を受けました。特にフレンチローストのコーヒーを初めて飲む前は、その素早さ、速さ、そしてシンプルさに感銘を受けました。

他の生体認証やデバイスによるアプローチも試みられています。大規模公開オンライン講座（MOOC）プロバイダーのCourseraは、「Signature Profile」に、課題を提出する人が毎回同一人物であることを確認するために、タイピングパターン（およびウェブカメラ）を測定する生体認証を採用しました。AppleはiPhone 5SにTouch ID指紋認証を搭載しています。MacユーザーがiPhoneを2回ノックすることでBluetooth経由でコンピュータのロックを解除できる、興味深いデバイス認証方法「Knock」もあります。

これらすべてをさらに一歩進め、長年のセキュリティオタクであるスティーブ・ギブソン氏は10月にSQRL（Secure Quick Reliable Login、発音は「スクイレル」）を提案しました。これは大きな注目を集めており、一言でまとめるのは容易ではありませんが、QRコード、サイト固有の自動キー、そして覚えるパスワードが1つだけの、まさに聖なる結婚を想像してみてください。

しかし、たとえ生体認証やデバイス固有のソリューションが広く採用されたとしても、指や網膜が利用できなかったり包帯を巻かれていたりした場合には、何らかのバックアップパスワード認証情報が必要になる可能性が高いでしょう。

開発者や組織の皆様へお願いです。モバイルとウェブの両方で、すべてのアプリやサイトでパスワードルールが統一されていることを確認するまで、アップデートをリリースしないでください。また、セキュリティ強化とユーザーの安全確保のため、英数字と特殊文字の両方を常に認識できるようにしてください。

それまでの間、私は不本意ながら不適切なパスワード設定のベータテスターであり続け、数少ない生体認証ログインに満足し、ノートパソコンが90日ごとに指紋認証の変更を促さないことに感謝する。そうなったら面倒だ。