モバイルアプリケーションによるAPI認証（SMSによる）

Question

現在、RESTful APIを使用したモバイルアプリケーション通信に（好ましくは単純な）認証システムを実装することが義務づけられています。バックエンドには、ユーザーの電話番号で識別されるユーザー固有のデータがあります。私は、一般的なセキュリティ、そこにあるさまざまな方法、そして彼らが働く仕組みがなぜ機能するのかについて、より多くのことを理解しようとしています。

私は、単純な認証システムを考えた：

• クライアントが自分の電話番号と生成されたGUIDを含んAPIに検証要求を送信します。
• サーバーは、確認コードを使用して電話番号にSMSメッセージを送信します。
• クライアントは、固有のGUID、電話番号、確認コードを送信して、端末を確認します。
• サーバーは、クライアントがさらなる要求に使用できる何らかの種類のアクセストークンで応答します。

私は、次の質問がある：

は、このアプローチに大きな欠陥がありますか？ HTTPSを使用していると仮定すると、暗号化されていないとデータを送信するのに十分な安全性がありますか？ Googleのアプリだけがトークンを読むことができるように、トークンにモバイルデバイスに安全に保存することができますか？ それ以外のことは考えていませんか？

携帯電話が盗まれたり他の方法で侵害された場合、データはもはや安全ではありませんが、それは克服するのが難しいリスクであることは既にわかっています。アクセストークンは、このリスクを最小限に抑えるために一時的に有効になる可能性があります。

私はこのアプローチが簡単で、どこかに大きな欠陥があると仮定しています。私を啓発できますか？

Answer 1

瑕疵があります。システムはブルートフォース攻撃の影響を受けやすい。

私が攻撃者であると仮定します。私は自分のためのguidを生成し、任意の電話番号と一緒に送信します。

次に、私は可能なSMSコードを調べてみましょう.6桁の場合、10^6の組み合わせしかありません。ブルートフォースはほんの数秒で終わります - そして、私はこの電話を持っている人のデータにアクセスします。

また、Filou氏のコメントで指摘されているように、任意のSMS番号を送信するように強制することができ、実質的に財務的損失を無料で維持できます。

この攻撃から有効な防衛もありません：指定されたUIDのための試みの限られた量（N）がある場合は

1. が、私は GUIDごとにNの試みを再生成します。
2. 時間あたりの電話1台あたりのリクエスト数が制限されている場合、偽のリクエストで可能なすべての数字を氾濫させてDoS/DDoS攻撃を実行することができるため、誰も要求を実行できません。

SMSの前にログイン/パスワードまたは証明書の認証がであることが必須です。です。また：

1. 暗号化/セキュリティプロトコルでGUIDのようなものを使用しないでください。 GUIDは確定的です（つまり、1つの値を知っていれば、将来の値を予測できます）。ランダムストリームを生成するために暗号ライブラリの組み込み関数を使用する
2. セキュリティプロトコルを自分で設計しようとしないでください。決して。 SSL 1.0のクリエイターたちが落ちたにもかかわらず、非常に多くの警告があります。彼らは鋭い人でした。一般的で実績のあるスキームをコピーする方が効率的です（Googleの認証は素晴らしい例です）。

Answer 2

あなたが言及したアプローチはうまく動作します。クライアントは電話番号とランダムIDでリクエストを開始し、サーバは検証トークンをデバイスに返します。トークンは、有効期限が設定されている1回のみの使用です。その後、クライアントは、電話番号、以前に使用されたランダムトークン、およびサーバーが検証する検証トークンを送信します。有効な場合、サーバーは認証に使用できるセッショントークン（または認証トークン）などを送信します。セッショントークンは、サーバーからタイムアウトを設定できます。
あなたはウェブアプリかどうかは言及していません。 Webアプリケーションの場合は、サーバーからhttpsのみのセッションCookieを設定できます。それ以外の場合は、アプリのローカルストアにローカルに保存することができます。通常の場合、アプリは他のアプリに属する​​個人情報を読み取ることができません。
すべての通信はHTTPSを使用して行う必要があります。そうしないと、最終的に認証トークンを使用しているため、スキーム全体がトラフィックのスニッフィングによって侵害される可能性があります。