クライアント/サーバーアプリケーションのユーザーパスワードをハッシングする

Question

私はiPhoneアプリケーションをWebサーバーと通信しています。 Appを起動するとき、ユーザーはユーザー名とパスワードで認証する必要があります。 AppとWebサーバー間の通信はセキュリティ保護されていますが（HTTPS）、Webサーバーにクリアパスワードを送信する必要はありません。パスワードの「署名」のみを送信したいと思います（署名は保存されます） Webサーバー上のデータベースに格納されます）。

IOSでこの「シグネチャ」を作成する最適なソリューションは何ですか？ MD5などを使用すべきでしょうか？

このシグネチャをビルドするために外部ライブラリを入手する必要がありますか、それともIOS SDKのSecKeyEncryptを使用して行うことができますか？

私はAndroidで動作しているアプリケーションを持っており、IOSとAndroidで同じシグネチャを生成できる必要があります。あなたの助けのための

おかげで、

セバスチャン。

Answer 1

パスワードを平文で送信するのは悪いので、何かをするのは良い第一歩です。努力するつもりなら、それを正しく行う方法を知ることが重要です。

MD5は強力なハッシングアルゴリズムではありませんが、MD5とSHA256（またはSHA512）の選択は、使用方法より重要ではありません。ハッシュアルゴリズムの詳細を無視して、まずそれがどのように使用されるかを見てみましょう。

ハッシュを使用するという考えは、文字列のハッシュは常に同じであり、一方向の操作であるという考え方です。文字列をキャプチャすることによって、パスワードを決定することは可能ではない（または実際的ではない）。近年、虹のテーブルを大量に使用したことで、それは間違っています。レインボーテーブルには、すべての可能なパスワード（指定された長さまで）とそのハッシュが含まれているため、攻撃者は逆引き参照を使用してパスワードを検出できます。レインボーテーブルは、16文字以下のパスワード用のすべてのハッシュアルゴリズムで簡単に利用できます。

この問題の解決方法はいくつかあります。一つは、ハッシュを多く（約1,000回）実行することです。正確な回数は、クライアントとサーバーの両方で事前に把握されている必要があります。これには、ハッシュ生成を高価にする利点と欠点があります。攻撃者が力を発揮するのは計算上より困難になりますが、虹のテーブルは十分大きく拡大されてもまだ有効です。

よくあることですが、あまり一般的ではない解決方法は、既知のランダムな文字列（通常は塩と呼ばれます）をパスワードに追加して長くすることです（おそらく64文字）。この塩は、事前にクライアントとサーバーの両方に知られていなければなりません。この解決策は安価で簡単です。塩が漏れてもそれは問題ではありません。

パスワードハッシングにはもう1つのよくある問題があります。悪意のあるユーザーがユーザーのパスワードのハッシュを知っている場合、それは設計が不適切なシステムのパスワード自体を知ることと同じくらい良いことです。ユーザー名とパスワードハッシュを必要とするRPC関数があるとしましょう。パスワードハッシュを知っている悪意のあるユーザーは、パスワードを知らなくてもパスワードを送信してシステムにアクセスできます。この既知のパスワードハッシュは、ユーザーがパスワードを変更するまでは引き続き機能します。パスワードは数か月です。必要なのは、パスワードハッシュが有効である期間を制限する方法です。これは、動的塩を使用することによって達成されます。

次に、認証は複数ステップのプロセスになります。

1. クライアントはサーバーに接続し、クライアント（またはデバイス）識別子（UUIDなど）を表示します。
2. サーバーは、そのクライアント識別子の動的ソルトを生成します。動的塩は、短期間（一般的には数分から数時間）良好である。
3. サーバーは、将来の使用のためにデータベーステーブルにダイナミックソルト、有効期限、および関連するクライアント識別子を格納します。
4. サーバは、有効期限とともに動的塩をクライアントに返します。
5. クライアントは、上記の2つのメカニズムのいずれかを使用してパスワードをハッシュし、ダイナミックソルトを連結し、ハッシュを再度行い、ユーザー名、クライアント識別子、および動的に塩漬けされたハッシュを使用して認証しようとします。
6. サーバーは、既知のパスワードハッシュをサブミットした値と照合して、クライアント識別子の既知の各動的塩を連結してハッシュすることによって、送信された資格証明を検証します。一致するものが見つかると、認証が受け入れられます。

これは、（大まかに）MySQLで使用されるメカニズムです。 SSLなしで安全に使用できるだけの安全性がありますが、残りのペイロードが保護されるようにSSLを使用することを常に推奨します。

このような安全なメカニズムを使用する場合は、MD5またはSHAバリアントを使用しても問題はありません。つまり、MD5が必要な理由がない限り、新しい開発にはSHA256を使用しないことは意味がありません。

Answer 2

md5は最良のアイデアではありません。今日は本当に高速なレインボーテーブルが多数あります。

iOSでAES256を使用することをお勧めします。これは簡単に行うことができるNSData+CommonCryptoです。

NSString* encryptionPass = @"myEncryptionPass"; 
NSData* passData = [userPassword dataUsingEncoding:NSStringEncodingConversionAllowLossy]; 
NSError* error = nil; 
NSData* encryptedPassData = [passData AES256EncryptedDataUsingKey:encryptionPass error:&error]; 
if(!error) 
{ 
    NSString* encryptedString = [[NSString alloc] initWithData:encryptedPassData encoding:NSUTF8StringEncoding] 
}