モバイルアプリに「Remember me」を実装するにはどうすればよいですか？
「Remember Me」の時間制限付き自動ログインタイプ機能をモバイルアプリケーション（Android）に実装したいと思います。アプリを起動するには、ユーザー名とパスワードを入力する必要があります。便宜上、
[〜＃〜]編集[〜＃〜]
最後に入力したユーザー名またはパスワード、あるいはその両方を電話のファイルに保存して、ユーザーが毎回入力し直さないようにします。
this を見ましたが、ブラウザ指向のようです。
質問：
- ファイルまたはパスワードを暗号化するにはどうすればよいですか？ハードコードされたキーを使用して暗号化することはできませんか？どういうわけか鍵を生成しなければならないでしょう。ただし、ユーザーが終了して再起動した場合-別のキーが生成されると想定しているため、何らかの方法でキーを保存する必要がありますか？
- 暗号化する必要がありますか？ （とにかく、ユーザーだけがこのファイルにアクセスできるようにするべきだと思います...）
編集2
代理キーやssl/tslを使用した公開キー認証を使用して、これらを複雑にしすぎていませんか？つまり、Firefoxは私のパスワードを保存し、確かにそれらは何らかの方法で暗号化されていますか？同様の方法でユーザー/パスを暗号化することを考えていましたか？それは悪い考えですか？
ユーザー名とパスワードとは別にアカウントに関連するログイン時にランダムにマッピングされた値を作成するというsymcbeanの提案が好きです。ただし、具体的に質問に答えるために、静的にマップされたキーなしでデータを暗号化する方法もあります。私は、電話に固有でOS API呼び出しを介して取得できる情報のビットを使用してキーを生成することを検討します。
編集：@DWの要請により、詳しく説明します：UDID、シリアル番号、およびその他の識別情報は、保存された暗号化の解読を防ぐために電話にアクセスすることなく、十分な暗号品質と機密性を備えている場合がありますデータ。ただし、保存されたデータへのアクセスには、電話へのアクセスも含まれる可能性があります。したがって、デバイスローカルの暗号化によるセキュリティのレベルは、単純なものです。
他の回答者は、HTTPセッションで行われるようにランダムな値を保存することを提案しています。元の質問者はHTTPを使用していないようで、この方法が彼のソフトウェアに適用されるとは考えていません。ただし、ランダムな値の保存と送信の論理的な実装は、どのトランスポートプロトコルにも適用できます。強くお勧めします。
または、公開鍵暗号化を使用して、クレデンシャルを電話機に保存できます。アプリケーションは、サーバーの公開鍵を使用して、エントリ時にユーザー名とパスワードを暗号化できます。したがって、デバイスが危険にさらされていても、ログインデータは読み取れません。
ログイン認証情報の取得を防ぐことが目的の場合、ランダムな一時識別子を使用するのが最善だと思います。これにより、サーバーデータ（秘密キー）を秘密にして利用できるようにするという問題が排除されます。そのキーが開示された場合、保護は役に立たない程度になります。紛失した場合は、新しいキーを使用してアプリを再デプロイする必要があります。一時的なログインデータが失われた場合、誰もがログインを余儀なくされますが、サービスが著しく中断されることはありません。
また、最初のログインと、ユーザー名とパスワードまたはランダムな値であるかどうかに関係なく、その他の可能な認証データの両方に、トランスポートの公開鍵暗号化（SSLまたはアプリに埋め込まれたシンプルなPGPキー）を使用してください。
ユーザー名とパスワードを電話に保存しないでください。
代わりに、次の2つの戦略のいずれかに従うことをお勧めします。
永続的なCookieを使用します。これは簡単な解決策です。 Webサイトに接続している場合は、初めてログオンするときにサーバーでユーザーを認証し、ユーザーのアカウントに関連付けられている（暗号化された）ランダム128ビット文字列を含む永続的なCookieをユーザーの電話に設定します。その後ユーザーがアプリケーションを起動するたびに、アプリケーションがHTTP/HTTPSを介してサーバーに接続すると、クライアントは永続的なCookieを送信し、サーバーはこれを使用してクライアントを認証できます。理想的には、HTTPSを使用し、安全なCookieを使用します。
公開鍵認証を使用します。これはよりトリッキーなソリューションです。電話アプリケーションに独自の公開/秘密鍵ペアを生成させることができます。ユーザーが初めてログオンすると、アプリケーションは公開鍵を送信でき、サーバーは公開鍵をそのアカウントに関連付けることができます。その後ユーザーがアプリケーションを起動するたびに、アプリケーションは秘密鍵を使用してサーバーに対して自身を認証できます。
たとえば、Webテクノロジーを使用している場合、クライアントに自己署名証明書を生成させ、HTTPSを使用してサーバーに接続し、クライアント証明書を使用して自身を認証させることができます。 AndroidのWebビューがクライアント証明書を適切にサポートしているかどうかをテストする必要があります。
または、独自のカスタムプロトコルを使用してサーバーに接続する場合は、SSLまたはTLSでトンネリングし、SSL/TLSのクライアント証明書機能を使用します。
トークンにユーザー名/パスワードを使用しないでください！
復号化が可能な場合は、復号化される恐れがあります。そして、ほとんどの人々は知らないはずのことを知っていますが、複数のサービスに同じパスワードを使用しています。そのため、サービスに特に価値がない場合でも、与えられたパスワードを保護する責任があります。
問題を解決する方法は、HTTPセッションの管理と同じです-サロゲート識別子（セッションCookieと同じ値を保持する可能性がありますが、寿命が長い）を使用し、サロゲート識別子のルックアップテーブルを維持します。に発行され、有効期限。
D.W.の2番目のオプションは、次の修正と追加の詳細を使用して最適に実装されます。
- ユーザーが通常の認証メカニズムを使用して正常に認証された後、その認証されたセッション中に、アプリでキーペアを生成します。
- 電話でUUIDを生成し（OS/APIの組み込みデバイスIDや、他のアプリが取得できる他の一意の識別子を使用しないでください）、暗号化して保存します（*アプリデータの暗号化のベストプラクティスについては以下を参照してください）携帯電話で）。
- uUIDといくつかの利用可能な電話の詳細の組み合わせをプログラムで使用し、（単に連結するのではなく）マッシュアップして、アプリだけが知っているAppDeviceIdを生成します。
- 公開鍵+ AppDeviceIdをセキュリティで保護されたチャネル（本当に信頼されたCAによって署名されたSSL/TLS）経由でサーバーに送信します。妥協することなく、デバイスと公開鍵を登録します。
- 暗号化のために：UUID（AppDeviceIdの作成に使用するものではない）といくつかの利用可能な電話の詳細の組み合わせを使用して、プログラムで暗号化キーを生成し、（単に連結するのではなく）少しつぶします。電話のロック画面のパスワード/ピンをより適切に結び付けることができる場合（iOSでは、これはフードチェーンの下でキーチェーンで行われ、IFFユーザーが実際にロック画面のパスワード/ピンを使用します）。
- 暗号化キーを生成するために作成したUUIDを、アプリのみがアクセスを「許可」されているストレージに保存します（ルート化されたデバイスは、あらゆるアプリまたはユーザーがおそらくそれにアクセスできることを意味します...そしてこれが最も弱い点です） 。
- appDeviceId用に作成したUUIDを暗号化して保存し、暗号化された秘密鍵を暗号化して保存します。ここでも、アプリのみがアクセスを「許可」されているストレージを使用します（ルート権限を取得されたデバイスは、アプリやユーザーがおそらくそれにアクセスできることを覚えておいてください）。
- 将来認証するために、アプリはアプリとサーバーの両方に既知のペイロードに署名する必要があります。秘密鍵を使用してAppDeviceIdを作成し、セキュアチャネル（SSL/TLSなど）を介してサーバーに送信します。サーバーは、公開鍵を使用して署名を検証する必要があります。
- サーバーが所定のAppDeviceIdを使用して試行された認証を受信した場合、失敗すると、登録された公開鍵を削除/削除/忘れ、ユーザーが他の（通常）より安全な方法で認証するまで、この鍵ペアメカニズムを使用した認証の試行をブロックします。 、実証済みの手法（この新しい手法で拡張する認証プロセスや、適切なドキュメントを直接使用するなど）。
- キーペアに時間制限を追加することはさらに優れており（長時間のハイジャックを軽減）、ユーザーは時折、より安全で実証済みの技術を使用して認証を行う必要があります。
上記を介して、コードの逆コンパイルとリバースエンジニアリング+デバイスに保存されたデータへのアクセス（デバイスへの物理アクセスORルート化されたデバイス上の悪意のあるアプリ）+デバイスの知識（フィンガープリント）いくつかのトリックを介してORデバイスへの物理アクセスORデバイス上のアプリの制御）は、そのキーペアとAppDeviceIdを使用して認証することができます。