2要素認証と認証アプリの選択について

PR

最新情報

2023/10/11追記
2023/10/10からGoogleのデフォルトの認証方法はパスキーになりました。

2023/07/09追記
安全性、使用時の手間等を考えると、現時点で有望な認証方法の総合的な順位(筆者所感)は、以下のようになると思われます。現時点で最も良さ気なのは「パスキー」です。

順位	認証方法	弱点
1	パスキー(FIDO2)	・故障・紛失対策にパスキーだけなら複数機設定必要 ・故障・紛失対策にパスキー以外の認証方法も追加すると 　追加する認証方法の弱点が加わる
2	認証アプリ	・アプリで数値を見て入力するのが面倒
3	SMS認証	・SIMスワップに脆弱 ・届いた数値を見て入力するのが面倒

パスキーで使用される指紋や網膜は、フェイクのもので読取システムに適用可能なようにコピーされたときに、本人には変えられない所が弱いですが、そこは、生体の指紋や網膜であることを検知する仕組みを向上させることで対応でしょうか。指紋を例にすれば、指紋の型を取り、樹脂等で再現して、指紋センサーにあてた時に、生体の指紋ではないということを検知してはじく仕組みです。

2023/05/23追記
2023/04/24に米Googleから、「Google 認証システム」に登録した各サービスアカウントのOTPを生成するための情報(秘密鍵等)をGoogleアカウントにバックアップできるようにすると発表がありました。アプリをアップデートすると、OTPを生成するための秘密鍵等の情報は、Googleアカウントに紐つけて保存されそこから復元できるようになりました。下記に記載のエクスポート・インポートの機能も残っています。

ユーザーは、Googleアカウントを用いて各サービスアカウントのOTPを生成するための情報をバックアップ・復元することもできますし、Googleアカウントを用いずにこれまで通りエクスポートしたいサービスアカウントを選択してQRコードを用いてエクスポート・インポートすることもできます(一方だけの使用も両方同時使用もできます)。

Googleアカウントを用いてバックアップ・復元ができると利便性は上がりますが、Googleアカウントが万一無効化された場合には復元ができなくなるので、そのことに備えて、Googleアカウントへのバックアップだけではなく物理的な端末にもバックアップを持っておくと安心だと思います。

また、Googleアカウントを用いてバックアップ・復元をする場合には、それらの情報がエンドツーエンド（E2E）暗号化されていないという情報があり、Googleは将来のバージョンに追加すると述べているとのことです。現バージョンでは、暗号化されていない状態の各サービスアカウントの秘密鍵を含んだ情報が見える形で通信されていますので、通信経路上で傍受される可能性があります。

「Google 認証システム」にE2E暗号化が追加されるまではGoogleアカウントを用いたバックアップ・復元機能の使用は控えるのが良さそうです。

以下の記事は「Google 認証システム」についてはGoogleアカウントを用いたバックアップ・復元機能を使用しないこれまでの使用方法についての説明になります。

また、この変更後のAndroid版のGoogle認証アプリの名称は「認証システム」から「Authenticator」に変更されました。これによって、Googleの「認証システム」もMicrosoftの「Authenticator」もインストールされた状態のアプリの名称は「Authenticator」となり、両方をインストールしている場合はアプリの区別はアイコンでする必要があります。

本説明では名称で違いがわかるように、Googleの「認証システム」は「Google 認証システム」と記載し、Microsoftの「Authenticator」は「Microsoft Authenticator」と記載しています。

まとめ

以下は2023/04/23の情報です。2要素認証と、代表的な認証アプリの「Google 認証システム」と「Microsoft Authenticator」の選択について説明します。

2要素認証はサービスへのログイン時に、2つの要素の認証を併用することで本人以外がログインする可能性を小さくする仕組みです。認証要素としては以下の3つがあります。

認証要素	例
本人だけが知っているもの Something you know	パスワード、PINコード、 秘密の質問への回答 等
本人だけが持っているもの Something you have	セキュリティキー、 OTPジェネレーター、 スマホ「認証アプリ」、 Bluetooth機器、等
本人だけが備えているもの Something you are	指紋、網膜パターン、 声紋、顔の3D形状 等

