6

一般に、ユーザーの資格情報を直接(つまり、プレーンテキストで)保存するべきではないことを理解しています。むしろ、それらの暗号化された形式を保存するのが最善です。

ただし、他のサードパーティサイトと相互作用するWebサイトを作成するとします。そして、このサードパーティのサイトが、認証のために(そのサイトで)ユーザーの資格情報を必要とするAPIを提供しているとしましょう。

たとえば、このサードパーティが提供するサービスに加えて、優れたUIを提供したり、追加機能を導入したりすることが私の目標である場合、APIを使用できるように、実際にユーザーの資格情報を何らかの方法で保存する必要があるようです。私のサイトのユーザーのパスワード(私はそれをハッシュしてソルトすることができます)が、外部サイトのパスワードです。

これを行うための「正しい」方法はありますか?私の最初の考えは、サードパーティのサービスへのAPI呼び出しを行う目的でサーバー上で復号化できるように、暗号化された資格情報を何らかの形式で保存することです。これは、攻撃者がユーザーの外部パスワードを盗むために、暗号化/復号化がどのように機能するかを理解する必要があることを意味します。しかし、それは私にはそれほど理解されていないようです。私のアプリケーションをホストしているサーバーをすでに侵害した巧妙なハッカーは、おそらくコードを入手して、それを非常に簡単に理解できるでしょう。

したがって、そのアプローチは、何もないよりはましのように思えますが、必ずしも優れているわけではありません。人々が使用する他の戦略はありますか?この概念全体(ユーザーの資格情報を必要とするサードパーティのサービスとのやり取り)はお勧めできませんか?

かなり有名なWebサイト(Mint.comなど)でも比較的一般的であるように思われるため、この状況に対処するための少なくともいくつかの合理的に安全な方法があると私は信じなければなりません。

更新:明確にするために:理想的な世界では、サードパーティのサービスがOAuthのバージョン(または同等のもの)を実装するため、資格情報を保存する必要がないことを認識しています。残念ながら、この場合の現実は、サードパーティのサービスでは、すべてのAPIリクエストでユーザー名とパスワードを送信する必要があります。それで、私が聞いているコンセンサスは、この場合、ほとんどの開発者がサービスの使用を拒否する(そしておそらくOAuthを実装することを提案する)ということですか?

4

1 に答える 1

5

IMOの意見ではファイルシステムのどこかにクレデンシャルを保存する責任を負わないでください。サードパーティのサーバーでさえユーザーの資格情報を知らないと考えてください(実際のパスワードではなく、パスワードのハッシュが保存されます)。 セッションがアクティブである限り続くhttpセッションの一部としてそれらを保存することをお勧めします。

于 2012-09-27T19:50:01.257 に答える