7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが、前置きが長くなっていつ完成するかも見えない。取り急ぎ以下のツイートでエッセンスを示しておいた*1が、すでにわかりかけている人達にしか刺さらなそうだ。
そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。）
— Hiromitsu Takagi (@HiromitsuTakagi) July 8, 2019
同様のことは4年前にNISCのコラムに書いたが、消えてしまっているので、ひとまず、その原稿を以下に再掲しておく。
皆さんはパスワードの定期的変更、してますか？ 私ですか？ 私はしていません。でも、先日、主要なサイトのパスワードを全部変更しました。
思い起こせば、私が初めて自分用のパスワードを決めたのは、大学の研究室でUNIXマシンを使わせてもらった1988年のことでした。それ以来同じパスワードを使い続けたのですが、2000年ごろ、セキュリティを意識するようになって、複雑なパスワードに変えました。銀行など重要なサイト用のパスワードと、一般のサイト用のパスワード、お試し用の漏れてもいいパスワードの3つを主に使い分けて（本当は他に重大なものが数個あるのですが）いましたが、ずっと変更しないで使ってきました。繰り返し手で打っているので体が覚えており、長年使い続けたパスワードは、自分の分身のようであり、愛着のあるものとなっていました。
そんな慣れ親しんだパスワードを捨てて変更したのは、このところもう使わなくなっていた、あるSNSサービス*2から、「お客様のアカウントに第三者が不正ログインした可能性がございます。」という知らせのメールが来たからでした。他のサイトでは異常が見当たらないので、「ほんまかいな？」と疑問に思いつつも、一挙にあちこちのパスワードを変更しました。
昨今、こうした通知をする事業者が増えていますが、これは、「リスト型攻撃」とか「パスワードリスト攻撃」などと呼ばれる手口が横行し、あちこちのサイトで大量の不正ログイン被害が出ているためです。どこかのサイトが不正侵入され、ID・パスワードを盗まれ、盗まれたものがリスト化されて不正に売買されており、それと同じID・パスワードを使っている別のサイトのアカウントが不正ログインされているのです。
残念ながら、サイト管理者側でこの攻撃を防ぐ完全な対策はありません。せいぜい、ログインエラーの発生回数が普段より多くなった時点で管理者が詳しく調査して対処するくらいしかなく、その間に生じる少数の不正ログインは防げません。本来ならば、パスワードを漏らした元のサイトの管理者が、事故の発生事実を公表し、漏れたパスワードの本人に通知するべきですが、私の場合、そうした通知は来ていませんので、漏らしたところ*3は公表を渋っているか、漏らしたことに気づいていないのでしょう。
私はこの機会に、各サイト毎に別々のランダムに生成した12文字のパスワードを設定してみました。利用者側でこのように対処すれば万全の対策となります。こういうパスワードはもう自分で覚えることは不可能ですが、最近のOSやWebブラウザには、パスワードを記憶して自動で入力してくれる「パスワード管理機能」が標準でついていますので、今回これを使う前提でそうしてみたのです。
実際に運用してみて困ったのは、スマホアプリで使うこともあるサービスの場合です。スマホアプリは、パスワードの自動入力に対応していないので、手で入力することになります。最初の1回は、パソコンのパスワード管理機能が覚えているものを画面に表示させて、ランダムな12文字を目で確認しながら打ちました。面倒な作業ですが、1回するだけならいいでしょう。ところが、あるスマホアプリは、パスワードを覚えてくれないものでした。宅配便の到着状況を確認するアプリ*4なのですが、外出中にいざ使おうとしたとき、パスワードの入力を求められ、パソコンのパスワード管理機能を見に行かないとわからず、その場で使えませんでした。
このアプリはなぜこのような設計なのでしょう？ セキュリティのため、パスワードをアプリに覚えさせておくのは危険だと考えたのでしょうか。
しかし、Twitterやfacebookといった著名アプリは、一度ログインすれば再びパスワードを入力する必要のない設計になっています。これはパスワードを覚えているのではなく、最初にログインしたときにサーバ側で発行されたアクセストークン（ランダムで長い文字列）をアプリが覚えているのです。サーバ側は、そのトークンを持っている端末を本人からのアクセスとみなしてログイン状態を保ちます。Webサイトでも、利用者がログアウトボタンを押さない限りログインしっぱなしになるサービスがありますが、それも同じ仕組みです。
スマホのアプリをログインしっぱなしにしておくことは危ないのでしょうか？ たしかに、スマホをどこかに置き忘れたりすると、勝手に操作される危険があります。でも、メールやメッセージも、ログインしっぱなしなアプリばかりであり、紛失時の安全性は、スマホの端末のパスワードや指紋認証、加えてリモートワイプ機能（遠隔データ消去機能）で保たれるのが前提となっているようです。
そうすると、ログインしっぱなしでよいならば、いっそのこと、サイトのパスワードなんか無くしてしまえばいいのではないでしょうか。
私のパスワードは今や、サイト毎に別々のランダムな12文字で、OSやブラウザが覚えていて自動入力です。それって、もはや、スマホアプリが自動送信している「アクセストークン」と変わらないではないですか。実際、サイト側のログイン認証のセキュリティ強度としては同等のものです。
パスワードをこのように設定している人はまだ少数派かもしれません。しかし、リスト型攻撃はいっこうに収まらず、完全な対策もないため、利用者への注意喚起として「パスワードを使いまわさないで！」と叫ばれるようになってきました。先ほどの宅配便のサイトも、「他のサイトで使用しているバスワードを設定しないでください」と利用者に求めていますが、どのサイトに行ってもそう言われるなら、もはや人力で対処するのは無理な注文です。OSやブラウザのパスワード管理機能に頼るしかありません。そして、そうするしかないのなら、パスワードはランダムなものでいいでしょう。
となると、利用者にパスワードを決めさせる必要もなく、サイト側で決めてしまえばいいはずです。サイトのアカウント作成のときに、新しい利用者にランダムな文字列（トークン）を渡し、それを設定するように渡します。初回利用時の設定はプログラムが自動的に処理するでしょう。利用者はパスワードを意識しないで使えます。パスワードなんていらなくなるのです*5。こうすれば、パスワードの使い回しを防ぐことができ、リスト型攻撃を無力化できます。
ただ、話はそう簡単ではありません。スマホの端末を買い換えたときに、トークンの引き継ぎをどうするかという問題が残ります。引き継ぎを自動でできないときのために、再設定のための仕組みがどうしても必要になってしまいます。パソコンのブラウザで使う場合には、cookieを削除するとログアウトしてしまいますから、やはり、再び設定するための仕組みが必要です。
その目的のために、これまで通りのパスワードを使ってしまうと、元の木阿弥です。なぜなら、利用者が設定するパスワードでは、使い回しされるのを防げないからです。ですので、アカウントの作成時に、ランダムな文字列のトークンを利用者に渡し、いざという再設定のときのために大切に保管しておくように促す方法が考えられます。パソコン内に保管せず、紙に印刷して金庫に保管するよう促すとよいでしょう。
では、そうしたサービス形態が将来、普通になってくると、この世から「パスワード」はなくなってしまうのでしょうか。サイト運営者から渡されるトークンは、「パスワード」と呼ぶには相応しくありません。そもそも「パスワード」とは、人が記憶して使うもののことを言うからです。今日、「他のサイトと同じにしないで」と言われて、しぶしぶランダムな文字列を自動入力させているのも、入力欄の名前こそ「パスワード」ですが、およそ「パスワード」とは呼べないものを入力しているわけです。
そういう将来でもなお使われるであろう「パスワード」は、端末の操作をロックするパスワードです。このようなパスワードは、サーバに送信しないものであり、端末上で本人認証の処理が行われます。こうしたパスワードは、一人に一つあれば足りるでしょう。複数の端末で使い回しても、今日のリスト型攻撃のような脅威はありません。こうした操作のロックは、指紋認証などの生体認証で置き換わるかもしれませんが、緊急時のために結局はパスワードも必要になるはずです。
つまり、将来、人が覚えて使うパスワードというものは、端末上の認証（ローカル認証）に限って使うものとなり、サイトのログイン認証（リモート認証）には使わないのが現実となるだろうということです。そして、そのときの「パスワード」は、原点に立ち返り、体が覚え、愛着のある、自分の分身のようなものにできるはずです。
ただ、そうした将来に急に切り替わることはできませんので、過渡期には、リモート認証に使うものも一部残ることになるでしょう。このとき心配になるのは、一般の利用者の方々が、「これはリモート認証なのか、ローカル認証なのか？」を区別できるだろうかという点です。この違いを人々が意識できるような工夫が必要だと思います。例えば、「パスワード」とか「トークン」といった言葉を再整理して、言葉で区別できるようにすることはできないでしょうか。
リモート認証用の「パスワード」をなくすまでにあと5年、10年かかる*6かもしれませんが、今のうちから考え方を整理しておく必要があるな、と感じています。