0

I have a username and password stored in a db with 2 way encryption. I would like to use these to log into a site with a JS form like this:

        var form = document.createElement("form");
        form.setAttribute("method", "post");
        form.setAttribute("action", "http://www.someloginscript.com/");
        var f = document.createElement("input");
        f.setAttribute("type", "text");
        f.setAttribute("name", "username");
        f.setAttribute("value", myUser);
        var f1 = document.createElement("input");
        f1.setAttribute("type", "text");
        f1.setAttribute("name", "password");
        f1.setAttribute("value", myPass);
        form.appendChild(field);
        form.appendChild(f1);
        document.body.appendChild(form);
        form.submit();

I would like to submit the form with the password, however to do this I need to decrypt it first. If I decrypt it then the password is visible through the 'Inspect Element' functions. I obviously don't want this.

I have stumbled upon a site called www.clipperz.com which does exactly what I want but I am not sure how. Do I need to implement their open source encryption library from http://sourceforge.net/projects/clipperz/ ? Or is it all smoke and mirrors that makes it appear more secure?

thanks!

edit: I now know that there is no secure way of doing this. Is using curl a more secure way of submitting this form? This way I can keep all the handling of passwords server side?

2
  • sounds stupid but instead of f1.setAttribute("type", "text"); have you tried f1.setAttribute("type", "password"); Commented Apr 27, 2011 at 11:15
  • The problem is that this string is readable long before this point. At some stage it needs to be retrieved, decrypted and stored in the variable. It is plain text at any stage post decryption Commented Apr 27, 2011 at 11:23

2 Answers 2

2

You haven't specified it exactly, but it sounds like you're trying to use Javascript on one site to automate a login process into another site? Is that correct? It also sounds like you want to use a general login for all users, which you need to prevent the users from seeing.

I don't think this will be workable in the way you're trying to do it. The problem is that the user on the browser has complete access to the Javascript code and all the data it uses, via tools like Firebug. Using these tools, he can even go as far as modifying the code after the page has loaded.

In short, there is no way of letting Javascript handle the data without giving the user the ability to see it.

I would suggest a better approach might be something as follows:

  • Site 1 sends a message to Site 2, informing it that it wants to log in a user. It tells it the users IP address, the login details it wants to use and other relevant details.

  • Site 2 responds to Site 1 with a token code which Site 1 then sends to the user's browser.

  • The Javascript code on the user's browser then posts the token to Site 2 instead of a login name and password.

  • Site 2 recognises it as the token it just gave to Site 1, and that it has come from the IP address it was told about, and logs the user in as if it had received a normal set of login details.

This process obviously requires you to write code on both Site 1 and Site 2, so you have to have full access to both of them. If Site 2 is a third party system, then you may have to come up with something else.

Sign up to request clarification or add additional context in comments.

2 Comments

cheers for the comprehensive response. Site2 is a third party site so I will need to come up with something else. Perhaps curl will be a more secure way of submitting the form?
Curl will indeed be much more secure. But it has the disadvantage that the login will be tied to your server rather than to the user's PC; this may cause things not to work if you need to do subsequent requests from the user's PC. (you could route them all through your server, but this will go wrong if you have multiple concurrent users). The best approach may be simply to contact the owners of Site 2 and discuss your requirements with them; they may have an API already, or be willing to work with you on a solution similar to the one I described.
1

Whatever information you end up sending to the third-party site, will have to be made available to the user's browser at some point - and at that point they'll be able to inspect it and get the information out.

Alternatively, they could look at the HTTP requests being made from their machine.

The point is, information on the user's machine can't be hidden from the user if it needs to be in a decrypted state on their machine at any point.

2 Comments

Thanks for the response. This makes perfect sense. So, does this mean that there is a way to submit this form server side? Perhaps this is how clipperz.com is doing it?
Clipperz doesn't seem to hide the passwords from the user, it just gives you a way to not have to type them youself

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.