1

So now I am pretty much sold to the idea of having pure html+js front end where all processing happens at client side browser and the backend provides all the data in JSON/xml/other format and so on.

Here's the dilemma,

For authentication, I am using OAuth2 Bearer token which gets generated when user authenticate using username and password (for e.g. at login stage).

There is an extra security for which clientside application (i.e.a front end web server or mobile app) that is making request to this WebAPI. When it makes the initial request, it passes "client_id " and "client_secret" to make sure the client is app is authorized to make this request to back end server.

In traditional .NET way I would store the encrypted clientid and key in web.config and my C# (Or VB.NET) code would retrieve it and send it over SSL to the server. So in the manner the client_id and client_secret is not exposed in rendered HTML (for e.g.) to the client side browser.

In pure javascript environment how can I secure my client_id and client_secret (or any other sensitive data for that matter)?

Thanks

activebiz
  • 6,000
  • 9
  • 41
  • 64
  • 2
    1 and 2 should be separate questions, and #3 is way too broad. Yes, there are a billion things you need to know for a client side app. – George Stocker Jun 17 '14 at 13:48

1 Answers1

1

I don't think you can secure your "secrets".

HTML5/JS code is pure text, anyone with a text editor can see it. What people normally try to do is obfuscate their code by using javascript minifiers/compressors; see here for a good discussion. The practice is called Security through Obscurity. But note that obfuscation is not security. Given time and effort, a determined "hacker" will eventually find your secrets. Another step you can take to deter, delay and frustrate such attacks is to spread bits of your secrets in the code, in different modules, etc. Having said that, you'll need to write code to assemble them at some point, so again, no real security.

I have a similar problem because I wanted to use a "shared secret" with the server so I can hash my client requests such that they are tamper-proof and can't be recreated without the attacher knowing the shared secret. Unfortunately I had to give up on the idea, since I realised I couldn't keep it secret enough.

Community
  • 1
  • 1
djikay
  • 10,450
  • 8
  • 41
  • 52
  • So what did you resort to then? Do you then accept the request from any client without any client_id and client_secret? If so doesnt it make pron to random service requests from any servers? – activebiz Jun 17 '14 at 19:29
  • 1
    I've pretty much given up on the idea of having a "secret", since it doesn't seem possible to keep it 100% safe. The client implementation is very early in its development so, for now, there are bigger fish to fry, so to speak. One possible solution for you might be to use a client-side certificate. I don't have any experience in using those but they rely on PKI to encrypt/decrypt text. It's something you might want to investigate further. In my case, the client is going to be a mobile app, so it's a maintenance nightmare to have a client certificate for each client. – djikay Jun 17 '14 at 19:37
  • 1
    Also, my service is using token authentication so only authenticated clients can access data. The problem is that I'm saving the token in local storage so, in theory, some malicious app on a user's phone can detect the token and use it to make spurious requests. I'm thinking of writing code to "encrypt" the token before I save it to local storage but, again, the key will be in my javascript text, so no real point doing that except for the extra effort that will be required to find it. – djikay Jun 17 '14 at 19:42
  • when you say only "authenticated clients can get access". doesnt it mean that your if client_id/client_secret is stored in js, then anyone can pick-up fiddler and start firing requests to your webapi server? – activebiz Jun 26 '14 at 06:04
  • 1
    For clients to be "authenticated", then need to supply a username and password to the server (always over HTTPS), which will check their credentials and, if valid, return a token. For subsequent requests, the clients will only need to supply the token. As I mentioned in my last comment, this token will need to be stored somewhere on the client side. If a malicious code running on the client is able to grab that token then yes, they can start firing requests to my server. I'll try to obfuscate the token somehow but, eventually, a determined hacker will always be able to find a way round this. – djikay Jun 26 '14 at 09:47
  • Thanks @djikay , FYI i have come across http://security.stackexchange.com/questions/44214/what-is-the-purpose-of-oauth-2-0-redirect-uri-checking?newreg=206eb61c04d04848b0f89aad4d97837a. which is using redirect_uri. I am still trying to understand how its done. Any inputs would be welcome. – activebiz Jun 26 '14 at 09:59