2

最近、Google と Yahoo の OpenID エンドポイントを自分のサイトの認証システムに実装したので、ユーザーは自分のサイトでアカウントを作成する必要がなくなりました。かなり一般的な方法ですよね?

具体的な質問がありますが、最初に背景情報を少し。

Three-legged 認証を通過すると、Attribute Exchange を使用してユーザーの名前とメール アドレスを取得しました。現在、ユーザー テーブルの特別なフィールドに OpenID (次のような長い文字列: https://me.yahoo.com/a/2Z7LplQsnI_DgtAw (... 英数字の集まり) を格納しています。

私の users テーブルが次のようになっているとしましょう。

type  id  password                          email             key
1     1   0e9212587d373ca58e9bada0c15e6fe4  test@example.com
2     1   b8d2f4a50d2b364ff2766556ba50da48  me@gmail.com      https://www.google.com/accounts/o8/id?id=AItOawll6-m_y…
2     2   6687d5d88b359ee1340717ebf0d1afc6  you@gmail.com     https://www.google.com/accounts/o8/id?id=AItOawm3-C_9…
3     1   fd193c2fa449c9d6dc201d62d5ca86d3  him@yahoo.com     https://me.yahoo.com/a/2Z7LplQsnI_DgtAw…
1     2   2e710b13b3dd787e2b15eab3dde508c2  person@site.com

types
1 = native account
2 = Google OpenID
3 = Yahoo OpenID

ユーザーがネイティブ アカウントでログインすると、電子メールとパスワードが認証に使用されます (当然)。

ユーザーが Google または Yahoo OpenID を使用する場合、OpenID (キー フィールド) が認証に使用されます。

さて、これですべての背景情報が取り除かれました... OpenID 自体を保存することを忘れて、属性交換から返された電子メールを使用してユーザーを認証した場合、安全でしょうか? 誰かが OpenID トランザクションの 3 番目のレグを偽装することはできますか? または、Google との OpenID トランザクションの属性交換部分から you@gmail.com を取得するたびに、それが本物であり、なりすましではないことを信頼できますか?

4

1 に答える 1

3

このように意図的にプロトコルを破ると、長期的には大きな頭痛の種になります。たとえば、ユーザーがカスタム構築された OpenID サーバーを使用してログインしているが、@gmail.com の電子メール アドレスを提供している場合を考えてみましょう。

OpenID 認証交換後に絶対的な一貫性と信頼性が保証される唯一の情報は、ID URL です。

于 2010-07-13T17:22:39.477 に答える