I would like to encrypt a string with AES 256 on the iPhone but have not found much via google. What I am trying to do is post some data to a web site as part of a game I am creating, but I do not want the user to be able to cheat by seeing how it is posted because it is plain text. So I want to post one encrypted string to my php page (ala www.test.com/test.php?encrypted= etc...) and then the php script will decrypt it and do what it needs to if it is valid.
You can just use the CryptoHelper which is adopted by CyrptoExercise Sample Project
A much easier approach here would be to use an HTTPS POST, which would give you similar protections with far less code, though there are still difficulties for solving the problem you're attacking. The kind of solution you're describing generally requires some kind of shared secret, and it's very hard to protect code using a shared secret for long. You may find these posts helpful:
Machine ID for Mac
Store an encryption key in Keychain while application installation process
Obfuscating Cocoa
Still, HTTPS is probably a much better solution than AES here.
Check out this site: http://iphonedevelopment.blogspot.com/2009/02/strong-encryption-for-cocoa-cocoa-touch.html
Related
I have been looking for a way to protect my RESTful APIs. This appeared simple, but it seems to not be so simple. First off, I am writing an iOS app connecting to a Play Framework server. None of this has anything to do with Google, Facebook, Twitter, or LinkedIn (shocking I know). Oh, and my current plans do not require custom apps to use my APIs, its just my apps for the time being.
Basic Authentication
What appeared to be simple was a basic user/pass on a /auth method managing a cookie session. That may draw some groans as being too simple or weak but mostly it moved identity to a session key quickly verified. My initial setup was to expire the sessions every day, but that lead to the iOS app forcing a login daily proving to be an annoyance.
OAuth
I posted a question on an iOS board and received a blunt direction towards OAuth. My research of OAuth began but holy sh*t is that complicated and there does not seem to be any server side examples... just plenty of people complaining about how frustrating it is. All the client examples show connecting to Google, Facebook, Twitter, and LinkedIn. Oh Joy!
After watching Eran Hammer's rant about OAuth1 and OAuth2, it seemed fruitless to continue and his OZ idea (which looks really clean) is only at the early stages in node.js.
Question
So, my question to the broad StackOverflow community is... what do you do for securing your REST APIs?
I'd suggest to consider approach used by biggest players i.e. Amazon Web Services or Windows Azure - HMAC. Although it isn't comfortable in implementation, as you can see it's trusted technique.
The general idea is to sign the request's parts (i.e. headers) in the iOS with secret key and try to recalculate it on the Play app to verify that request is authentic and not manipulated. If it won't fail, you can be (almost) sure, that was sent from somebody, who uses valid secret key.
Take a look into Windows' document to get the concept (I think that for common task, you can use the less number of elements used for signing).
There is also other interesting post (based on AWS authentication) which describes whole process even better.
Edit
Of course you should realize that authentication in iOS and securing API requests are different things, even if you'll expire your session every 15 minutes, you can't be sure that somebody won't overhear it and then will be able to send a fake request from the outside. Signing every request should minimize the risk.
On the other hand, if you'll prepare clear rules for signing the requests and will write short doc (which I recommend even for yourself), you can deliver it to the other developer and he'll be able to implement it in (almost) any platform supporting SHA256, so you will have API ready for using from 3-rd party apps - if you'll decide to publish it in the future.
Since Play Framework is in Java, you could use Apache Shiro
I haven't used it yet.. (I am planning to though) So I don't know if it's the best option.
Just do something simple, send the authorization code / password in a custom header over HTTPS .
So the only problem with the Basic Authentication approach was that the user has to login every day? Why not offer the user an option to save his username/password on the device? That way he can choose between security and convenience.
I am using OpenTokSDK for iPhone (using it Natively)
I have made the code for calling but just there is one problem.:-
I have to statically Add the SessionID. But i want to generate the ID Dynamically.
How can I do this ?
Please help!
Thanks In Advance
Full disclosure: I am a developer for TokBox.
The only safe way to get session ID and token credentials to the device is by developing an application server that suits the specific needs of your app. We have a number of server-side SDKs available on GitHub (link) that will interface with the OpenTok server API to generate this data.
Note well the server-side SDK is enough to get your credentials generated, but not all devices will be on the same session, so things like user management and application workflows are all considerations that cannot be easily written to an open source library.
That said, we did try to make some of these examples more clear by writing code examples on our blog (link). You can relieve much of the overhead of writing your own application server (no doubt a daunting task, especially the first time around) by leveraging one of the third party signaling services available, like Parse and Pusher, to name two.
Wobbals is correct, and In addition to what Wabbals has mentioned, generating sessions/tokens is very simple, the sample code required for each server language (PHP, NodeJS, C#, Ruby) is located in OpenTok's Github page.
Furthermore, if you choose not to have server side code and use Parse to handle your back-end, there is a wonderful writeup about how to use Parse's cloud code module for OpenTok to generate sessions and tokens.
Good Luck!
I strongly felt that the tokbox tutorial was quite basic but had steeper learning curve. So I ended up wrote out my own app-cum-tutorial.
Though late, I felt compelled to post here:
How To write your first iPhone Video Chat App using parse and opentok(tokbox)
If I have a password variable that is used for remote SSL authentication, is it secure to store in the source code?
e.g.
NSString * password = #"password";
Are there better way?
Update: Sorry for confusion, I am not storing the user password, instead, I am storing a password that is used to call our own backend, all the app will use the same password.
My new answer:
Try not to use static passwords to access the back-end, period. What happens if somebody you don't want determines what that password is. Why not use usernames & passwords?
You can also consider using a public key or embedded certificate to allow only your app access to the back end servers.
My original answer:
Sounds like you want to get to know the Keychain.
Here's a tutorial that talks about it:
http://maniacdev.com/2011/07/tutorial-how-to-use-the-ios-keychain-to-store-names-and-passwords/
And here is a related question that talks about the security of Keychain under iOS.
You shouldn't have programs a store static password for all users, but instead have each user set up his/her account & password for authentication and then store that stuff in the keychain.
Any text contained within your application is easily extractable. There's no real way around this - using the strings tool, anyone can see any and all text content statically embedded into your app. However, there are some ways around this - notably, if you split up your string into several static strings and concatenate in the right order, it will be much more difficult to reverse engineer the password contained in your app.
I recommend you take a look at a similar question (How Safe is Information Contained within iPhone App Compiled Code), and specifically, my answer to that question, for a more in-depth explanation of what I mean. (Nimrod's comment on that question is also interesting.)
NO!
build your app. Go to the terminal and type strings and then drag your executable to terminal and press return... You'll see your secret password in plain text :)
You should store its hash.
I am reading several posts on this issue but is still not clear. I am developing an app that uses sha encryption (with commoncrypto) for exclusively authentication reasons. For what I understood I do not need the CCATS documentation in this case and therefore I can overcome this procedure and simply send my app to apple without any further requirement.
Specifically I send an xml file (over soap) with the password encrypted and the extra data (like username, ecc) in clear. Additionally I do not communicate over SSL protocol
Is it correct?
If you are only using CommonCrypto for your encryption functions you should not worry about this. You don't need the CCATS documentation, because it's already covered as part of iOS. It's generally accepted that any use of the built-in encryption functions does not require any disclosure - I don't believe Apple have ever officially published this as policy, but they certainly have communicated it to individual developers.
I'm writing an iPhone app that integrates with third party APIs. These APIs use OAuth (key/secret specific to my app not per user) in order to authenticate which app the request is being made in behalf of.
Is it secure (or how secure) is it to simply put the key/secret in code? Can this sort of data be reverse-engineered? Is there a better way to go about including this data in a project?
There is no place on the iPhone to hide data. A user with a jailbroken iPhone has more control over the device than any developer. If possible you should setup a web service such as a REST or SOAP service to take care of these OAuth transactions on behalf of the client.
As Rook said earlier, there is no way to hide your data in iPhone. But you can make hacker job so difficult. I just done a work around for the same issue.
Put oAuth key information in PLIST
Mannually I encrypt this PLIST by using AES key and I got encrypted "CIPHER TEXT"
Modify the AES key by appending characters in between with your own logic. Since it required at runtime to decrypt the plist
Add this modified key with plist "CIPHER TEXT" and store this value in New plist.
Remove old plist which has oAuth information
Now you have only one plist which has encrypted value with modified KEY
Advantage:
Hacking is so difficult since hacker don't have a proper cipher text in plist
To hack this code they should know to separate Modified AES key from Cipher text.
Thou they found Modified AES key, they don't have any clue about the appending algorithm, here i simple used EVEN position of the character, but you can't modify this and you can take 3rd or 4th position of the character. Which is actually will differ for each developer
for more information please visit below link;
https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication
I'd suggest looking into the Keychain services provided by Apple
http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html