海賊版などについてはあまり気にしませんが、バックエンド（Railsベース）がDOSなどの自動化されたサービスに開かれていないことを確認したいと思います。したがって、バックエンドへのすべてのアクセスを単純に確認したいと思います。 （これは、データをGETおよびPUTするためのいくつかのRESTクエリになります）は、マシン上で実行されているスクリプトではなく、有効なiPhoneアプリケーションを介して行われます。
ユーザーエクスペリエンスがシームレスになるように、アカウントの使用を避けたいと思います。
私の最初の意図は、UDIDとシークレットを一緒にハッシュし、サーバーへのHTTPS接続を介してそれ（およびUDID）を提供することです。これにより、認証されたセッションを作成できるようになるか、エラーが返されます。
盗聴された場合、攻撃者はハッシュを取得してリプレイし、このスキームをリプレイ攻撃に対して開いたままにする可能性があります。しかし、HTTPS接続は盗聴から私を保護するべきではありませんか？
ありがとう！
bpapaが言うように、それはなりすましになる可能性がありますが、あなたが言うように、誰かがやって来て、サーバーに1000の要求を続けて送信するだけで、サーバーがそれぞれを処理する必要があるので、それほど心配する必要はありません。 。
ハッシュについてのあなたの考えは良いスタートです。そこから、現在のタイムスタンプを事前にハッシュされた値に追加して、それを送信することもできます。指定されたタイムスタンプがサーバーの現在の時刻と1日以上異なる場合は、アクセスを禁止します。これにより、とにかく1日以上後にリプレイ攻撃が停止します。
別のオプションは、ナンスを使用することです。誰でもサーバーにナンスを要求できますが、デバイスはハッシュをサーバーに送信する前に、それをプレハッシュデータに追加する必要があります。生成されたナンスは保存する必要があります。または、単にサーバーの現在のタイムスタンプである可能性があります。次に、デバイスは、事前にハッシュされたデータにサーバーのタイムスタンプではなくサーバーのタイムスタンプを追加する必要があります。これにより、リプレイ攻撃が発生するまでの期間が1日よりもはるかに短くなります。
クライアント証明書でSSLを使用します。クライアントに秘密鍵を持っていて、その証明書を発行します。セッションを続行するために、Webサーバーはこのクライアント証明書の存在を要求できます。
Railsのコードの詳細を説明することはできませんが、アーキテクチャに関しては、少しやり過ぎかもしれませんが、最も安全な方法です。証明書付きのSSLは標準的な業界ソリューションであり、ライブラリはiPhone /クライアント側とサーバー側の両方に存在するため、何も発明したり、多くを実装したりする必要はなく、それらをうまく連携させるだけです。
また、HMAC-SHA1のようなHMACを検討することもできます。これは、基本的に、ここで他の人が話しているハッシュの標準化です。ノンスを追加すると、リプレイ攻撃に対しても安全になります。ナンスを使用してHMAC-SHA1を実装する方法については、OAuthプロトコル（フロー全体ではなく、ナンスと他のパラメーターを認証された要求に結び付ける方法）を確認できます。
なりすましの可能性があるため、これを保証する方法はありません。
本当にこのルートに行きたい場合（正直なところ、ここで本当にスーパーミッションクリティカルなことをしているのでない限り、おそらく時間を無駄にしているでしょう）、iPhoneデバイストークンを渡すことができます。または、ハッシュしてから渡すこともできます。もちろん、サーバー側などで検証する方法はありませんが、悪意のある人が本当にあなたを倒したい場合は、最初に対処しなければならない障害＃1があります。