9

現在、RESTful API を使用したモバイル アプリケーション通信用の (できれば単純な) 認証システムの実装を任されています。バックエンドには、ユーザーの電話番号で識別されるユーザー固有のデータがあります。セキュリティ全般、さまざまな方法、およびそれらが機能する理由についてもっと理解しようとしています。

簡単な認証システムを考えました：

  • クライアントは、電話番号と生成された GUID を含む検証要求を API に送信します。
  • サーバーは、確認コードを含む SMS メッセージを電話番号に送信します。
  • クライアントは、一意の GUID、電話番号、および確認コードを送信して、デバイスを確認します。
  • サーバーは、クライアントがさらなるリクエストに使用できる何らかのアクセス トークンで応答します。

次の質問があります。

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

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

私は、このアプローチが単純であり、どこかに大きな欠陥があると仮定しています:)教えてもらえますか?

4

2 に答える 2

6

欠陥があります。システムはブルート フォース攻撃を受けやすい。

私が攻撃者だとします。自分用の GUID を生成し、任意の電話番号と一緒に送信します。

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

また、Filou のコメントで指摘されているように、任意の数の SMS を送信するように強制することができ、事実上無料で経済的損失を被ることができます。

この攻撃に対する有効な防御策もありません。

  1. 特定の UID の試行回数 (N) が限られている場合は、N 回試行ごとに GUID を再生成します。
  2. 電話あたりの時間あたりのリクエスト数に制限がある場合、考えられるすべての番号を偽のリクエストであふれさせることで、DoS/DDoS 攻撃を実行できます。したがって、誰もリクエストを実行できなくなります。

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

  1. 暗号化/セキュリティ プロトコルで GUID などを使用しないでください。GUID は決定論的です (つまり、1 つの値を知っていれば、将来の値を予測できます)。ランダム ストリームを生成するために暗号ライブラリ組み込み関数を使用する
  2. 自分でセキュリティ プロトコルを設計しようとしないでください。一度もない。SSL 1.0 の作成者でさえ陥った非常に多くの警告があります。一般的で実証済みのスキームをより適切にコピーします (Google の認証はその好例です)。
于 2013-08-13T13:07:38.407 に答える
0

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

于 2013-08-13T11:03:42.463 に答える