認証資格情報(ユーザーID /パスワード)を平文で送信するモバイルアプリを継承しました。
私には2つの選択肢があると思います。a)TLSを使用する。b)独自の認証プロトコルを作成します。
(b)を選択した場合、それを安全にするために従わなければならない重要なガイドラインは何ですか。たとえば、リプレイ攻撃を回避する方法、暗号化戦略。
b)を使用する場合、重要なガイドラインは次のとおりです。あなたがそれを安全にしたいのなら、それはそうです。
a)に固執してみてください。
独自のセキュリティ プロトコルを作成する必要はありません。ほぼ間違いなく、悪用可能な欠陥があります。ログイン資格情報の機密性を保護することだけが必要な場合は、SSL/TLS を使用する必要があります。また、将来的にクライアント証明書ベースの認証に簡単にアップグレードすることもできます。
(b)については、チャレンジ/レスポンスを行うと思います。
サーバーはランダムな文字列を生成し、それをクライアントに送信します。クライアントはそれをパスワードに追加してすべてをハッシュし、ハッシュをサーバーに送り返します。サーバーは同じ計算を行い、結果をクライアントから取得したものと比較します。それらが一致する場合、クライアントは正しいパスワードを送信しました。
最も明らかな脆弱性は、誰かが交換の両側をスヌープした場合、パスワードに対してオフライン辞書攻撃を実行できることです。
「訴えられることはない」と「合理的に保護されている」という「安全」の定義の両方について、モバイル アプリケーションの場合、回線は中間者攻撃に対して安全であり、盗聴に対して広く開かれていると想定できます。 . SSL/TLS が最も簡単な方法のように思えますが、これはキャリアと対象の電話によって異なる場合があります。
TLS を機能させることができず、独自に作成する必要がある場合は、Diffie-Hellman鍵交換と確立された暗号ライブラリーを使用してください ( Legion of the Bouncy Castleには、J2ME 準拠の jightweight 実装があります)。