自分の知っているシステムでは、1要素目の認証は「本人だけが知っているもの」、２要素目の認証は「本人だけが持っているもの」が多く、２要素目の認証は以下で説明するスマホ「認証アプリ」に表示される数値を入力するもの、スマホでSMSで受信した数値を入力するもの、スマホに表示される本人確認ダイアローグに返答するもの、ペアリングしたBluetooth機器との接続を確認するもの…等があります。

スマホ「認証アプリ」で表示される数値は、標準的なものはRFC 6238の方法で計算される数値です。この数値は、RFC 4226で、引数であるカウンター値に時刻を設定して求めた値で、コアの計算はRFC 2104で規定されるHMAC(Hashed Message Authentication Code)-SHA-1アルゴリズムを用いて計算されます。(SHA-1の代わりに、SHA-256, SHA-512も選択可能となっていますがデフォルトはSHA-1です。)

このスマホ「認証アプリ」に表示される数値を求めるアルゴリズムはOATH (Open AuTHentication) TOTP (Time-based One-Time Password) と呼ばれており、TOTPだけで呼ばれることも多いようです。

各サービスで、認証システムの要件として、「OATH TOTP互換 or RFC 6238準拠の認証アプリを使用ください」と書いてあるとわかりやすいと思いますが、そのようには記載されていないことが多いです。サービスの認証システムの説明では、アルゴリズム名ではなく「Google 認証システム」等、認証システムとして使用可能なアプリ名が示されることが多いです。

「Google 認証システム」と「Microsoft Authenticator」で表示される数値は、OATH TOTPを用いて SHA-1で30秒毎の更新で6桁出力を指定したときの値と一致していました。ですので、これらのアプリが使用可能なアプリとして記載されていれば、OATH TOTP互換(RFC 6238準拠)の認証アプリが使用可能です。Google Play Store等でTOTPで検索して出てくるアプリが使用できると思われます。それらのアプリの安全性は別途確認が必要です。注意が必要なのは、RFC 6238以外の独自アルゴリズムを用いているサービスもあることです。

認証アプリで表示されるサービスアカウント毎の6桁の数値は、秘密鍵がわかれば、上記のRFCに記載の方法で求められます。この6桁の数値はunixのoathtool等のコマンドを用いて算出することも可能です。秘密鍵はサービスアカウント登録時のQRコードに平文で記載されています。この話は別にまとめまる予定です。この文字列(URI)のフォーマットはRFCにはなっていないようです。

認証アプリはサービスアカウント毎に30秒で値が変わる「ワンタイム パスワード(OTP)」を生成し表示します。30秒で値は変わりますが、RFC 6238では、受信側でのOTPの検証は送信側との時刻ずれ、通信遅延等も考慮して、送信側で表示されている30秒間だけではなく、設定した時間幅のOTPも許容するよう記載されています。具体的に、OTPの値を変化させる時間刻みを30秒刻みとした場合に、前後何個分のOTPまで許容すべきかは記載されておらず、この時間幅はサービス提供者毎に定められるようです。

試しに受信側でどの程度前の時間のOTPまで許容しているのかをtwitter (X)で確認してみた所、送信側OTPの数値が切り替わって57秒遅れでログインを試みたときにはログインできましたが、59秒遅れではログインできませんでした。twitterでは30秒刻みで2つ前のOTPまで許容していると考えられます。逆に未来のOTP(送信側での時計の進みに相当)に関しての許容はほぼありませんでした。

以上のことからtwitterでの許容時間幅はOTPの値が最初に更新されてから90秒ですので、この場合は最長でも90秒たてばOTPの値は無効になることになります。また上のことから、認証アプリでOTPの数値が更新されそうなときや更新された後でも、OTPの値が更新されてから1分程度は有効なので、値を正しく入力すればログイン可能です。OTPの値が更新された瞬間に、受信側でそのOTPが無効になるわけではありません。OTP更新までの残り時間が短いからといってOTPの値が更新されるまで待つ必要はありません (ただし、サービスによってはこの仕様を実装しておらず、すぐに無効になるものもありました)。

