User login form for external website security issues

Question

Given this hypothetical situation what would be a safe solution?

A large social netwokring (SN) site would like to provide developers with a login solution whereby the user can login directly from the developers site (as opposed to redirecting to the social networking site for authentication/ eg. OAuth), meaning there will be a login form on the developer's site where the user can provide their username and details used on the SN site.

Some of my ideas

The first solution I could think of is post details with an ajax request and a JSONP callback is given with information such as successfull login, error in username/password, or user information such as email address etc. This solution is riddled with issues the biggest being, can the SN site trust every developer? When the user logs in he could send an ajax request storing the users password in a database. Or the user may not even have JavaScript enabled (although ignore this last issue)!!

Alternatively, the SN site could provide an iframe where the user can login and it can call functions on the parent frame. The only security risk I could think of with this solution was if there are any xss vulnerabilties in the SN iframe src page however this is non-existant as the none of the page contains user submitted data.

I would never consider this in an application, I'de just like to extend my knowledge of what the capabilities are.

Answer 1

The short answer is

NO

The explanation why was already kind-of provided by you (for the two hypothetical solutions you described).

1. If the form actually "sits" on your site, you can steal the data (simple javascript on the username+password inputs). No reasonable SN site would give this privilege to 3rd party developers.

2. If the form does not "sit" on your site, but instead sits in an iframe on your site, you are still able to steal the data (take a look at the following stackoverflow question).
   By the way, this is the reason why some sites block their login pages from being loaded once they detect the page is in an iframe

This is why authentication flows such as OAuth were invented! Solutions like this (based on tokens and keeping the login process out of the 3rd party application) are the only currently "safe" solutions that exist and are being used, this is due to the risk that the 3rd party developers might be evil.

By the way, facebook login gives a nice user experience by opening a small window instead of making a full redirection outside of the developer's site.

HAVING THAT SAID
HYPOTHETICALLY (I never saw such a solution, and I'd never use it if I were exposing an authentication service because it's kind of dumb and I it can be easily imitated for phishing purposes) you can do the following:

create a login page using some closed client-side technology (such as the oldie Java Applets, or something similar) and let the 3rd party ebmed it within their pages. The applet should encrypt the data internally before sending it to the server.

Answer 2

Many Login APIs use keys along with the JSON. So If I was connecting to a Social Network(SN) It would want my developer key and application key. This is one of the first of many security checks. After the SN verified that the request is coming from the registered developer's application. The server end will check each entry in the json file for injections and such. Another system that the SNs may do is check the location of the request. They may require the developer to send information through the developer's server, thus being able to track request from the developer's server ip. This way the develop will add extra security on their end as well.

Can a SN trust every developer? No, they really can't. Some API keys require the developer to pay to use, or a rigorous signup process that requires personal information from the developer. This way if the developer does any fraudulent activities, they could be taken to court for their actions. I hope this helped.

--Note-- Oh to add on, you would never want a remote use to log in. Rather, have the user log in at the main SN website. There the user can then add the developer's app to use some of their information. As the SN, you would never want to give developers access to your users passwords.

Answer 3

The main problem with what you are describing is that users would have to be willing to type their SN username/password into a 3rd party website. Only an extremely naive user would ever do that. (So, like, maybe 97% of them.)

As for what the SN would have to do to support said 3rd parties, the answer is nothing. The 3rd party can simply provide their own form to the user, receive the credentials from the user, and attempt to use them to log into the SN. The form could even be made to look like the SN's login form, and have a little lock next to it to confuse some users into thinking it is secure. It would work as long as the SN doesn't do anything to prevent logins from the 3rd party, such as rate limiting the number of logins from the same IP. (Of course that could be worked around by using a larger pool of source IP addresses.)

A safe solution from the SN's perspective would be to train their users to never give their credentials to a third party, even if the 3rd party claims is OK. Of course, as was recently demonstrated, even the NSA can't train it's own employees not to share their passwords, so the SN would probably be fighting an uphill battle.