二要素認証開発者ベストプラクティス

Twilioの二要素認証の実装における知見は、アプリケーションへの二要素認証を組み込む際に避けるべき陥穽や従うべき共通パターンをつまびらかにしてきました。 このページには一般的な疑問に対する回答や、二要素認証の実装時に役立ちまとまった知見とベストプラクティスが含まれています。

このベストプラクティスの多くはすでにTwilioの二要素認証クイックスタートに組み込まれています。 ご自身で実装を始める前にクイックスタートをお試しいただくことをお勧めします。

二要素認証の実装をカスタマイズする

ご自身のアプリケーションにAPIの実装を始める前に、Twilio ConsoleでAuthyアプリケーションを作成することになります。 ここでは認証セットアップのルックアンドフィールとユーザー体験をカスタマイズする機会が与えられます。

カスタムロゴ、画像、および色

既定では、Twilio Consoleでセットアップされたアプリケーションのリクエストに既定のロゴと画像が使用されます。 これを変更するには、左側のサイドバーで「画像と色 (Images & Colors)」リンクをクリックします。 大きな画像(プッシュ通知がアクティブな間表示されます)と小さな画像の両方をアップロードしてください。 画像の最大サイズは128 Kbです。

ページ上の画像の下では、文字、見出し、そして背景の色を変更することができます。 また、追加でタイマーの色を変更することもできます。 加えられた変更はページ右側の電話機のプレビューでただちに反映されます。

API経由で、リクエストごとにカスタムロゴを設定することもできます。 詳細については、ApprovalRequests APIページを参照してください。。

Two-factor Authentication Messages

既定では、Authy APIはユーザーのメッセージにアカウントセキュリティーConsoleのアプリケーション名を自動的に使用します。 「アプリケーション名」としてConsoleで設定したものは何であれ2FAのメッセージに反映され、文章の残りの部分は自動的にローカライズされ、ユーザーに対して送信されます。

二要素認証のリクエストのメッセージには、キャリアーによるスパムフラグを回避するため、いくつかの亜種があります。 一般的には下記のような形式です。 しかしながら、一部の単語とその並び順は変更される可能性があります:

Your <Application Name> verification code is: 1234

カスタムメッセージ

既定のメッセージの亜種では不十分な場合のために、Authy APIではアカウントごとにフラグ設定されるカスタムの二要素認証メッセージがサポートされています。 カスタムメッセージを有効にするには、お客様のビジネス要件を添えて株式会社KDDIウェブコミュニケーションズのサポート窓口までご連絡ください。 キャリアーによるフィルタリングやブロックを引き続き避けるため、弊社の使用するものと大幅に異なるカスタムメッセージが必要となる点にご注意ください。 上記のご判断の際には、弊社営業チームがお手伝いをいたします。

メモ: カスタムメッセージをオンにした場合、必要なローカライズと翻訳をご自身で行うことが必要です。 

Your <Application Name> Service Number is 1234!

 

二要素認証アプリケーションのセキュリティーを確保する

Consoleでアプリケーションのセットアップが済んだので、ここでご自身のアプリケーションロジックにAPIを実装していく方法について見ていきましょう。 

新規ユーザーを登録する

高度なセキュリティーのため、新規ユーザーの登録を行う際には下記のワークフローに従うことを推奨します。 各ステップでは直前のステップを済ませていることを前提としています:

  1. 電話番号検証(アカウント検証)を使用して、デバイスがエンドユーザーの所有物であるかどうか判断します。
  2. 継続的な二要素認証の使用方法については、ユーザーを登録します。
  3. Twilioの二要素認証を必須とし、ログイン、高リスクな操作、および高額取引の任意の組み合わせについて保護します。

追加の詳細やお客様独自の要件の検討には、弊社営業チームまでご相談ください。

Twilioからのプッシュ認証検証リクエストを検証する

Twilioでは、プッシュ認証のWebhookリクエストがTwilioから送信されており、かつこれが改竄されていないことの確認にHMAC署名検証を提供しています。 プッシュ認証はTwilioと直接行われるため、Twilioはお客様の公開したエンドポイントに対して検証結果を伴うWebhookをレスポンスとして返します。 検証なしにテストを行うことは可能ですが、本番環境ではリクエスト検証のためのコードを追加することが必要です。 (Twilioのアカウントセキュリティーヘルパーライブラリーを使用すると、このステップが簡単になります)。

Twilioからのすべてのリクエストには、Consoleのアプリケーション APIキーでHMAC-SHA256を使用しハッシュされたX-Authy-Signature HTTPヘッダーが含まれます。

受信Twilioプッシュ認証の検証手順については、こちらに詳細が記載されています。

トークン生成のアルゴリズム

Twilioのトークン生成コードでは、RFC 6238のワンタイムパスワードアルゴリズムが実装されています。

二要素認証の配信チャネルを理解する

こちらの概要ページに、4種類のAuthy APIの認証チャネルについて説明していますが、Twilioの提供するこの4つのチャネルそれぞれの高次の長所と短所を理解することは重要です。

SMS(または音声通話)チャネルを使用すべきですか?

