We’re rewarding the question askers & reputations are being recalculated! Read more.
3 added 85 characters in body
source | link

how can end-users verify the authenticity of the login forms that collect their credentials?

When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking thetheir browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared withand permissions granted to the appplication.

AE.g., if you're authenticating with Google, expect to be redirected to a consent form looks somethingscreen like this:

What's to stop a malicious website from displaying a fraudulent Google or Facebook login form, for the purpose of harvesting user credentials?

On the other hand, ifIf you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your input is safe (unless you're willing to carefully inspect the app's source, which is unrealistic for the average user).

And from the chaptersection about security considerations:

When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking the browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared with the appplication.

A consent form looks something like this:

On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your input is safe (unless you're willing to carefully inspect the app's source, which is unrealistic for the average user).

And from the chapter about security considerations:

how can end-users verify the authenticity of the login forms that collect their credentials?

When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking their browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared and permissions granted to the appplication.

E.g., if you're authenticating with Google, expect to be redirected to a consent screen like this:

What's to stop a malicious website from displaying a fraudulent Google or Facebook login form, for the purpose of harvesting user credentials?

If you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your input is safe (unless you're willing to carefully inspect the app's source, which is unrealistic for the average user).

And from the section about security considerations:

2 added 85 characters in body
source | link

On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your datainput is safe (unless you're willing to carefully analyzeinspect the app's source, which is unrealistic for the average user).

RFC 6749 (The OAuth 2.0 Authorization Framework) addressescomments on the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the general problem with embedding:

(Resource owner = the user)

On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your data is safe (unless you're willing to carefully analyze the app's source).

RFC 6749 (The OAuth 2.0 Authorization Framework) addresses the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the problem with embedding:

On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your input is safe (unless you're willing to carefully inspect the app's source, which is unrealistic for the average user).

RFC 6749 (The OAuth 2.0 Authorization Framework) comments on the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the general problem with embedding:

(Resource owner = the user)

1
source | link

Third-party authentication protocols on the web usually rely on redirecting to the authentication provider rather than allowing (potentially untrusted) sites to embed their authentication controls.

When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking the browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared with the appplication.

A consent form looks something like this:

OAuth consent form

(Image Source)

On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your data is safe (unless you're willing to carefully analyze the app's source).

RFC 6749 (The OAuth 2.0 Authorization Framework) addresses the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the problem with embedding:

9.  Native Applications

   (...)

   When choosing between an external or embedded user-agent, developers
   should consider the following:

   (...)

   o  An embedded user-agent poses a security challenge because resource
      owners are authenticating in an unidentified window without access
      to the visual protections found in most external user-agents.  An
      embedded user-agent educates end-users to trust unidentified
      requests for authentication (making phishing attacks easier to
      execute).

And from the chapter about security considerations:

10.11.  Phishing Attacks

   Wide deployment of this and similar protocols may cause end-users to
   become inured to the practice of being redirected to websites where
   they are asked to enter their passwords.  If end-users are not
   careful to verify the authenticity of these websites before entering
   their credentials, it will be possible for attackers to exploit this
   practice to steal resource owners' passwords.

   Service providers should attempt to educate end-users about the risks
   phishing attacks pose and should provide mechanisms that make it easy
   for end-users to confirm the authenticity of their sites.  Client
   developers should consider the security implications of how they
   interact with the user-agent (e.g., external, embedded), and the
   ability of the end-user to verify the authenticity of the
   authorization server.

(Emphasis my own)