ひろみちゅ先生曰く「それはもはやパスワードではない」「いっそトークン方式に切り替えてはどうか」

Hiromitsu Takagi @HiromitsuTakagi

そもそも「パスワード」とは何か。パスワードとは人が覚えて使うものである。必然的に複数のログインサービスで同じものが使われ得るのが前提となる。故に、管理者さえ利用者パスワードを知り得ないよう技術的対策し、利用者には自由にパスワード設定できるようにするのが当然であった。それが今日、…

Hiromitsu Takagi @HiromitsuTakagi

…今日、幾つもの管理者からパスワード（又はその弱いハッシュ値）が流出する事故が相次ぎ、リスト攻撃が横行したことから、ログインサービス毎に異なるパスワードを付けよとする意見が強まった。管理者が利用者に対して「当サービス専用のパスワードを設定してください」と指示する例も出てきた。…

Hiromitsu Takagi @HiromitsuTakagi

…出てきた。しかしそれはもはや「パスワード」ではない。それを実践すればOSやブラウザのパスワード記憶機能を用いて自動管理するところに行き着く。パスワードは乱数生成され利用者は記憶しない。となればもはや、利用者に自由にパスワード設定できるようにする必要性がないのであり、管理者が、…

Hiromitsu Takagi @HiromitsuTakagi

…管理者がパスワードを乱数生成して利用者に与えればよいのである。それは定義からして「パスワード」ではないのであり、事前共有鍵のようなものだ。管理者から与えられた鍵をセットして使う例としてTLS-PSKなどがある。ここでは暗号鍵に使うわけではないので別の用語が必要だが、認証の強度…

Hiromitsu Takagi @HiromitsuTakagi

…強度は片側認証（サーバ証明書のみ）のHTTPS通信でパスワード送信（今日通常用いられている方法）で劣るものではなく、パスワード管理が他の鍵管理と同様であれば同じと言え、クライアント認証なんて実はいらないんじゃね？との議論もある。利用者には「ログイントークン」等の語で渡す。既に…

Hiromitsu Takagi @HiromitsuTakagi

…既にスマホアプリでは、そのような実装になっていて、利用者が意識ないままログイン認証が行われているものもある。この場合トークンは定期的変更する必要もない。証明書に短い有効期限があるのはRAとしての期限によるのであって、鍵が劣化するわけではない（アルゴリズム危殆化への対処は必要）…

Hiromitsu Takagi @HiromitsuTakagi

…ない。日本のガラケーではある意味過去それに近い世界が生まれていた。即ち、利用者がパスワードを持たないのが理想とされ、キャリアの回線認証の安全性を前提にキャリア発行の契約者ID・端末IDでサービス管理者は利用者を識別・認証していた。むろん全サービス共通のトークンだった点は誤りだ…

Hiromitsu Takagi @HiromitsuTakagi

…だが、サービス毎に独自のトークンを用いTLSで送信すれば安全である。興味深いのはスマホへの転換期に登場したLINEがたどった道だ。LINEは当初パスワードを持たなかった。利用開始時の初期登録でパスワード設定させず、独自のトークンで認証をしていた。それが後に、パスワード機能を…

Hiromitsu Takagi @HiromitsuTakagi

…機能を付加することになる。それは機種更新時の引き継ぎ、マルチデバイス対応のためだった。結局ガラケー界の「パスワードなしが理想」は過去の遺物であり、パスワードは必要なものだった。ところが、そのLINEもリスト攻撃に見舞われ、パスワードをLINE専用にせよと呼びかけることとなる。…

Hiromitsu Takagi @HiromitsuTakagi

…なる。もはやメモするしかない。ここで立ち戻ってみると、LINEのそれは「パスワード」である必要のないものだった。端末の変更や追加の場面で入力するだけの年1回あるか程度。ユーザ視点でそれはログインではなくアプリの初期設定作業にすぎない。ならば管理者発行のトークンで足りる。このよ…

Hiromitsu Takagi @HiromitsuTakagi

…このように、①稀にしか使わない②サービス毎に別々にするとの前提は、③覚えられなくて「パスワード」に不向きというだけでなく④初期設定で使うだけの「ログイントークン」で足りるということでもある。パスワードを他と同じにしないでと呼びかけるなら、いっそトークン方式に切り替えてはどうか。

Hiromitsu Takagi @HiromitsuTakagi

その場合も「パスワード」は端末の不正操作防止のため残る。端末がトークンで端末認証されているところに加えて、重要な操作でパスワードを求める。このときのパスワードはアプリでローカルに認証処理すればよく、サーバは預からないため、サービス間で同一でよい。記憶による認証の復権である。その…

Hiromitsu Takagi @HiromitsuTakagi

…そのような本来の「パスワード」と、メモや端末管理が前提の「ログイントークン」とは異なるものだ（前者は記憶が必要、後者は記憶が不要）という認識を利用者に持ってもらうために、これらは名称として呼び分けられるべきである。

Hiromitsu Takagi @HiromitsuTakagi

このところMacとiOSでiCloud同期する「キーチェーン」でランダムパスワードに置き換えてみているが、たまにうまく使えないサイトがあって、まだまだ一般の人たちに使えとするのは早いなと感じる。Dropboxですらうまくいかない。 pic.twitter.com/daSh2jOt3j

拡大

Hiromitsu Takagi @HiromitsuTakagi

ランダムに変更してハマったのが「ヤマト運輸」アプリ。Webでランダムパスワードに変更しキーチェーンに覚えさせ、アプリは最初に1回設定して…とやってみたら、アプリ終了でログアウトする仕様（覚えるのはIDだけ）で、出先で使用できず。 pic.twitter.com/NgClXhS8i5

拡大

Hiromitsu Takagi @HiromitsuTakagi

このようなWebとアプリの両方を提供するサービスでは、アプリの設定用トークンをWebのHTTPS画面上に発行し、最初に設定してくださいとすればよい。その上で、重要な操作が端末で即できてしまうのが危ないというのであれば、ローカル認証のパスワード機能を付ければよい。

Hiromitsu Takagi @HiromitsuTakagi

そのようにすれば、Web側はキーチェーンでランダムパスワードを使用し、アプリでは記憶できるパスワードを使用できる。一方、キーチェーンを使わない人は、両方とも記憶できるパスワードを使うことになろう（同じパスワードを使うかもしれない）が、そこは利用者の選択である。

Hiromitsu Takagi @HiromitsuTakagi

なお、Webのサービスでは、キオスク端末から臨時にログインできる利点が残る限りは、パスワードを廃止するわけにもいかない。しかしそこは利用者に選択させてもいいだろう。初回登録時から、パスワード方式かトークン方式かを選択させる。前者なら自分で設定させ、後者なら自動発行してメモさせる。