はったりエンジニアの備忘録

アタマに浮かんだはてなを忘れないために。

2 段階認証は本当に安全なのか調べてみた

Posted on

このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。

有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。

というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。

ワンタイムパスワードの仕様

ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。

前者はワンタイムパスワードの生成回数をベースにしているのに対し、後者はワンタイムパスワードを生成するときの時刻をベースにしています。以下のページで詳しく解説されています。

Google や AWS が採用しているのは時刻ベースの TOTP です。今回はこの TOTP について調べました。

自分はハードウェアトークンを持っていないので、Google Authenticator や Authy のスマホアプリを使った方法を前提にしています。

TOTP の仕組み

TOTP は時刻をベースにしていると書きましたが、具体的には次のようなことをやっています。普段、ログイン時に 6 桁の数字を入力しているのは 2 番になります。

  1. 安全な方法でサーバ側とクライアント側で同じ秘密鍵を共有しておく
  2. 共有した秘密鍵と UNIX Time を用いて同じ計算方法でワンタイムパスワードを求める

UNIX Time がシードになっているので、端末の時刻がずれていると認証は通りません。試しに iPhone や Android の時刻設定を数分ずらして 2 段階認証を試してみてください。何度やってもエラーになるはずです。

ワンタイムパスワードの求め方は先ほどのページの続きに載っています。

1 番の秘密鍵の共有は 2 段階認証を設定するときに行っています。有効にするとき画面に表示された QR コードをスマホで読み取りますが、この QR コードにはアカウント名や秘密鍵、ワンタイムパスワードの生成方法 (HOTP or TOTP) が含まれています。 QR コードを読み取ることでサーバ側で生成された秘密鍵がクライアント側へ共有されます。

AWS の場合を見てみましょう。生成された QR コードを手元でデコードしてみると otpauth:// の URI スキーマ形式になっていることがわかります。

otpauth://totp/user@000000000000?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

otpauth://(パスワードの生成方式)/(ユーザー名)@(AWS のアカウント ID)?secret=(64 バイトの秘密鍵)

この URI スキーマをメールや SMS で共有すると盗聴のリスクがあるので、スマホで QR コードを読み取るという方法を採用しているんだと思います（画面の前にいるユーザーにしかできないから、ユーザーが注意すれば盗聴のリスクはない）。

破る隙はあるか？

ここまでの説明を踏まえて、2 段階認証を破る方法を考えてみたいと思います。

狙える隙があるとすれば秘密鍵を共有するときです。 TOTP は UNIX Time をシードにしているので、秘密鍵さえわかってしまえば第三者が自由にワンタイムパスワードを生成できます。

サーバ側とクライアント側に分けて秘密鍵が漏れるシチュエーションを考えてみました。まずはサーバ側から。

自分が思いついたのはこの 2 つですが、どちらも考えにくいですね。次にクライアント側を考えてみます。

クライアント側はユーザーが気をつけることで防げそうです。

秘密鍵を総当りで試すことも考えましたが、仮に秘密鍵が英数字の 62 文字から成り立っているとしても 62 ^ 64 パターンあるので現実的ではありません（実際には 30 秒おきに UNIX Time のシードが変わるので計算量はさらに増えます）。

これらのことから 2 段階認証を破ることは技術的にハードルが高く、総当りするにしても労力に見合わないのではないでしょうか。

まとめ

2 段階認証は安全と盲目的に思っていましたが、仕組みをちゃんと知るのは大切ですね。