2FA
多くのオンラインサービスでは、ワンタイムコードを使用した二要素認証（2FA）を設定することができます（場合によっては、2FAは必須となります）。Google Authenticatorは、このようなコードを生成する認証システムアプリとして最もよく知られ、多くの人に使用されています。ほぼすべてのサービスがGoogle Authenticatorに対応しており、2FAを設定する際にこのアプリへのリンクが提示されることもあります。しかし、Google Authenticatorのほかにも多数の認証システムアプリがあります。例えば、Microsoft AuthenticatorやTwilio Authyなどです。
では、Google Authenticator以外のアプリは、それに代わる十分な機能を備えたものでしょうか。潜在的な危険はあるのでしょうか。この記事を最後まで読む時間がない方のために、ここで答えをお教えしましょう。ご心配なく。Google Authenticator以外のアプリも使用することができます。どのようなアプリが存在し、なぜ安全なのか、さらにそれらがどのように機能するのか、についてこれから詳しくご説明します。
認証システムが機能する仕組み
ではまず、一般的に認証システムアプリがどのように機能するのかを見ていきましょう。強固な認証を実現することを目的に、OATH（Initiative for Open Authentication）のもと、複数のオープンスタンダードプロトコルが作られました。認証システムアプリは、このような標準（とその他の事柄もありますが、この記事のトピックではないのでここでは省きます）に基づいて設計されています。
OATH HOTP
遡ること2005年に、OATH HOTP（Hash-based One-Time Password）が登場しました。これは、一回限りのパスワードを生成する方法を指定するオープン標準で、認証の基礎となりました。
これは、アプリとサービスの両方が同じ秘密鍵を使用するという考えをベースとしています。次に、この鍵とカウンター値に基づくユニークなコードを生成するために、暗号化アルゴリズムが適用されます。カウンターとは、原則的に新しいワンタイムコードが生成されるたびに増分される値を指します。コードを算出するために使用されるデータは、アプリとサービスの両サイドで同じなので、すべてが想定通りに機能すれば、両サイドで生成されるコードは同じです。そのため、次に必要なのは、両サイドで生成されたコードを比較する方法です。ユーザーが入力したコードがサーバーによって生成されたコードと一致すれば、認証は成功となります。
コードを生成するリクエストごとにカウンター値が変更されるため、コードはユニークで、かつ一回限りのものとなります。また、逆計算を行ってこのコードから秘密鍵を抽出することを妨げるアルゴリズムが使用されています。そのため、誰かがワンタイムコードを傍受できたとしても、秘密鍵を算出したり、認証システムをまねたり、新しいコードを生成させることは不可能です。
HOTPには、2つの大きな問題があります。一つ目は、カウンター値が簡単に同期しなくなるという点です。例えば、ユーザーが認証システムにコードを生成するように要求したのに、このコードを使用しなかった場合、クライアント側の認証システムではカウンター値が増分されるのに対し、サービス側ではカウンター値は変更されない、ということが起きます。その結果、生成されるコードが一致しなくなります。二つ目は、カウンター値が変更されるまでコードが有効の状態が続くという点です。そのため攻撃者が何らかの方法でコードを傍受し、ユーザーの操作を妨害することに成功した場合、そのコードを悪用するための時間を攻撃者に与えてしまう可能性があります。
OATH TOTP
2011年になると、新しい標準が登場しました。OATH TOTP（Time-based One-Time Password）と呼ばれるもので、使用時の時間をカウンターとして使用します。原則は同じです。両サイドが把握している秘密鍵を使用して、同じ暗号化アルゴリズムを使用したワンタイムパスワードを算出します。カウンターがUNIX時間に基づいているため、コードはそれが使用されたかどうかは関係なく、自動的に一定の間隔を置いて変更されるようになっています。
インターネットに接続するデバイスであれば正確な時間を把握しているので、ワンタイムコードが同期しなくなることを心配する必要はありません。また、コードを変更する間隔が短いため（デフォルト設定は30秒）、万が一ワンタイムコードが傍受されたとしても、攻撃者にはこれを悪用するための十分な時間がありません。
認証システムの基本原則
これら2つの標準が、認証システムアプリでは使用されています。もちろん、TOTPの方が単純にあらゆる面において優れているためより一般的に使われていますが、HOTPもいまだに使い続けられています。
認証システムを設計する際、クライアントとサーバーは必ず共通の標準に基づいて設計され、鍵を共有する仕組みが必要です。これは、認証システムアプリが機能するために、最低限必要な条件です。追加のパラメータを設定して、トークンを作成することも可能です。では、アプリとサービスはどのようにコードが一致していることを認識するのでしょうか。多くの場合、QRコードが使用されます。さて、これらのコードはどのように機能するのでしょうか。
認証システムのQRコードの中身
私が知る限りでは、これはOATHのもとで開発された標準ではなく、Google Authenticatorによって設定されたフォーマットに従うために有志により作成されたものです。どのような由来であれ、アプリベースの認証システムでは、必要なすべての情報がエンコードされた状態で保持されているリンク（厳密には、ユニフォームリソースアイデンティファイア、URI）であるQRコードが使用される傾向があります。どういったものか、ここにその一例を示します。
otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30
ご覧の通り、次の内容を示すすべてのパラメータがQRコードで伝達されています。
- URIの目的 — 認証トークンの作成（行頭の「otpauth」が示す内容です）
- 認証システムの標準 － HOTPまたはTOTP。この場合は、TOTP
- アプリ（この例ではGoogle）内で表示されるトークンラベル
- ユーザー名 — この場合は、alanna@gmail.com
- コードが生成された秘密鍵（Base32） — 最も重要である、ランダムな文字で構成された長い文字列
- URIを作成したサービス名 — この例では、Google
- コードの生成に使用されたアルゴリズム — この場合、SHA1
- 生成されたコードの長さ — ここで示されているような6桁がよく使用されますが、他の桁数も使用可
- コードの有効期限が切れる期間 — 30秒が一般的ですが、別の間隔も設定可能
この内容を示すQRコードは、次のようなものです。
QRコードは、 認証トークンの多数のパラメータを示しています
実際に、上述のとおり、これらのパラメータの多くは省略可能です。トークンラベルやユーザー名は任意です。サービス名に至っては全く必要ではありません。この情報はコード生成には何の影響も及ぼさず、主に便宜上示されています。その他のパラメータの一部も、必須ではありません。認証システムではデフォルトのコード生成標準（SHA1）が使用され、その他の設定がURIでエンコードされていなければ、30秒間有効の6桁のコードが生成されます。
実質的に、サービスや認証システムでは、標準（HOTPまたはTOTP）を設定し、秘密鍵を共有することだけが必要となります。そのため、次のようなURIとQRコードは、上述のURIおよびQRコードと機能的には全く同じ認証トークンを生成します。
otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7
ORコードのパラメータの多くは省略可、又は任意の値に設定することができます。重要なのは秘密鍵を設定してHOTPかTOTPと、標準を設定することです
つまりポイントは、認証のためにアプリが生成するコードを使用するサービスの大半が、このようなQRコードを使って機能する、ということです。認証システムアプリは、このようなQRコードを読み取り、認証コードに変換し、その結果ワンタイムコードを生成することができるようになっています。そのため、Google Authenticatorでなくても、あなたの好きな代替アプリを選んで使用することができます。
例外：一般的な認証システムに対応しないサービスがあります
IT業界のすべての人間が上述のような標準に従っているわけではなく、独自の標準を採用することを選択している人もいます。以下の企業とそのサービスやプログラムは、（Google Authenticatorを含む）第三者機関が作成した認証システムアプリとの互換性がありません。
- Apple。クパチーノの人たちは独自の2FAシステムを構築しており、サードパーティー製のアプリは使用しません。代わりに、Apple IDに紐づけられているすべてのデバイスで、オペレーティングシステムによって同時にワンタイムコードが生成されます。これこそが、Appleが順調に勝ち進んでいる方法です。
- ValveおよびBlizzard。Steamやnetでのセキュリティを確保するために、開発者が独自の2FAを採用しています。それぞれ、Steam Guard（AndroidおよびiOS向けのSteamアプリに実装）とBattle.net Authenticatorです。私が知る限り、これらのシステムに対応するサードパーティー製のアプリは1つだけで、それはWinAuthです。
- Microsoft。マイクロソフトのアカウント認証には、Microsoft Authenticatorをインストールする必要があります。良い点としては、ユーザーはコードを入力する必要がないところです。アプリでボタンをタップするだけでログインすることを確認できます。さらにプラスとして、Microsoft Authenticatorでは一般的な認証トークンを生成します。そのため、Google Authenticatorの代替アプリとして使用できます。ちなみに、Microsoft Authenticatorを使用するためにマイクロソフトのアカウントは不要です。
- Adobe。グラフィックソフトウェアの開発者は、2FA用の自社アプリ、Adobe Account Accessを開発しています。これはMicrosoft Authenticatorのロジックに似ており、コードを送信するのではなく、ボタンをタップすることで、Adobeアカウントへのログインが認証されます。理論的には、このアプリはサードパーティー製のサービスで認証に使用されるトークの生成をサポートしていますが、Adobe Account Accessが機能するには、まずこのアプリを自身のAdobeアカウントとリンクする必要があり、App StoreおよびGoogle Playのレビューでは、これはおすすめされていません。
結局のところ、Google Authenticatorを使う必要があるのか？
必要ではありません。Google Authenticatorと機能するすべてのサービスでは、任意の代替アプリを使用して二要素認証を設定できます。さらに、代替アプリの多くは、Googleのアプリよりも大幅に優れた利点を備えています。
ちなみに、人気のオペレーティングシステム（Android、iOS、Windows、およびmacOS）ごとに、最も興味深い認証システムを紹介した記事が投稿されています。そして最後に、この記事を読んでくださった読者の方であれば、andOTP（Androidをご利用の場合）や、OTP auth（iOSをご利用の場合）にもご興味があるかもしれません。
ヒント