以上はtwitterで確認した結果であり、遅れとして30秒×何個分まで許容されるかはサービス毎に決められていると思いますが、遅れを許容すべきと記載されているので、RFC 6238準拠であれば少なくとも1つ分(30秒)は許容していると思います。

OTPの数値の桁数はほとんどの場合6桁です。6桁までなら1回見るだけで記憶して入力できそうなので6桁ということもあるのかもしれません。

ちなみに、RFC 4226の5.3でOTP≡Dの値は以下のように求められるので、この部分で意味のある計算可能なOTPの値としては1～10桁があり得ますが、oathtoolで設定可能な桁(Digit)は6, 7, 8のみでした。あまり短いと総当たり式のクラッキングに弱くなり、長いと覚えるのが大変になり、手入力がわずらわしいので、6, 7, 8桁あたりの実用的な桁としたのではないかと思います。

RFC4226 5.3
Step 1, Step 2割愛
Step 3
Snum = 0...2^31-1≡0...2147483647(10桁)の値を求める
D = Snum mod 10^Digit、すなわち、下Digit桁をとる

AndroidアプリのAegis Authenticatorでは10桁まで設定可能でした。

以下の説明で明確にした方が良いので、この記事で使用する用語を以下に定めます。一般的にこれらの用語が常にこのような意味であるというわけではありません。

用語	定義
サービス	Twitter, Instagram, PayPal等
サービス アカウント	認証アプリに登録してOTP値を入力して ログインするアカウント ・Twitter, Instagram, PayPal等のアカウント ・Twitter等に複数アカウントがある場合は、 　それぞれ別のサービスアカウント

以上前振りが長くなりましたが、ここからが、まとめの本題です。

認証アプリ選択のまとめ

• 認証機能だけを使いたいなら知名度の高い会社のアプリでは「Google 認証システム」アプリがおすすめ
  • 登録したサービスアカウントを個別にエクスポートできる
    • エクスポートのQRコードから秘密鍵を取り出せる(別記事とします)
  • インポートできるので複数スマホに同じ複数サービスアカウントを設定できる
  • 容易にエクスポートでき、アプリ起動時の認証はないので、OSの機能等で「アプリロック」/「アプリのロック」をしておく方が安心
  • Androidの「Google 認証システム」アプリに登録したサービスアカウントの削除は、削除したいサービスアカウントを長押しして表示されるごみ箱マークをクリック
  • iOSでは「Google Authenticator」という名前
    • 「Google Authenticator」でのインポートはメイン画面の+ボタンから行う
    • 「Appを取り除く」「Appを削除」では登録したサービスアカウントは削除されず、再インストールでそのまま現れる
    • サービスアカウントの削除は「…」>「編集」>「鉛筆マーク」>右上の「ごみ箱」
  • Googleの複数のアカウントの登録も可能、Googleアカウントの登録は本ソフトでなくともRFC 6238準拠の認証アプリで可
• 「Microsoft Authenticator」は複数の機能を提供する
  • 登録した情報のバックアップをするならMicrosoftアカウントと紐付ける必要がある
  • 複数スマホで同じ複数サービスアカウントを使用するためには、クラウドにバックアップしたデータを別スマホで復元する必要がある
    • Microsoftアカウントにログインできなくなった場合には復元できなくなる
    • サービスアカウントだけではなく、クレジットカード情報、アドレス情報、
      検証済み IDの管理もできるが、多くの情報の管理ができる分ソフトが大きく、バックアップができなくなったときの影響が大きい
  • バックアップはandroidとiOSで異なる場所にされるので、この2つのOS間では異なるOSで保存したバックアップからの復元ができず、複数スマホに同じ複数サービスアカウントを一発で設定する方法は見つからなかった
  • Microsoftの複数アカウントの登録も可能、Microsoftアカウントの登録は本ソフトのみ可能のようである
  • パスワードレス認証は便利なので、この機能のために本ソフトを使うのはおすすめ

