I have the problem that I want to program a program that will have to interact with some 3rd party web service. This service requires for specific actions that the client (my program) authorizes itself by both a username/password combination as well as a token. The username/password is specific to the user of my program and no of a problem here. The token (API key) is a problem.
Suppose I want to make my program open source and put its sources on some public server. Of course I cannot hardcode (or include) the API key. Otherwise I would not only break the contract not to publish it but also any (non-authorized) usage will fall back onto me and my program.
According to my research (e.g. Open source a project but keep API keys confidential or How to hide the API key in my Electron application?) I could put a proxy server (closed source) between the 3rd party API and my program. Now I see two big open doors for bad-minded people to attack this scenario:
As the source code of the main program is open source, any interaction with the proxy can be literally read from source code. An attacker could fork my main program and use exactly the same calls on the proxy but with compromised data. Same result as with openly available keys: My program will get into trouble for other people's bad actions/programming skills.
I could add a username/password to authenticate the program against my proxy. I then offer (free-to-use) registration to the proxy in order to allow my program to be used productively. This adds an additional layer of authentication and complexity but is doable. Anyone really wanting to do bad things will nevertheless be able to obtain a password and use his own fork to access the proxy. I cannot put my own keys/encryption/.... anywhere as the necessary routine to decrypt/imitate these will be publicly visible in the open sourced project.
So now I have simply shifted the problem to detect if the running software is an original one, from the 3rd party to my proxy server. I only have the benefit that I could maybe know which user was the bad guy and ban him but this is all I can do while my token might get revoked by this issue.
I am sorry but I did not find a usable solution in the web to this specific problem. How can I attack this problem (on an abstract level)?
Related
I built a C++ application that loads dll's (plugins). Before loading a dll, the application checks that the dll's digital signature is part of a white list. This is done to ensure that only authorized dll's get loaded.
I'm trying to do accomplish something similar using an out of process COM server/client. The COM server needs to ensure that only specific clients are able to access it (from a white list). I know that Microsoft provides many different authentication mechanisms for COM, but they seem to revolve around the applications identity (account used to run it). Ultimately, I need a secure way to verify that the COM client is who they say they are, and that they are in my white list.
I'm open to other ways of accomplishing this, but not using COM isn't really an option.
Thanks for any help you can provide
Chris
I think this can be accomplished in DCOM Config in combination with trusted client certificates.
Another way is to implement a method in the interface where the server verifies the client digital signature. In this link is an example how to read out the client cert
How do I read an embedded code signing signature in C++?
I'm using Dropbox OAuth in my desktop application for uploading files. However, my app is open-source, so I have no idea how to store the app secret. If I don't hide it, any other program will be able to use my app identity.
I could include the separate header file (C++) with secret keys and don't distribute this header in my sources, but, in my opinion, such repository will look a bit inadequate (correct me if I'm wrong).
Any suggestions?
I think the typical thing to do here is to omit the app key and secret from your source and give people instructions for how to create their own app key and secret via the Dropbox website.
I think you hit the nail on the head - the nature of sharing your software as FOSS means that anybody can duplicate any portion of your program's functionality; this also implies that anyone can design software to impersonate any aspect of your program. This is by no means a bad thing; it's just the nature of open source.
If you selectively hide your app secret, all you're doing is preventing others from building your source and getting the same result as you get when you build it. That's pretty much contrary to open source principles IMO.
If the problem is the risk of app deletion on some marketplace due to secret getting compromised, then one solution is to generate a new app secret at build time, for each individual build - although this is far from ideal.
I am building a windows 8 application which will be used as the interface to a web service I have running.
I need to find a safe way of encrypting sensitive data to pass, then decrypt it the other end.
Two things I need to do (as they may require separate methods);
1) User will enter a username and password which needs to be authenticated
2) User will enter personal information to be saved.
Now I have looked at many encryption/decryption methods, but I cannot find anything which is common place between the two. For example System.Security.Cryptography is not available within the windows 8 app, and my website can't use CryptographicEngine.
I am basically trying to find the best way to DO what I need to do. Along with a way of actually doing it in code.
You will not be able to use the same namespaces, as you have recognized. What you need to do is settle on a standard crypto algorithm on both ends.
Here is a discussion for one approach on the Win8 side using AES256. http://social.msdn.microsoft.com/Forums/en/winappswithcsharp/thread/8f9ecac4-80d2-47c8-8c41-9d7877565bf5
Here is a solution for doing AES256 with regular .NET
http://msdn.microsoft.com/en-us/magazine/cc164055.aspx
If you just need to secure the channel, then use an HTTPS web service, that's what HTTPS was designed for. The client-side HttpWebRequest class should just do the rest for you.
You'll need a certificate on the web server.
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
My team and me are currently working on quite a large project. We are working on an online game, which will be accessible (for the moment), in two ways:
-Via a web browser, an application full JavaScript(client-side), full Ajax (basically meaning that the UI will be managed in JS client side).
-Via an iPhone application (the UI will be managed by the application itself).
Between the two different applications, the core logic remains the same, so I believe (I could be wrong), that the best solution would be to create a web service (if possible using standards such as RESTful or Rest) capable of perming all necessary operations.
Following this logic, I have encountered a problem: the authentication and identity management of the user. This poses problem as the applications users need to be authenticated to preform certain operations.
I’ve looked into WS-security, but this obviously requires passwords to be stored, unencrypted on the server, which is not acceptable!
I then looked into Oauth, but at first glance this seemed like a lot of work to set up and not particularly suited to my needs (the way that applications have to be accepted does not please me since it will be my application and my application only using the web service, not any external application).
I’ve read and heard about a lot of other ways to do what I want, but to be honest, I’m a little confused and I don’t know what information is reliable and what isn’t.
I would like to note that I’m using symfony2 for the backend and jquery for the client side JavaScript.
Furthermore, I would like a detailed, step-by-step response, because I really am confused with all that I have read and heard.
Thank you for your time, and I hope someone can help me as it’s quite urgent.
Good evening
I'm not entirely sure if this answers your request, but since the UI will always be handled on the client side, I think you could use stateless HTTP authentication:
This is the firewall in security.yml:
security:
firewalls:
api:
pattern: ^/api/ # or whatever path you want
http_basic: ~
stateless: true
And then the idea basically is that on the server, you use your normal user providers, encoders and whatnot to achieve maximal security, and on the client, you send the HTTP authentication headers, for example, in jQuery:
$.ajax("...", {
username: "Foo",
password: "bar"
});
Please note that since the authentication is stateless (no cookie is ever created), the headers have to be sent with every request, but, I figure, since the application is almost entirely client-side, this isn't a problem.
You can also check the Symfony2 security manual for further information on how to setup HTTP authentication. Also be sure to force HTTPS access in your ACL, so the requests containing the credentials are secured (requires_channel: https in your ACL definitions).