2017-03-28 23 views
0

私は認証のためにasp.netアイデンティティ2.0を使用してMVCウェブサイトを持っています。 アンドロイドモバイルアプリの同じDB用のREST APIも開発中です。 REST APIの認証にID 2.0のハッシュパスワードを使用したいのですが、アンドロイドアプリからプレーンパスワードを送信しないでください。 AndroidアプリはID 2.0ユーザーマネージャと同じ方法でパスワードをハッシュする必要があります。そうすれば、Android Appから送信されたパスワードとAspNetUsersテーブルにあるパスワードを比較できます。 Java/AndroidでID 2.0のPasswordHasherを実装するための実装やガイドラインが見つかりません。ここでASP.Net Identity 2.0 and rest API for android

は、私は最後の2日間以来立ち往生しています助けてくださいアイデンティティ2.0 PasswordHasher https://raw.githubusercontent.com/aspnet/Identity/5480aa182bad3fb3b729a0169d0462873331e306/src/Microsoft.AspNetCore.Identity/PasswordHasher.cs

のC#コード..ですクライアント上でパスワードをハッシュ

答えて

1

は悪い考えです。どのようにプレーンテキストでパスワードを送信する方が良いでしょうか? MiTM攻撃者がハッシュされたパスワードを取得した場合、システムにログインする必要があります。はい、元のパスワードを送信していませんが、事実上パスワードになるハッシュを送信していて、パスワードのプレーンテキストハッシュをデータベースに保存しています。

また、塩についてはどうですか? Identityフレームワークでは、saltはハッシュと同じフィールドに格納されています。同じ文字列でPasswordHasher.HashPassword()を10回実行すると、この結果にはすでに塩が含まれているため、10種類の結果が得られます。これをクライアント上で実行しようとすると、毎回異なる文字列が得られ、すでにデータベースに格納されているハッシュ/ソルトと比較することはできません。だから、同じ塩でハッシュできるように、サーバーから何らかの形で塩を渡さなければなりません。これは、過度に複雑になり、間違って実行される傾向があります。

セキュリティシステムを自分で作成しようとしないでください。暗号化された接続でプレーンテキストでユーザー名/パスワードを渡し、フレームワークにハッシュ/永続化をさせます。

+0

クライアントでパスワードをハッシュする利点は、必ずしもシステムをより安全にするわけではないが、クライアントのセキュリティをさらに強化することです。 MiTM攻撃の場合、攻撃者は、ユーザーが同じパスワードを使用する他のアプリケーションで使用されるプレーンテキストパスワードを持ちません。 – keelerjr12