機能	「Google 認証システム」	「Microsoft Authenticator」
アカウント との紐付け	不要	クラウドバックアップ時は Microsoftアカウント必要
OTPの生成	○	○
パスワード レス認証	×	○ (MSアカウントの)
パスワード 管理	×	○
複数スマホ での使用*	○	△ (同じOS同士のみ)
サービス アカウント のコピー	○ 個別にできる	△ 全ての復元のみ
ソフトの軽さ	○ 認証機能 だけで軽い	△ クレジットカード情報、 アドレス情報、検証済み ID** 等も保存でき、大きく重い
バックアップ	QRコードを 表示させて コピー可能	・アカウントにバックアップ可能 ただし「問題が発生しました」が 表示されるとバックアップできなくなる ・確実な解決法は見つけられていない ・経験的に解決できた方法はあるが 経験的なものなので確実とはいえない
備考	OSによらず QRコードで サービス アカウントの コピー可能	Android, iOSでバックアップ したサービスアカウントは それぞれの機種だけで復元可能

複数スマホでの使用* の意味: 認証アプリに複数のサービスアカウントを登録し、認証アプリの操作だけで、別のスマホを同じ複数のサービスアカウントが登録された状態にできるかどうか。2台目が可能なら3台目以降も可能。

検証済み ID**: Microsoft Entra Verified IDという仕組みの証明書。アメリカでは大学の卒業証明書等で使われている所もあるようだが、日本では現時点では一般には普及していないよう。

以上は個人の意見で、以下に説明を記載していますが、セキュリティに関わるソフトでもあり、選択は安全性等を勘案して総合的に各々で判断する必要があります。

はじめに

最近はパスワードと併用で2要素認証を使うシステムが増えてきています。Twitter社がフリーアカウントに対してSMSによる2要素認証を強制的に無効にしたこともあり、2要素認証で認証アプリを使う場面は増えてきているのではないでしょうか。実際の所、SMS認証はSIMスワップに脆弱なので、認証アプリの方が安全性が高いといわれており、認証アプリに変更するちょうど良い機会と考えるのも良いと思います。

認証アプリはサービスアカウント毎に数値を生成しますが、Googleの「認証システム (Android), Authenticator (iOS)」(「Google 認証システム」と記載)でも、Microsoftの「Authenticator」(「Microsoft Authenticator」と記載) のどちらを使用しても、30秒毎に表示されるOTPの数値は同じです。RFC 6238準拠で30秒毎に値が更新されるアプリなら同じ値になります。このアルゴリズムはTOTPとも呼ばれています。RFC 6238では数値の更新を30秒毎にすることを推奨しています。何秒ごとに数値が更新されるかも数値生成のパラメータなので、30秒毎の更新でないものはRFC 6238準拠でも値が変わってきます。

表示される数値生成のアルゴリズムが同じならば、どこの会社のソフトでもいいはずですが、セキュリティに関係するソフトなので信頼できるものを使用する必要があります。日本であまり聞きなじみのない会社のものを使うのは安全性確認のハードルが高く、まずは、「Google 認証システム」か、「Microsoft Authenticator」あたりになるのではないでしょうか。

「Google 認証システム」か「Microsoft Authenticator」か

「Google 認証システム」

Googleの認証アプリはOTPの生成だけを行うアプリです。しばらく前に使用したときは別のスマホに登録したサービスアカウントをエクスポートすると元のスマホでは使えなくなっていたと思うのですが、今確認すると、複数のスマホにエクスポートして、複数のスマホで同じ複数のサービスアカウントを登録した状態にできるようになっていました。エクスポートすると元のスマホで使えない仕様ですと、バックアップができず実用上困るので仕様が変わったのではないでしょうか。複数スマホにバックアップできるとセキュリティは下がるので、そこはトレードオフとなります。

「Google 認証システム」は使用時にGoogleアカウントでログインする必要はなく、QRコードでサービスアカウントを登録・インポートするだけで使用できます。

OSに関係なく、エクスポートしたいサービスアカウントを選んでエクスポートできます。

アカウントにログインしないで使用するので、新しいサービスアカウントをあるスマホで登録しても自動的に他のスマホの「Google 認証システム」に反映されることはありません。別のスマホにもそのサービスアカウントを登録する場合は、手動でそのサービスアカウントをエクスポート → インポートする必要があります。

Googleアカウントが万一無効化されたとしても、登録されたサービスアカウントのエクスポート → インポート (コピー) は行えます。

