私は現在、ログインレスサービスを含むプロジェクトを計画している段階にあります。
ユーザーは、クライアント(ios)で作成された一意のデバイスIDによって識別されます。
セキュリティ上の懸念は何ですか?攻撃を防ぐための一般的なパターンは何ですか?
- ソケットはSSLでラップされます
- クライアントを検証するためのプライベート証明書を作成しますか?(誰かがバイナリを逆コンパイルして取得するのはどうですか?)
どんな考えでもありがたいです
私は現在、ログインレスサービスを含むプロジェクトを計画している段階にあります。
ユーザーは、クライアント(ios)で作成された一意のデバイスIDによって識別されます。
セキュリティ上の懸念は何ですか?攻撃を防ぐための一般的なパターンは何ですか?
どんな考えでもありがたいです
このシナリオの「攻撃者」は誰ですか? ユーザーを攻撃から保護していますか、それともユーザーを攻撃者として扱っていますか? ユーザーを攻撃者として扱うスキームは、セキュリティ スキームではなく、DRM スキームです。セキュリティと DRM はまったく別の問題であり、DRM の問題は解決できません。これは、絶え間ない努力とパッチによってのみ軽減できます。
iOS では一意の ID を簡単に作成できますが (「参考文献」を参照CFUUIDCreate
)、デバイスではなく、特定のインストールにのみ関連付けられます。ユーザーがプログラムを削除し、UUID を別の場所 (iCloud など) に保存しなかった場合、次に UUID を作成するときは別のものになります。
ユーザーを認証できます。彼らには頭の中に秘めている秘密があります。iPhone のような汎用デバイスは、許可されたユーザーが偽造できない方法で認証することはできません。これは非常に複雑な言い方ですが、あなたが Apple でなければ、脱獄の問題は解決不可能であり、解決しようとして多額のお金を費やす価値はありません。(彼らは脱獄を止めるために、あなたの開発予算全体よりもはるかに多くのお金を費やしてきました。
デバイスを弱く識別する方法があります。特に、MAC アドレスを使用できます。Appleが将来これを取り除く可能性は非常に高いです。ユーザーをスパイするために悪用するのは簡単すぎるため、デバイスを一意に識別する他の方法を削除しました。
ユーザーを認証するためのプライベート証明書を作成することは素晴らしいことです。プログラムを認証するには?それは単なる難読化であり、あなたのプログラムが苦労する価値がある場合、すぐに取り出されます。
この一般的なトピックは、SO で何度も議論されてきました。いくつかのディスカッションへのリンクについては、以下を参照してください。これまでに取り上げられていない具体的な質問がある場合は、お知らせください。