I want to add integration with a third-party service to a web application (developed in HTML and Javascript) which targets Android / iOS (and later Windows Phone). Thus I have access to all “modern” features. This third-party service needs credentials and is controlled via GET-Parameters.
For example, a request url could look like “http://www.example.org/foo?username=user&password=1234”.
Changing the third-party service to accept hashed passwords is no option as I have no access to it.
As the user does not want to type in his username and password every time he uses the service or starts the application, I want to save his credentials somehow.
Now I wonder, what’s the best way to do so.
I know that real “security” is an illusion here but I do not want to expose the credentials to unnecessary risks by saving them the wrong way.
I already thought about several possible ways
- Plain Cookies: The most
straightforward way – is it “secure”
enough in this scenario? - DOM-Storage:
Any differences to cookies in this
relationship? - Encrypted Cookies: The
credentials would be encrypted, but
you could easily find out the key
when looking at the source code of
the page or debugging it.
Which one should I choose? Are there any better ways?
Is bothering with encrpytion actually worth it when it can be cracked that easily?
All the ways are bad and insecure. So is sending username and password as a get param – you even run this over https?
The way to do this usually is to not store the username/password at all, but a GUID/hash that identifies the users session, and then let that session be persisted.
That way, even if somebody else gets access to the session, they won’t have the username/password. As part of this, people cannot change the password unless they supply the existing.
Connect to and authenticate with the 3rd party service through a backend proxy if it absolutely needs to have username/password sent.