一方「Microsoft Authenticator」は、Microsoftアカウントにサインインできないと、登録された情報をクラウドにバックアップできないので、登録されたサービスアカウントを他のスマホにコピーすることができません。

認証機能だけを使いたいのであれば、「Google 認証システム」が良いと思います。

ちなみに、Googleアカウントの認証は標準的なTOTPで、本ソフトにGoogleアカウントを複数登録することもできます。

ちなみにx2、QRコードでサービスアカウントを登録しますが、その文字列(URI)の仕様は、google-authenticatorの仕様としてKey Uri Formatに記載されています。ここに、以下のものが選択可能と記載してありますが、Key Uri Formatにも記載してあるように、デフォルト値以外を指定してもデフォルト値で登録されます。

• アルゴリズム: SHA1 (デフォルト)、SHA256、SHA512
• 桁数: 6 (デフォルト)、8
• ピリオド: 30 (デフォルト)、デフォルト以外の数値

ちなみにx3、AndroidアプリのAegis Authenticatorではこれらの全てのパラメータの指定に対応していました。

エクスポート内容

「Google 認証システム」のエクスポート機能で表示させたQRコードはKey Uri Formatで定められたotpauth:で始まる標準的なスキーム(URIの先頭のxxx:)ではなく、以下のようなスキームなので、通常のTOTPソフトではインポートできません。ただし通常のTOTPのURIに変換することはできるので、変換後にはインポートできます。(別記事とする予定です)

otpauth-migration://offline?data=xxx...

パスワードに相当する秘密鍵が取り出せるのはセキュリティ上どうなのかなぁと思いますが、簡単にはできないようにotpauth-migration:のような独自スキームで秘密鍵が簡単にはわからないようにしたのかもしれません。複数のサービスアカウントが1回のQRコードの表示でエクスポートできるという利便性のためもあると思います。

Unixのパスワードはパスワードに対して不可逆的な演算後のデータを格納してあります。スーパーユーザーでもユーザーが忘れたパスワードはわからず、忘れた場合は再設定するようになっています。パスワードを平文で保存することはありません。ユーザーが入力したパスワードに同じ不可逆的な演算を行い、演算後の値が一致することで、パスワードが合っているかどうかを確認できるようにし、パスワード自体は保存されたデータからはわからないようになっています。

これと同じようにできないかと考えましたが、Unixのパスワードの各ユーザーにおけるバックアップは各ユーザーがそれぞれの方法で、パスワード認証の外で平文で保存しているものであり、同様に、OTP生成の秘密鍵も、バックアップ作成時は、平文のまま受け渡すか、可逆的な変換を施したデータで受け渡す方法となるのではないかと思いました。

登録したサービスアカウントの別スマホへのコピー方法

androidのGoogleの「認証システム」アプリの場合は、以下の方法でもインポート可能です。iOSのAuthenticatorにはこのメニューはないので、上の方法でインポートします。

「Microsoft Authenticator」

サービスアカウントの認証だけを行うなら「Google 認証システム」の方が使いやすいと思います。本ソフトは、Microsoftアカウントのパスワードレス認証に使用するのが良いように思われます。またMicrosoftアカウントの認証は本ソフトだけで行えるようです。

「Google 認証システム」のエクスポート機能で表示させたQRコードを「+」ボタンで本ソフトにインポートすることはできません。インポートするためには変換ソフトでスキームを「otpauth-migration:」から「otpauth:」に変換する必要があります(別記事とする予定です)。

本ソフトには、下記の「クラウドのバックアップ」をオンにしたときに、まれに「問題が発生しました」というアラートが出る問題があります。2年以上前の報告もあることから、すぐにこの問題が対処されない可能性があります。また、この問題が発生した場合の対処法を下記に2つ示しましたが、根本原因が明らかでないので、これらの対処法で必ず解決されるとは限りません。解決できない場合には、登録してある情報をバックアップする方法がなくなります。この状態で、使用中のスマホや「Microsoft Authenticator」が何らかの理由で使用できなくなると、Authenticatorを用いてアクセスしている情報にアクセスする方法がなくなることを念頭において、本ソフトの使用を判断する必要があると思います。

