Documentation link mentioned in the video are as follows: Encrypting your app's file: developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files Apple on jailbroken device: support.apple.com/en-us/HT201954 OWASP guideline on jail broken device: owasp.org/www-project-mobile-top-10/2016-risks/m2-insecure-data-storage Implementing face id and touch id in your app: developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id Keychain dumper: github.com/ptoomey3/Keychain-Dumper SSL kill switch 2: github.com/nabla-c0d3/ssl-kill-switch2 Core data is encrypted by default from iOS 5 onwards: developer.apple.com/library/archive/releasenotes/General/WhatsNewIniOS/Articles/iOS5.html#//apple_ref/doc/uid/TP30915195-SW1 SSL pinning code examples: Configure server certificates: developer.apple.com/news/?id=g9ejcf8y Implementing ssl pinning: www.kodeco.com/1484288-preventing-man-in-the-middle-attacks-in-ios-with-ssl-pinning Store private keys in Secure Enclave: developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave
Is it possible to check whether the app is running on jail broken or non jail broken devices. If app is running on jail broken devices what security measures we should take apart from SSL pinning and encrption of data. As i saw the video ssl pinning also breaken by jail broken devices
I've been following your content since the beginning, and I must say, you truly understand what developers need. Very few content creators grasp this as well as you do. Your way of explaining things is exceptional, and the way you configure your content-whether it's the voice, presentation, diagrams, audio, or the level of explanation-is consistently top-notch. This level of quality is rarely found elsewhere. I appreciate seeing your organic growth and the dedication you put into your work. However, it's been a while since you last published a video. I hope everything is well with you. I understand that staying consistent with publishing content can be a challenge, but I encourage you to keep it up. Your work is invaluable, and I truly want to see you shine. I also want to mention that I love your Hindi videos and don't see any issue with them, but if you make the same content in English, it will be available to a global audience. I believe you have the potential to rank among the top iOS content creators in the world.
@@CodeCat15 Thanks Ravi for your reply. Today these things are being asked in almost every company's interview, so please make a detailed video on these topics as soon as possible.🙃
When we create an ipa, Xcode obfuscates the app, and if the hacker is able to reverse engineer it then apple needs to strengthen its process than us having to do something about it. However swift code is hard to reverse engineer than objective c so it’s safe to say that objective c was more prone to such attacks than swift You can take a look at SwiftShield for more protection for RE github.com/rockbruno/swiftshield
@CodeCat15 I think there's one concept more concept, public key: In SSL pinning, instead of pinning the entire certificate, you can pin just the public key. This way, even if the certificate expires and is renewed (with the same public key), your pinning still works. However, you still need to be mindful of certificate expiration and renewal in your general SSL management. but thanks for your video, It was really insightful! :D
I made a spelling mistake there that's on me, it's CORS stands for Cross-Origin Resource Sharing. its a security mechanism implemented in web browsers that controls how web applications on different domains can interact with each other.
I have one question, as you shared CoreData by default implements security in disk.. that means... shouldn't we encrypt data just before storing it ? @CodeCat
Encrypt if and only if your database has user sensitive information, do not force add encryption just for the peace of mind. Better not to store any user sensitive information in the database at all to begin with. Having said that, as per the docs of apple, on a non-jail broken device where we have apple security layer it seems that core data does encrypt the user data. One thing you can do is use the complete file protection level with core data than default to add more secure layer You may also add your own encryption but as explained in the db encryption chapter of the video, you may face latency issues since the data needs to be encrypted/decrypted for read write operations.
It depends on what encryption strategies the api is using and expecting, depending on that you can talk with your security team and implement the same, also include penetration testers to test this implementation. It's a wide topic because the security impelmentation varies, but surely I can spin something up to demonstrate this.
Awesome video Ravi. Just to add, SSL Public Pinning are also being used these days than certificate pinning, just to avoid expiration of certficates. Can you please elaborate more on Apple CryptoKit? Best wishes 🙏
Thank you for your insightful comment! SSL Public Pinning is indeed gaining popularity for avoiding certificate expiration issues. Apple CryptoKit is a powerful framework used in iOS development for cryptographic operations. It offers secure and efficient ways to handle encryption, decryption, and other cryptographic tasks, ensuring data protection and privacy in apps. I'll consider creating a video that elaborates on its features and usage. Stay tuned for more content!
Couple of ways to do this 1. Aap aapke code mai ek file mai store kar sakte ho, aur us file ko gitignore mai add kar sakte ho, private key kabhi commit nahi hogi server pe 2. Point 1 mai flaws hai coz koi bhi private key ko read kar sakta hai, to you can use Secure Enclave that’s provided by iOS and is encrypted developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave Again the issue with point 2 is that it uses keychain and you need to maintain the private key in plan text format to compare 3. You can use sqlcipher for your private keys 4. There’s another approach which am aware but have not used which is using cocoapod-keys In some cases I have used approach 1 and 2, in approach 1 we change the keys in every major release it’s a part of our security checklist. Hope it helps.
@@CodeCat15 Thank you for the suggestions. On that note aap Jail Break bhi detect karte ho? I read multiple articles and no one described full proof method to make your application fully secure. We can make hacker life difficult but not impossible. Aap ka kya kahana hai is bare m?
That statement is correct; aur isliye maine video mai baar baar yahi kaha hai ki agar aap sensitive information app pe store karne se avoid kar sakte ho, to fir hacker k pass koi sensitive info nahi jayegi it goes to the saying The best secret is having no secret at all. Lekin agar aap kuch sensitive info store kar rahe ho to usko encrypt zaroor karna coz is information ko decrypt karne k liye private key chaiye hogi jo sirf aapke pass hogi na ki hacker k pass. But as I said, don’t store any sensitive information in the app to begin with
Hi Ravi, We can implement SSL pinning using the public key hashes present in response headers, we should hard code the public key hashes received in response headers in app code and compare the hash of the certificate on runtime with these array of hashes. This will work without changing the certificate for every 90days. We implemented a year ago working fine without issues, because if the certificate changes the next certificate hash will be in public key hashes.
By public key hashes you mean the public keys that's send from the server during the handshake process? And you have a set of stored hashes that match this public key in your app bundle? Did I get that correct? Also are you speaking of public key pinning? or just using the public key hashes because in public key pinning we have to extract the public key from the certificate than having hardcoded hash, please let me know If you are just using the hashes then here's my opinion (Note: I have not used the said approach by you in any of my apps as I like to pin certificate as it does more to validate the authenticity of the server) These public keys are freely available to anyone even the hackers. If public key hash changes and the hard coded hash is not present in your app code then your app will fail to respond any api requests, and it's very common for the public keys to change Example: 1. If someone resets the server key. 2. If there's a change in how the public key generation is done and now you have a mismatch in the stored hash on your app 3. The keys could also change if the ssh gets compromised and in this case a new public key needs to be formed which is different from the old ones although this may work in your case, but it's prone to failure if the key hash changes. If the key hash is the only thing that you are checking, then what would happen if a hacker gain access to the freely available public key and intercept the message? because all your app would do is just check the public key hash and say yeah this is good to go and starts communicating with the bad server (try testing this use case with help of a penetration tester) It's the certificate that's installed in the bundle that does a in-depth check and validates the signature and avoids communicating with the bad server Such public key based hashes are done to avoid having to install the certificate every year, but I am a little spectical of this approach to just rely on the public hash which can change and in your case if the hacker gets public key and impersonates the good server. In the video I didn't suggest to change the certificate every 90 days it was just to add a reminder 90 days before the certificate expires, I think what you ment here was the free certificates which encrypt for only 90 days but if you have paid certificates then you can get the validity for 1 year or 2 year.
@@CodeCat15 Hi Ravi, What I meant is we hard code the 4 public key hashes from the response and for the very first API call we get the server certificate and its hash dynamically and check it is one of the hardcoded public hashes. We used it for our macOS product which relies on Okta IDP, okta changes the certificate every year. If the certificate changed the new cert hash will be within the hardcoded public hashes. This way we avoid releasing the build whenever the certificate changes and we release the build for every quarter. What you suggest is also a good approach. I'm just saying my approach may be helpful for someone.
I am glad that this video was helpful, i will drop videos one at a time on the mentioned topics that were discussed in the video along with some good practices.
Very useful content ... Super cool ☺ Also i have question, Apple already have keychain wrapper and cryptokit to encrypt sensitive data then, Why SSL pining is needed to encrypt and validation ?
With APIs you are sending information outside the iOS ecosystem and hence SSL pinning is needed to be implemented to ensure you are talking with the good server and not with an imposter Apple has those keychain wrappers but don’t assume that your app will run on only non-jail broken devices You must encrypt the data first and then save it in the keychain, and use a different encryption than what is used by apple for keychain which I think is AES
One of the things I have emphasized in the video is to avoid storing any kind of sensitive information in the app, avoid bundling any kind of API secret keys etc with your app that's risky business. You can start with something simple like detecting if your app is running on a jailbroken device and prevent the app from running on jailbroken devices and use code obfuscation. Code obfuscation is the process of transforming the source code in a way that makes it more difficult for reverse engineers to understand, decompile, or modify. You can use several paid third-party tools to do so, please get them verified by company security architects because different companies have different guidelines for data security. Here are some of the tools that I know of 1. SwiftShield 2. ProGuard 3. Dotfuscator (this is for xamarin projects not native swift but worth mentioning) 4. GuardSquare Remember that no method is foolproof, and determined attackers may still find ways to reverse engineer an app. Therefore, combining multiple protection techniques offers the best defense against reverse engineering attempts.
Before watching this video i don't know about security and y for security But you make very easily to understand what needs to be secured and why also the ways thaks alot bro 😊
