How do we maintain the data security in iPhone apps. For instance, a custom app for a bank needs more security in terms of:
1. Data in transmission
2. Data in rest (Data inside iPhone)
What are the potential steps one can take to ensure the integrity and security of data? What support iPhone SDK provides to achieve this? How do we encrypt/decrypt the payloads? Save the data in encrypted format locally and how do we protect this from potential threat of decryption by unauthentic user?
It's a big topic but there's a great, free video on this subject from Apple's 2010 WWDC.
http://developer.apple.com/videos/wwdc/2010/ (sign in with a developer account)
Session 209, "Securing Application Data"
Also useful: Session 204, "Creating Secure Applications"
For the wire use SSL to a server that uses oauth or some similar authentication mechanism.
For local data use the keychain ( http://developer.apple.com/library/ios/#documentation/Security/Reference/keychainservices/Reference/reference.html and http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html)
Related
We have a live mobile application supporting registering with the user's mobile number.
We send OTP upon each register request and now we have hundreds of spam requests costing a lot of money due to the SMS service fee.
Rate limiting on Ip is applied.
Rate limiting on device id is also applied.
The register request is secured by adding a signature to the header using the HMAC SHA-256 algorithm, the key used to generate the signature stored in mobile code.
But it turns out that this is not enough to secure the process.
Is there any other practice we should do to solve the spam issue?
We are using Flutter for the mobile app
Your Problem
We have a live mobile application supporting registering with the user's mobile number. We send OTP upon each register request and now we have hundreds of spam requests costing a lot of money due to the SMS service fee.
Registering with the mobile phone number to deter spam isn't enough because a lot of services exist in the internet to provide anyone with free mobile phone numbers, that are often used to workaround registrations or any other services that require you to provide a number.
Rate limiting on Ip is applied.
Malicious users can rotate their IP address when they use a script (bot) or run your app in an emulator. Also IP addresses in mobile are very dynamic, its not like in residential broadband where they stay stable for long periods.
Rate limiting on device id is also applied.
The malicious user will rotate the device id when using a bot, an emulator or a rooted device.
Reverse Engineering
The register request is secured by adding a signature to the header using the HMAC SHA-256 algorithm, the key used to generate the signature stored in mobile code.
The malicious user will reverse engineer you mobile app statically to see how the HMAC signature is done and then replicate it on its script. In a series of articles around Mobile API Security I wrote an article about statically reverse engineering an app, while in the context of extracting an API Key the principles remain to extract the logic for the HMAC signature. You can learn how to it by yourself on your own app by applying the same basic technics I used on the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
The malicious user may also reverse engineer dynamically your app to understand how it communicates with your API server in order to do exactly the same on its bot.
This is usually done with a MitM attack on a device that the malicious user controls and a lot of open-source tools exist to help with the task, being the most known ones mitmproxy and Frida. Turns out that I also wrote an article on how to use this tools, not to extract the HMAC signature, but to bypass certificate pinning, but the basic mechanics to perform the dynamic analysis are the same, therefore I invite you to try this techniques against your own app. Learn the basics of MitM attack with Frida and mitmproxy on the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to disable certificate pinning and in the process you will also learn how to create an Android emulator with a writable system to allow for adding the custom certificate authority for the proxy server into the Android operating system trust store. This will allow us to bypass certificate pinning and intercept the requests between the mobile and its backend with a MitM attack.
The Difference Between WHO and WHAT is Accessing the API Server
But it turns out that this is not enough to secure the process.
No, its not enough because its not that hard to bypass with the several techniques I shown above.
In order for you to improve your security posture when developing an application you first need to understand the difference between who and what is doing the request to the API server.
In the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
When you grasp this idea and it's ingrained in your mindset, then you will look into mobile API security with another perspective and be able to see attack surfaces that you never though they existed before.
Possible Solutions
Security must be always seen as a layered approach, where you add as many layers as needed to deter the opponent from even trying to break them, or if in the case they try they will need a lot of resources, knowledge and time. This not new to software development, its being done for centuries, like in the medieval castles and prisons.
Is there any other practice we should do to solve the spam issue?
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
From this answer the Mobile App Attestation would be the most suitable for you to employ in order to give a very high degree of confidence to your API backend that the request is indeed from what it expects, a genuine and unmodified version of your mobile app, not from a bot, an emulator, a jail broken device or whatever other technique being used by the malicious user.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
I am just exploring on Vidyo IO platform for enabling video conferencing capabilities on top of one web application. I am just concerned about the below points and trying to get answers for the same.
Can anyone please help me with the details for the below points if you are aware of them?
Can we add/remove the participants from the video conference.
Can we just have an audio call.
Are the conference calls carried in the encrypted mode.
Are there any chances like generated API token can be stolen by any hackers and join into the conference call.
Thanks
Can we add/remove the participants from the video conference.
Yes. This kind of "moderation" may be achieved via client SDK only as well as via Vidyo backend APIs.
Can we just have an audio call.
Yes. On your application level you should just not select any local camera device (in Visyo SDK language - .SelectLocalCamera(null)).
Are the conference calls carried in the encrypted mode.
Yes.
Are there any chances like generated API token can be stolen by any hackers and join into the conference call.
Token is being generated based on ApplicationID and DeveloperKey that are tied to your personal account. If you don't expose this information, Token will not be compromised.
I'm currently working on an FTP client as a packaged Chrome App.
Is safe to store user credentials for different FTP servers using chrome.storage.*?
According to the docs:
Confidential user information should not be stored! The storage area isn't encrypted.
Don't store sensitive information using the chrome.storage.* APIs. See this question for more information.
I've uploaded and encoded several videos to windows Azure Media services. How can I provide secure streaming access to subscribers logged into my MVC 4 web site hosted as an Azure service? I basically don't want them to be able to watch a video if they are not signed in?
(I've been reading about Azure Media services and I can't find anything and that usually means I'm missing the obvious!?)
Now you could use AES or PlayReady content protection with Azure Media Services to encrypt your file over the wire. We provide token authentication on top of the key delivery, which ensure only your authorized user could get the content.
For more information, please read my blog post here: http://azure.microsoft.com/blog/2014/09/10/announcing-public-availability-of-azure-media-services-content-protection-services/
There are a couple of options for you. Currently you can encrypt the video using PlayReady DRM and then use a third party provider such as BuyDRM or EzDRM to handle authentication and DRM license delivery. EzDRM is currently available for purchase via the Azure store. This will provide you the highest degree of protection for your videos. Long term we are looking into more light weight approaches for authentication and video content protection for the cases where protection provided by DRM is not needed. We will post updates to http://social.msdn.microsoft.com/Forums/en-US/MediaServices/ when new capabilities are available in Azure Media Services.
I'm developing an iPhone app that lets users upload photos to a Google App Engine backend written in Python.
Data is transferred between the device and server via HTTP POST and GET. What is the simplest, most secure way to ensure only iPhones with my app can get data? Also, I don't want the user to enter in credentials, it should be invisible to her.
I could embed a key in the device and send that with every request which the server would check against. But a malicious user could potentially decompile the app and obtain the key. Any suggestions?
With your requirement that the user not enter any form of password, your options are severely limited. As you note, any shared secret key in the app can be pulled out by someone via binary extraction etc. -- in effect, you can't stop a really dedicated cracker finding out the secret and then just submitting that to the server.
There are approaches that are not watertight, but which might make it harder for wholesale abuse of your service. One example might be to release updates for your app every month (or two weeks, or whatever) that contain a new shared secret. Then obviously your web service has to expect the new shared secret, as well as accepting the exising secret, for each time period.
If your data is very sensitive, you might want to stop eavesdropping by using HTTPS; but as Nick says, if you use HTTPS for anything except authentication, you have extra hoops to jump through at App submission time.
Whenever you have a key stored on a device or in software that is accessible by someone it is subject to attack. iOS's keychain is generally a helpful way to store things you want to secure. However, it is still subject to attack. As with all security you need come up with a model that is appropriate for your application.
Also note that there are encryption export restrictions that you should familiarize yourself with if you be intending to use encryption for more than authorization.