このアラートが出る前に別のスマホの「Microsoft Authenticator」にバックアップの復元をしておくことが良いと思います。いったんこのアラートが出ると別のスマホの「Microsoft Authenticator」に登録した情報を復元できなくなります。

登録したサービスアカウントの別スマホへのコピー方法

「Microsoft Authenticator」に、いったんアカウント登録後、すべてのアカウントを削除した場合は以下の画面が表示されます。この場合は「回復の開始」を押して、同様に図3-4.以降の操作をします。

「クラウドのバックアップ」で「問題が発生しました」への対処方法

「Microsoft Authenticator」で「クラウドのバックアップ」を設定したときに「問題が発生しました」というアラート画面が表示されたときの対処方法を以下に２つ紹介します。

「Microsoft Authenticator」で「クラウドのバックアップ」のバックアップをオフにした後、オンにすると下図の「問題が発生しました」というアラートが表示されることがあります。再現条件は明確ではないですが、WiFiで接続した状態で何度かバックアップのオフ・オンを繰り返すと表示されることがありました。

この状態になると「Microsoft Authenticator」に登録したサービスアカウント一覧をバックアップできなくなり、その結果、復元操作で登録したサービスアカウントを他のスマホに復元しようとしても下図のアラートが出て復元できません。

この状態で、「Microsoft Authenticator」で問題が発生したスマホが動かなくなったら、登録してあるサービスアカウント全てに対して2要素認証の設定をサービス側でやり直す必要があるので、何とかしてクラウドに設定をバックアップできるようにしてそこから復元できるようにしたいところです。

「Microsoft Authenticator」を再インストールすると登録してあるサービスアカウントもなくなるので、再インストールでは対処できません。

この現象は、Microsoftコミュニティに、2020年07月(英語)、2022年08月、2022年12月等に報告されていますが、現時点ではまだ発生します。

2020年07月(英語)の投稿では、DNSの設定をプライベートから自動にするか、WiFiを使わずに電話回線で接続するようにすることで解決した人もいるということですが、それでは解決しないという人たちもいました。WiFiでDNSの設定を変更している人はPi-hole等でフィルタリングをしておりバックアップ先がフィルタリングされているということのようです。

2022年12月の投稿では、別のMicrosoftアカウントを新規に作成して、そのアカウントも「Microsoft Authenticator」に登録してバックアップを試すという案が出ていました。「解決できた方法1」がこの方法です。アカウントを追加すると、「クラウドのバックアップ」をONにしたときにバックアップするアカウントを選択できます。エラーの出たアカウントを選択すると、同じアラートが表示されバックアップできないときとできるときがありました。追加したアカウントを選択したときには試した範囲では全てバックアップすることができました。どちらのバックアップでもバックアップが成功した場合には別のAndroidの「Microsoft Authenticator」で復元すると、登録してあるサービスアカウントを復元することができました。

ただし、復元時にMicrosoftアカウントに以下のような表示がでることがありました。この場合は赤字の表示されている場所をクリックして指示に従えば赤字の表示を消すことができました。「通知の送信」を押した後に、他のスマホの「Microsoft Authenticator」に自動的に通知が表示されないときは、右上の縦の「…」をクリックして、「通知の確認」を選択します。

こうすれば必ずクラウドにバックアップできるようになるという方法は見つかりませんでしたが、試した範囲では上に紹介した方法で解決できましたので、その方法を紹介しました。

最後に

登録したサービスアカウントを簡単に複数台で同期して使えるようにしていないのは、セキュリティを考慮してのことと思われます。

かといって登録した情報のバックアップができないのはそれはそれで問題ですので、「Google 認証システム」では手動でエクスポートをさせることで、どのスマホでサービスアカウントの認証ができるようにしたかをユーザーに意識させるようにしたものと思われます。

「Microsoft Authenticator」はアカウントに紐付けたバックアップからの復元だけを行わせるようにして、「Microsoft Authenticator」をインストールしただけでどのスマホでもサービスアカウントの認証が行えるようにはせず、ユーザーが復元という操作を行ったときだけ複製するようにして、ユーザーに意識させているものと思われます。

PR