1

ユーザーとパスワードの組み合わせを送信する必要があるモバイル アプリケーション用に構築しているフローについて、意見をお願いします。私の考えは、AES-256 を使用してパスワードを暗号化し、ランダムなパスフレーズと IV を生成してキーを生成することです。パスワードが最初に生成されるときに、暗号化されたパスワードと IV. IV と暗号化されたパスワードはサーバーの redis DB に保存され、キーと暗号化されたパスワードはモバイル デバイスにのみ保存されます (IV はデバイスに保存されません)。したがって、ユーザーがログインする必要があるたびに、暗号化されたパスワードとキーがサーバーに送信され、IV が保存されます。サーバーは、送信された暗号化されたパスワードと DB に保存されたパスワードの両方を、送信されたばかりのキーと IV を使用して復号化します。すでにサーバー上にあります。

ユーザーがパスワードを変更したい場合、暗号化されたパスワード、キー、および IV が再度生成され、それらが一致する場合は古いもの (キーと暗号化されたパスワード) も送信され、サーバーで値が更新され、クライアントに通知が送信されます。それらも更新します。

このトランザクションはすべて、SSL トンネリング内でも行われます。

これは安全だと思いますか?そうでなければ、なぜですか?モバイルデバイスからサーバーへの安全な方法でパスワードを暗号化/復号化する他のオプションはありますか?

よろしく。

4

1 に答える 1

0

これを行う最善の方法は、データを送信する前にクライアント側でパスワードのハッシュを実行し、ハッシュを送信することです。次に、サーバーにそのハッシュで独自のハッシュを実行させて、パスワードがクライアントを離れる必要がなく、保存されたハッシュのブルートフォースからプレーンテキストのパスワードを取得できないようにします。

前にリストした KDF (pbkdf2、scrypt、bcrypt) は時間がかかるため、セキュリティが通常よりも重要でない限り、クライアントで実行してからサーバーで実行したくないでしょう。KDF は、誰かがハッシュからパスワードを総当たり攻撃するのを防ぐために使用されます。これは、ユーザー ハッシュを格納するテーブルが侵害された場合でも、ユーザー パスワードのプレーン テキストは安全であることを意味します。たとえば、クライアントで KDF を実行し、サーバーで KDF が生成したハッシュの単純なソルト付き MD5 を言う場合、ユーザーのプレーン テキスト パスワードは安全ですが、アクセスできた人にとっては簡単かもしれません。保存されたハッシュ (サーバーが侵害されていることを意味します) を使用して、そのユーザーとしてログインします。サイト/アプリが stackoverflow である場合、サーバー自体が既に侵害されていれば、ユーザー アカウントが侵害されても問題にならない可能性があります。一方、ペイパルの場合、アカウントにアクセスできる人は、ハッシュ テーブルにアクセスするだけではアクセスできないユーザーの銀行口座にアクセスできます。この場合、クライアントとサーバーの両方で KDF を実行するのが最適です。

SSL の使用に関しては、サーバーが実際に自分のサーバーであり、MITM が行われていないことを確認する方法があれば、それは良いことです。これらのいずれかが侵害された場合、平文でパスワードを送信すると、攻撃者が平文のパスワードにアクセスできるようになります。

于 2013-02-14T20:39:22.497 に答える