My site will be using the APIs like Paypal and also making Facebook Apps. So lets say for Facebook, they allow only https for Apps to work with them. Mine is only hosted on http site.
So can i solve this problem by buying a Shared Hosting with SSL included?
Is it a solution? or do i need to buy my own Certificate?
I'm not having enough knowledge about SSLs. Any suggestion please.
There are a lot of providers, that offer an SSL certificate for your domain, on shared hosting. Normally they will handle the installation for you, not sure if you can install your own certificate. Some providers even offer to use their own certificate for free, you will have to use an URL like https://www.providerdomain.com/yourdomain/... though.
Apart from unserious offerings, you can distinguish between cheaper domain-validated SSL certificates and the more expensive extended-validation SSL certificates (EV).
Both certificates are technically the same (the connection is encrypted), but domain-validated certificates are cheaper, because the seller only has to check the domain. The EV-certificates also require information about the owner of the domain, and the seller should check, if this information is correct (more administrative effort).
In most cases the domain-validated certificate is fine, the user will have no disadvantages and the EV-certificates are really (too) expensive.
So can i solve this problem by buying a Shared Hosting with SSL included?
SSL on shared hosting usually implies that you can not access your own domain via SSL, but have to use something like https://youraccount.yourhostersserver.tld
That means, other users on your server might probably use that same domain in their apps, if they only rely on the shared SSL certificate as well. Let one of them spam on Facebook, and in the worst case scenario the whole domain yourhostersserver.tld might get blocked by Facebook.
Also, if a user gets into “direct contact” with your app’s website, they might see this URL as well (as long as you stay inside Facebook, canvas/page tab app, most users will probably not notice it).
So I would not really recommend this option; at least not for something that you consider halfway important.
Related
The Stage
I'm working on a web application to enable trade of assets between different parties.
The different parties are known to me, and are not too many.
I record each transaction of an asset from one party to another in a database (sql server). I've stripped down database access as much as I can, and parties have to identify themselves by usernames and passwords to initiate transactions. Communication from web to api will of course be secure (https).
The Problem
These measures leaves me pretty confident that the stored transactions are authentic, but of course the parties of the transactions does not necessarily trust that I (or anyone else with sa password) haven't tampered with the data or created fake transactions.
My thinking
So I figure I need something to be able to prove the authenticity of such a transaction.
Maybe a signature from the party who is giving away their asset? A signature that I can store along with the signed transaction? In that case, the signer needs a private key and I think certificates is a way do this, right? I don't know of any way to access certificates installed on a computer from a web page though so the web page would have to launch a locally installed application to do the actual signing, because the locally installed application could access the certificate, and the signing party have trust in this application to sign the actual untampered-with transaction.
Is this a feasible solution?
How should certificates be distributed? I guess they should be issued from a CA that both I and the party trust?
I have a relatively successful app in the app store that allows people to view metrics on their iDevice using a JSON file hosted on the their server. The app has a simple settings screen in which you simply type the URL of your JSON file and the app takes care of visualising the data in the file. I use AFNetworking for this.
For example the URL might be: http://www.mylargecompany.com/factorykpi.json
Customers are now coming back to me and asking for the ability to connect to their servers more securely. Problem is there is a myriad of ways you can secure your server.
I need some advice. What kind of standard security features would I need to build into my app. I am confused by OAuth, HTTPS, etc.
I believe OAuth would mean the customers server would have to use it? Can you make a generic OAuth login screen in an app or do you need to know which web server you are connecting to authenticate.
Any advice on even the most basic of security measure would be very welcome!
Regards,
MonkeyBusiness
Security is really a very broad topic. There is no short answer. In any case, both web service and client app need to implement security mechanisms. I would recommend, you provide both the web service and client app.
You likely need some user login with a password, "server verifies user identity" and "client verifies server identity" using certificates. Then you utilize HTTPS which ensures to transport confident data in a secure way. The web service should be implemented with one of the well known web application frameworks since security is a scary business, and tricky. Implementing everything yourself, might end in a suboptimal insecure application.
You should now read more about the complex topic and come back when you have specific questions.
... most basic would be to use https, which would secure the transaction, but anybody accessing the same link would be able to access the same data. Thus you will need some kind of authentication, starting with a simple secret key passed as POST request, username and password and/or via certificates.
I am building a RESTful API in Python with the Pylons framework, serving it with Apache2 and mod_wsgi, and would like to connect it to an iPhone app. I have very little experience with HTTPS, SSL, and certificate authorities, and I am wondering how I would go about securing my API.
How do I make sure that the API is being served through HTTPS? Is it necessary to, as in this example, set up an SSL certificate? If I sign an SSL certificate through an authority not recognized by iOS (CACert.org, for example, and mainly because it is free), will that affect my app's ability to communicate with my server? How have others solved this problem of securing communications between a web-based RESTful API and iPhone apps?
Also, how does OAuth fit into all this?
This really depends on what you mean by "securing" your API.
Do you mean that you want to A) secure it so that unauthorized people are unable to access the API or B) do you mean that you want some level of encryption on the data passed back and forth between the client and server?
If the answer is B or both, then you will definitely need to look at getting an SSL certificate and installing it on the server. Most certificate authorities have guides on how to do this.
I'm not sure what you mean by "an authority not recognized by iOS" but you should still probably consider forking out the dough for a certificate from a recognized authority. It still wouldn't hurt to try CACert.org though if they are offering free certificates. I can't really see there being any problem in terms of the ability of communication between server and client being affected.
In terms of securing your API from unauthorized clients, you could check out OAuth (see http://oauth.net/). There are various Python libraries for OAuth. Check out https://github.com/simplegeo/python-oauth2 for example. The only thing you may want to consider is that there is a reasonable learning curve when it comes to implementing OAuth.
The second link above demonstrates a simple OAuth client and also has example code for a three-legged authentication process.
You can handle certificates programmatically in iOS. You can even use self-signed certificates as long as your code acknowledges the fingerprint. I can't remember the details off the top of my head, but I know you can use didReceiveAuthenticationChallenge to do this.
In the long run, it is simpler to just buy a cert (cacert.org won't do).
I'm building and iPhone App that will make requests to an application of mine running on a server. I'm using REST to build the server's application API. What is the best way for securing the requests from the iPhone to the server and viceversa. Is OAuth a good option? What would you recommend?
Thanks!
If it's a server you control, use a SSL/TLS connection for all communications between the phone and your server. Make sure that the phone app code checks the server's certificate (e.g., to check that it is a cert for your domain name, where your domain name is hardcoded into the source code). This will protect against eavesdropping, man-in-the-middle attacks, message forgery, and other attacks on the data while it is in transit.
There is not really any way to answer the question "what's best" without a lot more information on the security needs of your app.
In general, you should consider authentication, authorization, and transport.
Authentication could be as simple as username/password login. This could be simple authentication, OAuth, kerberos, etc. It is meant to identify the user. Authorization deals with which services are allowed to be accessed by which groups or individuals. You'd need a way to grant and maintain privileges. Finally, securing the transport typically means using encrypted services, such as HTTPS over SSL. This prevent data from being intercepted or altered during transport.
There are many other considerations to think about including how your protecting personally-identifiable information, encryption, etc., but again, there is no one-size-fits-all solution that could be recommended.
I'd like to make requests from an iphone app to a web service I've built. How can I verify that requests made to the web service come from my iphone app (or indeed any authorised source) and are not forged?
I have looked at basic auth over HTTPS but is baking credentials into an application secure?
This question isn't really iphone specific; I'd like to know how to protect and authenticate requests in general.
Authentication can be asserted by presenting something you know, something you have, something you are or a combination of the three.
The iPhone doesn't have retinal or fingerprint scanners, so there are no "something you are" options available.
Client certificates work well as a "something you have" token. Most smartcards work by signing a message with an embedded certificate. When a certificate is compromised, it can be put onto a Certificate Revocation List (CRL) referenced by the webservers. Obviously, you wouldn't want to put your app's embedded certificate in the CRL -- that would deny access to all your users. Instead, you'll want users to download individual certificates to their iPhone.
After that, it's a matter of monitoring for unusual behavior to find the bad actors and adding those certs to the CRL. Two dead giveaways would be clients who send too many requests at once or from too many different IPs in too short a time.
Login/password is a simple "something you know" token. Like certificates, login/password combinations can be compromised and similar monitoring can be set up to find inappropriate behavior. The difference is compromised accounts would be marked "blocked" rather than added to a CRL.
By requiring both a client certificate and a login/password you increase the amount of effort needed to compromise an account.
Of course, you must ensure only valid accounts are added to the database. If there is an automated way to create new accounts and corresponding client certificates, then that account creation server/process becomes the easiest way for bad actors to create viable, unauthorized accounts. Requiring a real person to sign-off on accounts removes the automation process, but means a disgruntled or corrupt employee could create invalid accounts. Requiring a second person to counter-sign the account makes it harder for a single person to be an inside threat.
In short, ensuring high integrity of the clients is a process that can be made arbitrarily complex and expensive. What tools and processes you decide to deploy as the authentication scheme has to be balanced by the value of what it is protecting.
In theory, if you want the connection to be secure, the best is to have the client sign their request using a certificate. There are multiple resources about this. Look for "client certificate" on Google.
This example from Sun is in Java, but the concept is similar whatever the language.
PS: obviously, this doesn't prevent you from using other authentication methods such as passwords, etc...
PPS: Keep in mind that if someone manages to extract the certificate from your application, you are screwed either way ;-). You can imagine a store providing an individual certificate to each app and invalidating the certificates that are compromised.