Even though I don't 100% understand your intent and goals, please pay attention for my comment to the question, where I tell you that such practice won't be safe. I'll try to explain why.
Please follow my logic. If, as you say, the login page for an external site is also on this site, the enrollment procedure (when a user creates account, username and password and post relevant data to the site) is defined on that site, and you don't have a control over it. Now, please understand why this should always be done by a human operator, as well as all authentications. Of course, you can simulate user input on your site, assuming the user trusts it, using, say, .NET
HttpWebRequest (which you can always do on server side, as you are using .NET).
Don't do it for this purpose! Even if your user trusts your site on that, you will break this trust: the user should not trust you. I'll also explain why. Keep reading.
Let's assume the external site is safe. First of all, it means that the
passwords are not stored anywhere, except user's brain. How can this be possible? One of the ways, the one which is most often used, is using the
cryptographic hash function. The password is actually never needed for authentication. The user only types the password manually, and the hash of the password is compared with the hash of the password, stored on the site, when users creates their accounts. As hash is
irreversible, it's
infeasible to restore the password based on hash. Please see:
http://en.wikipedia.org/wiki/Cryptographic_hash_function[
^].
Now, I'm afraid you are going to store a real (non-hashed) password on your site, otherwise it would be quite difficult, if even possible, to authenticate on this external login page in simulated way. And storing of the original password is so unsafe, that you should
just forget about cryptographic strength of your side! And, worse, by doing so you would also badly betray the users of the external site.
Don't do it, ever.
Look again at my comment to your question. You should better follow the architecture of the collaboration between eBay and PayPal. The key reason for having separate sites is that people can use PayPay to do monetary transactions not related to eBay. Even though PayPal belongs to eBay, the sites are independent. eBay has unlimited access to PayPal pages, but the user has separate accounts on both sites,
and always authenticate on both sites manually and separately, for a good reason. That's why people
trust eBay and PayPal and
should not trust your application, unless you follow my advice and do things safely.
Good luck,
—SA
Submit an article or tip