メニュー

Rate this page:

Thanks for rating this page!

We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

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

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

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

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

First before you start implementing the API in your application, you will create an Authy application in the Twilio Console. Here you have an opportunity to customize to the look, feel, and user experience of your authentication setup.

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

By default, your application's requests will use the default logo and image set up in the Twilio Console. To change it, click on the 'Images & Colors' link on the left sidebar. Upload both a large image (seen while the push notification is active) and a smaller icon. The maximum image size is 128 Kb.

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

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

二要素認証のメッセージ

By default, the Authy API automatically uses the Application Name from the Account Security Console in user messages. Whatever you set in the Console as the 'Application Name' will be reflected in 2FA messages, and the rest of the text will be automatically localized and translated for your users.

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

Your <Application Name> verification code is: 1234

カスタムメッセージ

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

Note: You will need to provide any localization and translation necessary on your own if you enable custom messaging.

Your <Application Name> Service Number is 1234!

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

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

新規ユーザーを登録する

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

  1. Use Phone Verification (Account Verification) to determine if the user has the device they claim currently in possession.
  2. 継続的な二要素認証の使用方法については、ユーザーを登録します。
  3. Twilioの二要素認証を必須とし、ログイン、高リスクな操作、および高額取引の任意の組み合わせについて保護します。

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

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

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

All requests from Twilio will include a X-Authy-Signature HTTP Header, which is hashed using HMAC-SHA256 with your Application API Key from the Console.

We've written up the steps to validating incoming Twilio Push Authentication Verifications in detail here.

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

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のサポート用のわずか数行のコードを追加することだけです。

You can force specific channels through the API or the Account Security Console, but you can also segment your users into specific channels. For example, you might want to allow users to opt-in to voice or SMS channels, or require some high-volume users to use soft tokens or push authentications.

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

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

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

時間の同期、有効期間、時間のズレ

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.

電話機が通信圏外であったり機内モードであったりしても、コードが入力時の時間のズレの合計が3分以内である限りパスコードは機能し続けます。 プラスマイナス3分、あるいは合計6分(SMSと音声通話の場合は3分)を超えてアプリケーションに対して有効期間を延長することはできません。

時間のズレに対応するためのAuthy側の実装はRFC 4226上には構築されたRFC 6238に基づいています。 時間同期とズレに関する追加の議論については、これらのRFCを参照してください。

ワンタイムパスワード (OTP) の長さ

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の長さ

レイテンシー(遅延)

Twilioでは往復レイテンシーを保証しませんが、Twilioのリクエストの大部分は500ミリ秒以下で完了します。 これは接続方法、ネットワークの混雑、およびその他の要因の地理的距離によって変化します。

カスタムモバイル認証Appを開発する

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

アプリケーションの開発は段階的アプローチを採用可能です。 まずAuthy (App) からスタートし、それから単一クライアントのソリューションに移行する前にAuthy Appとご自身のアプリケーションを同時にサポートします。 以下でSDKについての追加情報がご覧いただけます。

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

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

ヘルプが必要ですか?

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.