SMSはソフトトークンやプッシュ認証よりもセキュリティーの低いチャネルですが、多くの場合認証の選択肢として利用できるようにしておくと良いでしょう。 SMSのサポートはすべての携帯電話に組み込み済みで、追加でアプリケーションをインストールせずとも、SMSを使用して配信されたトークンはユーザーに配信されます。 パスワードのみの認証かパスワードとSMSを併用した場合かを比較した場合、勝者は明らかにSMSを併用する方法です。 Twilioはまた、一般的なSMS認証の実装に加えて追加のセキュリティーを提供しています。 たとえば、特定のエンドポイントへの配信(オンラインSMSポータルなど)を制限することで、いくつかの攻撃要因を回避しています。

同様の議論は音声通話チャネルにも当てはまります。 世界の一部の地域では、音声通話のトラフィックが優先されています。 音声通話のチャネルを有効にしておくことで(アプリケーション設定では規定でそうなっていない場合があるため)、一部の地域でトークン配信の信頼性を向上させることができます。

もっともセキュリティーの高い2FAチャネルはどれですか?

プッシュ認証はもっともセキュアなチャネルであり、そして同時にエンドユーザーにとっても大変利便性の高いものです。 モバイルアプリケーションを開いてもらったり、Webサイトのトークンにアクセスしてもらったりする代わりに、プッシュ認証は簡単に操作可能な「承認/否認」ダイアログを表示します。 加えてプッシュ認証における「否認」は、その際のユーザーのアクションについてのより詳細な調査を適用するための、アプリケーションのビジネスロジックで使用可能なシグナルでもあります。

プッシュ認証ほどセキュアではありませんが、ソフトトークン(App内またはSDKで生成されるTOTP = Time-based One Time Passcodes、時間ベースのパスコード)は依然として強固なセキュリティー手段になります。 ソフトトークンはプッシュ認証における「否認」シグナルは提供せず、標的型攻撃のような他の攻撃箇所は存在し得ますが、トークンはSMSまたは音声通話チャネルと比較するとはるかにセキュリティーの高い手段になります。

二要素認証のチャネルはどのように制限すべきですか?

TwilioのAuthy APIには前方互換性があルため、SMSチャネルのサポートを追加することは、自動的に音声通話およびソフトトークンに使用可能になることを意味しています。 プッシュ認証に必要なのは、ポーリングまたはWebhookのサポート用のわずか数行のコードを追加することだけです。

APIまたはアカウントセキュリティーConsoleで特定のチャネルを強制することは可能ですが、またエンドユーザーごとにどのチャネルを使用するか分類できます。 たとえば、エンドユーザーに音声またはSMSのチャネルをオプトインさせたり、一部の使用頻度の高いエンドユーザーに対してソフトトークンまたはプッシュ認証の使用を必須とするようにしたい、といったことが考えられます。

特定の要件についてはお気軽に株式会社KDDIウェブコミュニケーションズにお問い合わせください。

送信量制限およびタイミング制限について理解する

アプリケーションの開発時には、数々の留意すべき送信量制限、冗長性、タイムアウト時間があります。 送信量制限はしばしばセキュリティー要件に関わる事柄のため、これらの値は変更される可能性があります。

Time Synchronization, Validity Window, and Time Drift

Soft tokens are valid plus or minus 3 minutes from the nominal time on the server. Generally speaking, the client and server are synchronized if the client is connected to the internet, but in extreme cases tokens may be valid for up to 6 minutes. To work around issues of time synchronization and drift, if your users have the Authy App it will opportunistically synchronize clocks with our servers when an internet connection is available. SMS and voice channels are synchronized, so requests are valid for exactly three minutes.

Passcodes will continue to work even when a phone is offline or in airplane mode, as long as the total time differential is less than three minutes when codes are submitted. We are unable to extend the validity window for your application beyond +/- 3 minutes, or 6 total minutes (3 for SMS/Voice).

Our time drift implementation is based on RFC 6238, which builds on RFC 4226. For a further discussion of time synchronization and drift, see those RFCs.

One Time Password (OTP) Length

By default, Two-factor Authentication apps will use 7 digit passcodes. You can change them to be from 6 to 8 digits in the 'Settings' link of the Authy Console.

TOTP Length

 

レイテンシー(遅延)

While we don't guarantee a two-way latency, the majority of our requests will complete in under 500 milliseconds. This will vary depending on your method of connectivity, network congestion, and geographic distance among other reasons.

 

Build Your Custom Mobile Authentication App

二要素認証を統合するための最速手段として、Authy APIをAuthyのデスクトップまたはモバイルAppとペアリングすることが挙げられます。 ご自身のソリューションを開発するプランに移行するのに先立って、まずはAuthy Appをお使いいただくことを推奨します。 Authy Appで開発を始めた場合、一部のデバッグ手順やアプリケーション開発の初期段階における大きな変動要素が取り除かれます。

You can take a staged approach to building an app, starting with Authy, then supporting the Authy App and your own applications simultaneously before moving to a single client solution. Here are the quick links for more information on the SDK:

 

Still Have Questions on Best Practices?  We're Here to Help.

二要素認証についての紛らわしい点、あるいは検討されているデザインパターンが実装するに値するかどうかについて関心がおありですか? Twilioのサポート窓口にお問い合わせいただけましたら、お客様にあった機能をお探しし、開発中のアプリケーションに最適に昨日する実装についてお手伝いします。

ヘルプが必要ですか?

誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。