created_at
updated_at
tags
toc

Passkey への道 #2: 2FA/TOTP

Intro

「パスワード」が認証の最重要要素で、いかにそれを死守するかを「サービス側」「ユーザ側」双方で考え続けてきたのが、平成の認証だった。

ところが、それは早々に破綻し、「パスワードだけでの認証」に限界が来た。

そこで、導入されたのが二要素認証(2FA: 2-Factor Auth)だ。

2FA が必要だった理由

認証には「記憶」「所有」「生体」の 3 種類があり、そのうち 2 つを組み合わせるのが 2FA だと言われるアレだ。

この文脈で言えば、「記憶」に頼るパスワードだけで認証するのはもう限界なので、別の要素に頼る必要がある。それがパスワードと同じ「記憶」に頼るものであれば、追加する意味がないということだ。

記憶要素追加の典型例は「秘密の質問」だ。「パスワード」の後に「飼っていたペットの名前は?」を入れさせたところで、有意な認証強度の向上には繋がらない。どちらも記憶に頼っているため、これは「二要素認証」ではなく「一要素二段階認証」などと揶揄される。

1st Factor がパスワードである以上、2nd Factor の選択肢は自ずと「所有」か「生体」のどちらかになる。

実はこの選択で「生体」を取るのは非常に難しい。

本当はここで「生体認証」の持つ問題や、Face ID/Touch ID などの解説をしたいところだが、長くなる上に後でまた出てくるため、そこでまとめて解説する。

とにかく、今 Web で行われる 2FA は、「所有」の要素を用いたものが主流だ。

銀行の乱数表

平成の中~後期頃、銀行は顧客に以下のような乱数表を配り始めた。

楽天銀行のセキュリティカード

パスワードを入れた後に、乱数表の「A-2, E-4, J-6, C-1」に書かれた文字を入力させる、といったものだ。

この場合、入力するのはパスワードと同じ「短い文字列」だが、この乱数表は覚えることを目的としておらず、「口座登録者の住所に書留で送った、つまり入力できる人は間違いなく、乱数表の持ち主だ」ということを担保している。

つまり「所有」の要素とみなすことができ、「記憶」に頼るパスワードと合わせた 2FA になるのだ。

仮に顧客が使い回しているパスワードが、平文保存しているどこかで漏洩し、それがダークネット経由で買われ、この銀行のパスワードと同じものが含まれていたとしても、このカードが無ければログインはできない。

この方式は、カードが二枚になるだけで扱いは比較的楽だった。しかし、限界も近かった。

この乱数表の写真を撮って送らせたり、全部を入力させるフィッシング詐欺サイトが登場し、結構な顧客が引っかかってしまったのだ。もちろん、再発行はできるが、それは被害に気づいている場合であって、被害にあったことにすら気づかなければ継続的に攻撃ができる。

もう少し、生成される値が予測しにくく、その場限りな乱数が提供できれば。

ということで、次に出てくるのが TOTP になる。

TOTP (Time-based One-Time Password)

銀行が乱数表の次に顧客に配ったのは、以下のようなデバイスだ。

きらぼし銀行のハードウェアトークン

ここに 30~60 秒ごとに変わる乱数が表示され、パスワードの次にそれを入力させるというものだ。

急に見慣れないものが送られてきて、困惑した顧客も多いだろう。これこそが、一定時間だけ有効な乱数を、その都度生成する TOTP (Time-based One-Time Password) のデバイスだ。

デバイスには鍵が入っており、それは取り出せない。無理に取り出そうとこじ開けたりすると、壊れて鍵が吹き飛ぶ作りになっている。代わりに、対になる鍵だけをサービス側に共有しておく。

このデバイスとサービスは、事前に交換した鍵のペアをうまく使うことで、全く同じ値を算出することができるのだ。それが固定値だと一回しか使えないため、変数としてタイムスタンプを入れることで、数秒間だけ有効な乱数をサーバ/クライアントで同時に生成できるという仕組みだ。

ユーザがこの値を入力して、サービス側で一致が確認できれば「このユーザが間違いなく、送ったデバイスを書留で受け取った人だ」ということを確認できる。つまり、色々やっているがこれも結局は「所有」による認証と言える。

これで、乱数表よりはまともな二要素認証ができたが、それでもこのような見慣れないデバイスの利用は、一般人とりわけ高齢者などにとっては負荷が高かっただろう。乱数表が並行運用される時間も長く、今でも運用しているサービスもあるだろう。

スマホ以降

携帯どころか、メールアドレスまで持っていないユーザをカバーするには、乱数表なりデバイスなりをサービスが用意して送りつける方法しかなかった。しかし、スマホが普及して以降は、2FA もスマホベースに移っていく。

昨今では、TOTP は SMS やメールに送られてくるものと思っている人も多いだろう。

SMS の場合は「登録した番号(SIM)を所有している」という要素になるが、国によってはキャリアの運用に穴が多く、SIM の乗っ取りなどの被害も横行して信頼性が揺らぎつつある。また、送信料をサービスが負担するため、一通数円の送料が積もればかなりのコストになる。

メールは、登録でも求めることが多く、多くのユーザをカバーする。しかし、パスワードのリカバリがメールで、TOTP もメールだと、そのメールサービスが盗まれた際に二要素の意味が無くなるという問題もある。また、銀行からの DM をブロックしたついでに、TOTP も迷惑フォルダに入ってしまうなど、ログイントラブルも尽きない。

そこで銀行は、前述した TOTP デバイス相当を、独自アプリとして提供し、顧客にインストールさせる方式を取り始めた。最近の金融詐欺対策で送られてくる「FIDO 対応アプリに移行してください」のアレだ。TOTP が表示されるものや、開いてタップするだけのものなど、実装は色々あるがやっていることは同じだ。

しかし、サービスごとにログイン用アプリが増えていくのは、ユーザにとってもサービスにとっても負荷だ。そこで、一般的なサービスでは、標準化されているこの仕組みを実装して QR コードを表示し、ユーザが好きな対応アプリで登録する方式が広まった。黎明期は Google Authenticator や Authy などがあり、しばらくするとパスワードマネージャも TOTP に対応するようになっていった。

Google Authenticator

「2FA にすれば安全になる」ということで、特に意識の高いサービスと、そのユーザらが積極的に導入し普及を進めた。エンジニアでは GitHub に登録するため、2010 年代中ごろ Google Authenticator を入れた人が多かったように思う。

Outro

こうして、「パスワード」に加えて「TOTP」を入力する 2FA が登場したことで、認証の強度は格段に上がった。

仮にパスワードだけが漏洩し、それを攻撃者が手にしても、それだけではログインできなくなったからだ。

何度言っても使い回しをやめないユーザや、平文保存して漏洩したことにすら気づいていない脆弱なサイトがあったとしても、自分で自分のサイトを守ることができる。

ここまでを踏まえて、「パスワードをちゃんと管理し、TOTP も登録しているから大丈夫」と思っている人も多いだろう。それもまだ、平成の感覚に過ぎない。