最高の携帯電話番号認証戦略は何ですか？
近年、携帯電話番号は認証の重要な要素となっており、SMSを使用してユーザーの携帯電話番号を取得する方法を採用する企業が増えています。
典型的なシナリオでは：
- UI（Webサイトでもアプリでも）は、ユーザーに自分の携帯番号を入力するように求めます
- サーバーはトークンを生成し、提供された携帯電話番号にそのトークンを送信します
- ユーザーは新しいUIに切り替える必要があります（つまり、SMSを取得するためにウェブサイトからモバイルデバイスに切り替えます。同様に、ユーザーが最初にアプリを使用していた場合、ユーザーはSMSアプリに切り替える必要があります
- 次に、ユーザーは受信したトークンをコピーまたは記憶する必要があります
- 次に、ユーザーは元のGUIに切り替えて、
- コピーまたは記憶されたトークンを元のWebサイトまたはアプリに入力し、
- キーを押す（たとえば）と
- サーバーが入力されたトークンを処理するのを待ちます
- 最後に、サーバーは入力されたトークンを検証し、正しい場合はその携帯電話番号を承認し、ユーザーの認証手段として設定します。
- 最後に結果がGUIに表示されます
これは、よく知られているほとんどのIT企業（Google、Facebookなど）がユーザーの認証に使用する典型的なシナリオです。
代替シナリオ：
- ユーザーが操作しているUI（Webサイトでもアプリでも）は、ユーザーに携帯電話番号の入力を求めます
- サーバーはトークンを生成し、そのトークンを同じUIでユーザーに表示し、指定された番号に送信するようユーザーに要求します
(Server Messaging Centre Number = SMCN)ユーザーが入力した携帯電話番号を使用します。- ユーザーは、表示されたトークンをコピーまたは記憶する必要がある場合があります。
- ユーザーは新しいUIに切り替える必要があります。たとえば、元のUIがWebサイトの場合、ユーザーはモバイルデバイスに切り替えてトークンを入力し、それをSMCNに送信する必要があります。ユーザーが元々アプリ内にいた場合も同じです。その場合、ユーザーはSMSアプリに切り替える必要があります。ただし、この場合、アプリはメッセージを事前入力する場合があります）
- ユーザーはSMCNにメッセージを送信します
- ユーザーは元のUIに戻す必要があります
- トークンがサーバーに送信されたことを確認します
- サーバーが入力されたトークンを処理するのを待ちます
- サーバーは入力されたトークンを検証し、正しい場合はその携帯電話番号を承認し、ユーザーの認証手段として設定することができます
- 結果はUIに表示されます
ユーザーエクスペリエンス、セキュリティ、その他の要素の観点から、どちらの方法が優れていますか？
どちらもセキュリティの点で同等に優れています。
私によると、最初のsenerioは十分に良く、適応されたものです。私たちは最初のセネリオに慣れています。 2番目のsenerioはあまり変更を加えず、不必要にユーザーは新しいアプローチで混乱してしまいます。
UXに関しては、最初のセネリオは非常に簡単で、ユーザーはこれが起こることを知っています。
インドのユーザーのほとんどはSMCNを知らないため、SMCNを検索する必要があります。これもユーザーに不満を生じさせます。
最初のsenerioでは、ユーザーはアプリとSMSランチャーを切り替える必要がありません。トークンSMSを受信した場合、SMSモバイルでの通知、コードはアラートでのみ表示され、少なくとも30秒間覚えておく必要があります。
上の画像を参照してください。今[〜＃〜] miui [〜＃〜]により、ユーザーはアラートバナーからトークンをコピーするだけです[アプリを切り替える必要はありません]
また、モバイルメーカーが最初のsenerioに適応し、それに応じてUIを変更していることも確認できます。
私は正直に言うと、セキュリティ対策として携帯電話を検証するというアイデアは好きではなかったと言います。より多くの場所がこれをsole検証方法として使用し始めており、これは、これらのプロバイダーのいくつかでアカウントを作成する方法がないため、携帯電話。しかし、私はそれがこのようにして喜んでいる人々にとって完全に有効な「オプション」であると思います、それは利用可能な唯一のオプションではないはずです。
とにかく、あなたの質問と、フィードバックを求めている2つのアプローチに戻ります。もともと私はどちらもセキュリティの点では本質的に同じだと思っていましたが、他の人は2番目のアプローチには問題があると指摘しています。ユーザーエクスペリエンスの観点から見ると、どれも不格好であるという点では、どちらも同じだと思います。
2つのうち1つを選択する必要がある場合は、ユーザーエクスペリエンス、セキュリティ、およびその他の要素の点でより優れた方法が最初の方法になります。それは、より多くのサイトがそれを行っている方法でもあり、したがって、このアプローチに精通しているかもしれません。親しみやすさは期待を生み、これは通常はユーザーが期待するものと一致するため、より良いユーザーエクスペリエンスにつながります。次に、このアサーションを裏付けるための参考資料をいくつか示します。
- http://www.cruxcollaborative.com/2-keys-to-unraveling-user-expectations/
- http://infinvision.com/familiarity-in-user-experience/
- http://www.uxmatters.com/mt/archives/2011/07/how-cognitive-fluency-affects-decision-making.php
- http://www.creativebloq.com/web-design/ux-design-patterns-work-91516961
したがって、大幅に改善された変更が必要な場合を除いて、これを避けたくはありません。
より良い4ステッププロセス
とはいえ、主な質問のタイトルである「最良の携帯電話番号認証戦略とは何ですか？」に対する回答を提供したいと思います。
この提案は変更が必要だと思います。なぜなら、それがはるかに単純な4ステップのプロセスだからです。シンプルになるだけでなく、安全性も向上し、ユーザーエクスペリエンスが大幅に向上します。これがどのように機能するかです（会社がAppleであると仮定しましょう）...
- UI（Webサイトでもアプリでも）はユーザーに携帯電話番号の入力を求めます
- UIは、自動電話を受信しようとしているときにユーザーに指示し、受信したらプロンプトに従います。
- ユーザーが電話を受けると、「Apple-はいの場合は1を押し、いいえの場合は2を押す "からの呼び出しを期待していましたか？」「はい」の場合、IVRは、ユーザーが先に入力した携帯電話番号の最後の6桁を話すか入力することによって、ユーザーにこれを再度確認するように要求しますUI。次に、検証を確認して電話を切ります。いいえの場合、IVRは次のように言います「ありがとうございます。ご不便をおかけして申し訳ありません。」.
- 元のUIが更新され、検証が確認され、携帯電話番号がユーザーに対して認証されるようになりました（もちろん、ユーザーが通話を予期していない「いいえ」を選択した場合を除く）。
話の終わり。安全、シンプル、高速。そして、それはユーザーにとってより良い体験を提供します！
このアプローチは、ユーザーがすでに6桁を知っているため、より良いオプションです。ユーザーが画面にアクセスするために「記憶」したり、画面を切り替えたりする必要はありません。サーバーは、セキュリティ/認証チェックを行って詳細を確認します（つまり、引き続き確認します）ユーザーは入力した携帯電話番号にアクセスできます）。
この4つのステッププロセスの別の実装は、会社がサーバーにランダムに何かを生成させることです（これによりセキュリティが向上すると思われるため-主張しません）。次に、非常によく似た4つのステッププロセスを採用します（仮定しましょう）。会社はグーグルです...）.
- UI（Webサイトでもアプリでも）はユーザーに携帯電話番号の入力を求めます
- サーバーはランダム「覚えやすい」ワード（「スーパーマン」、「エレファント」など）を生成し、ユーザーに表示して指示します自動通話を受信しようとしており、受信したときにプロンプトに従います。
- ユーザーは電話を受け、システムは「Googleからのこの電話を待っていましたか-はいまたはいいえ」と答えます。 「はい」の場合、IVRは、以前に提供されたランダムで覚えやすい単語をユーザーが話すことを要求しますそれら。次に、検証を確認して電話を切ります。 いいえの場合、IVRは「ありがとうございます。ご不便をおかけして申し訳ありません。
- 元のUIが更新され、検証が確認され、携帯電話番号がユーザーに対して認証されるようになりました（もちろん、ユーザーが通話を予期していない「いいえ」を選択した場合を除く）。
個人的には、音声認識やユーザーの理解に関して、言語やアクセントに関する問題を回避できるという理由だけで、最初の4ステップのプロセスを好みます。この問題は、たとえば次のような研究によってカバーされています。
- http://www.callcentrehelper.com/contact-centres-hang-up-on-speech-recognition-27512.htm
- http://www.usan.com/customer-self-service-ivr/ivr-and-the-freedom-to-speak/
- http://customerthink.com/talk-about-cx-customization-in-2014-you-need-to-understand-accents-what-accent-does-your-business-have/
これらのリスクが問題でなければ、おそらく2番目のアプローチを選ぶでしょう。しかし、どちらのアプローチも、前のステップの半分未満しか取らず、ユーザーにより優れたエクスペリエンスを提供する、はるかに単純なプロセスを心に留めています。
元のユーザーインターフェイスがモバイルアプリであった場合のもう1つのオプションは、デバイスからユーザーの携帯電話番号（携帯電話の場合）を自動的に取得して、ステップ1をすばやく追跡することです。ただし、これがユーザーが使用したい数であるかどうかをユーザーに確認することになるので、ステップ1はまだ必要だと思います。
とにかく、これは私の最高の携帯電話番号認証戦略です。
:)
これがなりすまし攻撃に対して広く開かれていると誰も指摘していないことに私は驚いています。
SMS=偽の発信者（送信者）と一緒に送信することは信じられないほど簡単で、ほとんど費用がかかりません。
メッセージが番号の本物の所有者から送信されたものである（または、その番号がまったく存在する）とは信じられません。
次のことを確認しているため、従来のモデル（ユーザーにメッセージを送信するモデル）はより安全です。
- 番号が存在し、メッセージを受信できます
- 「認証」しようとしている人は、その番号にリンクされているサービスにアクセスできます
双方向の検証は、異なる通信チャネルを使用するため、はるかに安全です。最初の方法は、ユーザーエクスペリエンスとセキュリティの点で優れています。
バリアを減らす必要があります
サインアッププロセスに双方向の検証サイクルを組み込むことができます。 SMS個人の場合は費用がかかるmoney。ユーザーにSMSの支払いを行わせると、ユーザーはそれを別の障壁として感じることができます。SMSが唯一の方法ではありません。これらの検証サイクルを完了するために自動電話通信も使用されます。ユーザーはこのような基本的なパターンに料金を支払いたくないでしょう。
ユーザージャーニーはどこで続行しますか？そこに留まります
多くの検証ケースでは、 SMSはメインチャネルではなく、ユーザーはブラウザまたはソフトウェアの一部を続行します。ユーザーは画面から続行するため、画面に戻ることおよび画面からの（承認/却下）がユーザーの点で優れています。経験。
SMS送信者番号/テキストは安全ではありません！
送信者番号は手動で変更でき、思ったほど安全ではありません。 Daveoc64が示唆したように; SMS世界の数字を信頼することは、歪む可能性があるため、かなり安全ではありません。彼のポイントに加えて、SMSは、あまりにも多くのトラックを残し、他の企業が聞くことができる未使用の容量。ここで誤解があります; Two Factor Authenticationはあなたを安全にします; SMSチャネル自体
回答機能を使用して申し訳ありませんが、コメントするにはまだ十分な評判がありません。 :(
Monomeethが提案する4ステップのアプローチが本当に好きだと言いたかっただけです。私はKISS原理の大ファンであり、このアプローチは適合しているようです。
私が見ることができる唯一の欠点は、あなたがあなたのパートナーの隣の真夜中にベッドに横たわっていて、あなたが電話を受けた場合、それはあまりダウンしないかもしれないので、UIはユーザーを許可する必要があるでしょう彼らが番号を提供する前にプロセスがどうなるかを知っているので、彼らはその時点で自分の携帯電話番号を確認するのに最適な時期なのか、それとも待つべきなのかを決定できます。
それ以外の場合は、質問で概説されている11のステップよりも4つの単純なステップのほうがはるかに好ましいでしょう。
このUXを改善するために、トークンの値を確認するためにアプリを切り替えるということはすでにたくさんあります。要約させてください：
1）今日の多くのアプリは、着信SMSを待って読み取って、コードを検出し、ユーザーに事前入力することができます。これは非常に良い方法であり、完全に新しいソリューションというよりも機能強化です。アプリがユーザーを検出できない場合は、とにかく、SMSトークンを確認できます。ほとんどのシナリオでは、トークンは自動的に正しく読み取られます。参照：https://www.quora.com/In-any-mobile-app-transaction- can-an-app-read-the-OTP-SMS-and-auto-fill-the-bank-page-to-finish-the-transaction
2）@Abhishek Sharmaが上記のように示しているように、アラートはトークンを覚えて追加するための優れた方法です。私たちのほとんどはそれに依存しています。昔、私はPAYTMがOTPメッセージを誤って実行することについての投稿を書いていたため、トークンの値を最初の最初の行ではなくメッセージの奥に入れると、トップバーアラートで簡単に表示できます。ここの記事： https://pregnantwithideas.wordpress.com/2015/08/07/paytm-com-user-experience-review/ 。 Paytmはこの投稿を同じように変更しました。
セキュリティの点では、どちらもかなり似ています。
ただし、ユーザーフレンドリーの観点からは、ユーザーにシステムにテキストメッセージを送信するように要求することはしません。 whatsapp、iMessageなどの時代から、誰もが計画にテキストメッセージを持っているわけではありません。少額の費用がかかる可能性があり、それが障壁になる可能性があります。
もちろん、指定された番号にテキストメッセージを送信するには追加料金がかかります。これは収益計画の一部です。
全体的なオプション1の方がユーザーフレンドリーです。
また、これは以前にも述べたように、モバイルデバイスで作業している場合、通常、アプリにいる間は着信テキストメッセージが一時的に表示されます。つまり、ユーザーは現在のアプリから移動する必要がなく、受け取ったセキュリティキーをすぐに入力するだけで済みます。これにより、オプション1がより高速で、（ユーザーにとって）最も安価になります。