I'm using Titanium.App.Properties to store user highly confidential data. So is it safe to store values here. Is it possible jailbreak iPhone's to leak this values. Is this values encrypted or stored as plain text?
Thanks in Advance.
Here is an update to this old question:
From Titanium 3.X docs:
As of Release 3.2.0, any application properties defined in the tiapp.xml file are stored in the device's secure storage, making them read-only. Additionally, external access to these properties is now restricted. Other iOS applications cannot access these properties and native Android modules must use the Titanium module API TiApplication.getAppProperties method to access these properties.
If you need to change the values during runtime, initially create the property with these APIs rather than defining them in the tiapp.xml file.
Prior to Release 3.2.0, application properties defined in the tiapp.xml file could be overwritten by these APIs and accessed externally by other applications and modules.
So, the answer to the question is:
If using SDK version 3.2.0 and above; Titanium.App.Properties is secure enough to store sensitive app-related data:
For storing constant values (cannot be changed at run-time); use tiapp.xml file.
e.g. <property name="app.google.api.key" type="string">key_here</property>
To get and set values dynamically at run-time, use Titanium.App.Properties.
You can also use this module for securely storing and reading app or user related data.
See this example code that defines security levels of each
operation.
Titanium.App.Properties are stored in a simple .plist file. It is in a compressed (encoded) XML file. So not encrypted, but also not technically in plain text (although any .plist reader, including the Mac itself, can present it in plain text.
Source: http://developer.appcelerator.com/question/130050/titaniumappproperties-is-it-safe
Related
I am new to GWT, and facing one problem.
How we have .properties file for initial configuration at startup.
I want to create one in GWT App.
Also, GWT has client and server package.
I want to setup the configuration at client package because all configuration belongs to client side.
My actual need,
I have one textArea which takes up only fixed number of characters and length is defined in my properties file like below.
So I have to read a properties file for validation.
my.properties
smsConstraintEnabled=true
smsConstraintCharLimit=160
I found few link but all are talking about properties file regarding Locale, I don't have any need on Locale side but need simple key-value configuration.
I want this file to be loaded at startup or at Entry point itself and then I can use it at any client package classes for my validation.
Thanks in advance.
Use a Constants interface. It's built with I18N in mind but will work just as well in this case, where you provide the constant values for a single locale, the default one (therefore used for every locale you'll compile your app with).
That however means the file is read at compile-time, not runtime (i.e. you'll have to recompile your app each time you change the properties file).
If you want something more dynamic, then read the file on the server-side and pass the information to the client-side. Easiest, and with minimal overhead, is to use a dynamic host page. To read the values in your client code, then either use a Dictionary (and Integer.parseInt et al.) or use JSNI (possibly with an overlay type).
I am creating an application that will be distributed using the iOS Enterprise Program. I know I'll need to create a manifest file that will be used to download and install the application. What I want is to add some custom info within the manifest file and read this info in the installed application. Does anyone know if this is possible and how can I do that?
Thanks
If by 'manifest file' you mean the .plist defining the IPA url etc. then yes, you can add your own custom key/value pairs. It's just a standard plist format which you can edit like any other, and additional key/value pairs will be ignored by the Over The Air distribution mechanism.
If you want to read these values from the application itself, the app will have to download the .plist again itself and parse out the values.
Recently i've asked about the security implications of storing sensitive info in the xml string resources in Android: the answer? Heavy security implications, is really easy to get the contents of every xml file with a simple command line tool, so it is almost mandatory to have important info encrypted.
Now, how is it like in iOS? How secure it is to have a certain data in a plist or a .strings localizable file, in plain text, non encrypted?
Still not very secure.
There is nothing stopping a user from unzipping an application stored on their computer in iTunes and viewing the contents. Its very easy to do, even without a jail broken phone. Any strings resources, plist files etc will be immediately accessible.
Even hard coded string literals are visible in the compiled binary when one views it with the strings utility. And going a set further, using the nm utility one can see all your applications symbols, such as method names, constants, etc.
I would recommend against storing anything that could be considered sensitive in plain text.
You can access any file on a jailbroken iPhone, so you'll need to encrypt sensitive data.
If your app ships with a .plist file, then the end user can unzip the .ipa app file and see the .plist file and do whatever they want with it.
The exact same problems, a plist is a very common file for Mac OSX and iOS and it is just a XML file. Secure your sensitive data on ALL platforms!
I would like to add that apple does provide a way to securely store sensitive information in the Keychain.
In the application I'm working on, I'm generating a username and password and storing them in [NSUserDefaults standardUserDefaults]. I know there's some system-wide information you can retrieve from there; does that mean all the applications on the phone have access to everything in there? I'm currently prefixing the keys I'm using in there with some strings of characters related to my application name to avoid conflicting with other applications, but is this necessary? And if so, is there a better way to avoid such collisions?
You should also be storing usernames and passwords inside of the keychain and not in user defaults. Storing them in user defaults open them up to snooping when backing up the data to their Mac.
No. NSUserDefaults are not system wide. Name them whatever you like, you'll be fine. :)
NSUserDefaults uses the abstract concept of "search paths" to look for defaults values. Unless you customize it, the standard user defaults object will look in three places; the launch arguments, your application's preferences, and the system preferences (for example global localization options). You can also manually add identifiers for other search paths, if you wanted to share the same preferences between more than one application (I haven't tried this with the iPhone, so I'm not sure if it's available on Cocoa Touch or if you can only do this on OS X).
You could potentially have a conflict with one of the systemwide preferences, but since your application's search path is searched first it's never an issue.
I'm currently using *.plist files for my iPhone app to store information that is later read into strings as NSArray or NSDictionary equivalents. I will be updating these files periodically and downloading them to the application if a new version is found. I would like to use the <plist version="1.0"> string located in each *.plist file to make these comparisons since it won't interfere with the actual content of the plist file.
My question: is it possible to access this information and use it in the manner I describe, or is this version information describing the version of the *.plist protocol and not the actual file itself? For example, can I change this to: <plist version="1.1"> for a new version of the file, read this version info and update the file if newer? If this is possible, I haven't found a way to extract this information using the iPhone SDK (the comparison and update part will be easy).
I'm pretty sure you should'nt touch that. It's probably used by apple for future-compability (or future backwards compability, if you prefer). So that if/when they change the syntax of plists, old ones will still work.
Easiest would be to have the first entry contain the version number, or possible as a part of the file name. Or maybe even at a completetley different place, like in a database or as a part of a file structure on the server.