3

Given the ubiquitous use of third party authentication providers in web apps today, how can end-users verify the authenticity of the login forms that collect their credentials? What's to stop a malicious website from displaying a fraudulent Google or Facebook login form, for the purpose of harvesting user credentials? Is there something about OAuth, OpenIdConnect, etc. which prevents this behavior? It seems like it would be quite prevalent if not.

EDIT: As others have pointed out, web apps are supposed to redirect the user to the authentication provider's site, rather than embedding the login form in their own page. What actually sparked my interest in this topic was the Postman browser app in Chrome, which displays a Google login form with no indication of its origin or destination.

2
  • 1
    Do you have a concrete example where an authentication provider actually has their login form embedded on an untrusted site? Google, Facebook, etc. always redirect to a login form on the provider's domain where you can verify the address and lock icon in the URL as well as the service you're authenticating with and which information will be shared.
    – Arminius
    Jan 13, 2018 at 19:54
  • The postman browser app in Chrome is an example. Admittedly it's not a standard web app, but it displays what appears to be an embedded Google login form.
    – echo
    Jan 13, 2018 at 20:51

2 Answers 2

1

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

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 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:

OAuth consent form

(Image Source)

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).

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:

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).

(Resource owner = the user)

And from the section 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)

0

Arminius's comment answers your question for all actual implementations of this.

However were the form embedded in the parent page you could open the developer tools and check the domain the iframe was loaded in from. You could also enter fake credentials and watch to see where the request were sent to.

All recent versions of major desktop browsers (chrome, Firefox, ie, opera, Edge etc) have the toolsets needed to perform both of the above.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .