App Secure | URLSession | Authentication Challenge | NTLM | Security | Credentails

Yesterday, I have posted about How to response Authentication Challange but thoughts came in mind that if you are going with the first options Provide authentication credentials is it really secure and safe? how is client sharing the credentials with the server?

After lots of Google, I have found, how’s NTLM works and it’s pretty interesting to see that client don’t share the password with the server. here are the steps as follow.

Screen Shot 2017-10-12 at 1.06.51 PM.png

  1. The client makes the request to the server.
  2. The server needs to validate the user because there is no identity so server generates 16 bytes random number called as the challenge and sends it to the client.
  3. Client hash this challenge with the user’s password and return it back to the server that is called the response it also includes username as plain text and challenge sent to the client.
  4. The server sends everything to the domain controller and it uses the username to retrieve the hash of the user’s password from security account manager database and hash the challenge.
  5. Domain controller shares the response back to the server if they are identical then authentication is successful otherwise a failure.

So the interesting part is here that Network API doesn’t share the password with the server it means it very secure.

Thank you for reading.

Share your thoughts and feeback.

 

 

 

How to Respond to an Authentication Challenge | iOS

How to Respond to an Authentication Challenge

If a session requires authentication it creates authentication challenge

 URLSession:task:didReceiveChallenge:completionHandler: 

in order for the connection to continue, the delegate has three options.

  • Provide authentication credentials
  • Attempt to continue without credentails
  • Cancel the authentication request.

NSURLProtectionSpace will give all information about the authentication type and failure if any attempts failed earlier.

Providing Credentials

To attempt to authenticate, the application should create an NSURLCredential object with authentication information of the form expected by the server. You can determine the server’s authentication method by calling authenticationMethod on the protection space.

  • HTTP basic authentication (NSURLAuthenticationMethodHTTPBasic) requires a user name and password. P
  • HTTP digest authentication (NSURLAuthenticationMethodHTTPDigest), like basic authentication, requires a user name and password.withcredentialWithUser:password:persistence:.
  • Client certificate authentication (NSURLAuthenticationMethodClientCertificate) requires the system identity and all certificates needed to authenticate with the server. Create an NSURLCredential object.
  • Server trust authentication (NSURLAuthenticationMethodServerTrust) requires a trust provided by the protection space of the authentication challenge.

Continuing Without Credentials

If the delegate chooses not to provide a credential for the authentication challenge, it can attempt to continue without one.

NSURLSessionAuthChallengePerformDefaultHandling processes the request as though the delegate did not provide a delegate method to handle the challenge.

  • NSURLSessionAuthChallengeRejectProtectionSpace rejects the challenge. Depending on the authentication types allowed by the server’s response, the URL loading class may call this delegate method more than once, for additional protection spaces.

Canceling the Connection

The delegate may also choose to cancel the authentication challenge, by passing NSURLSessionAuthChallengeCancelAuthenticationChallenge to the provided completion handler block.

POV | Difference between ! and ? | In-Shorts Story

Whenever we write code in Swift we use optional because it beautiful way for handling null values as in Objective C its little different and difficult as well, one of the reason is, Objective C based on C, so there are legacy issues as well, but in Swift there is not legacy at all so for handling null value we have separate feature from the language itself that is called Optional (Optional chaining is a process for querying and calling properties, methods, and subscripts on an optional that might currently be nil).

Now the second question comes up in mind is, how does it work?

The idea is whenever you feel any value could be nil in future just make it as Optional simply and before using it first see, is it contains anything? if Yes than use it otherwise make the nessarary decision. In other words, we can say its something like you has a box and it may or may not contains something so before using it first unwrap and check.

How to create Optionals?

? and ! here is the answer. I also googled what is the correct difference and where to use what but only a few links were useful. Small answer is.

Use ? if the value can become nil in the future so that you test for this before using always (we have to use if let or guard statement).

Use ! if it really shouldn’t become nil in the future, but it needs to be nil initially like we do with IBOutlets always (Benefit is before using no need to unwrap using if let or guard statement). But it we use ! and the value is nil ready for the crash.

Thank you for reading.
Please share your comment it will help me to improve.

Happy Learning.

Dependency Injection | Swift | Quick Note

A short answer is, it’s scary terms for a very simple idea!!! See this lines of code.

class Engine {

}

class Car {
    let engine: Engine? = nil
    init() {
        self.engine = Engine()
    }
}

we are creating dependency internally but the object can be also received from outside with lots of benefits like the object become instantly testable, Testing becomes possible without any frameworks, No runtime effects, This makes the whole system more loosely coupled.

class Car {
    let engine: Engine? = nil
    init(engine: Engine) {
        self.engine = engine
    }
}

There are three common types of dependency injections.

Setter, Interface, Constructor based.

In iOS Constructor based is preferable one, it’s when dependency passed to the client in the initializer and don’t change during the whole client life and the biggest advantage of this type could be that it makes the violation of the single responsibility programming principle, if an object takes all dependencies in the initializer and if it has more than three parameters so it means refactoring is needed.

Thanks for reading!!!

Swift | UICollectionView | Dynamic Cell Width Using Auto Layout | No More Code | Quick Note

The story starts from here, today I was looking into the old codebase and found a bunch of lines of code for calculating the width of `UICollectionViewCell` then I realized is it really required and after Googling I found lots of people are writing code again.

In my scenario, it was breadcrumbs where I needed dynamic width so I removed whole code and here is what I did.

STEP: 1 Added `UILabel` with four constraints.

Screen Shot 2017-08-22 at 10.50.35 AM.png

STEP: 2 Created `UICollectionViewFlowLayout` using `UICollectionView` reference and set the estimated `CGSize`

Screen Shot 2017-08-22 at 11.02.20 AM.png

STEP: 3 set cell `UILabel` to `sizeToFit()`

cell.label.sizeToFit()

That’s All.
Thank you if you want to look into codebase, follow this GIT Link.

Swift | iOS 10 | Orientation | Quick Notes

When it comes to handling Orientation in iOS App Development, creates little confusion because with every release their minor changes. so let’s see who does it works with iOS 10.

First thing if you want to support all Orientations just enable it from here.

Screen Shot 2017-08-02 at 3.40.51 PM.png

Second, if the requirement is something like, need Orientation support only for few Controllers. make sure you have followed the first case and just this code snippet for enabling/disable it for each view.

override var shouldAutorotate: Bool {
    return true
}

its simple as its looking just return `true` if you want to support orientation for controller else return `false`. Next concern is if you are returning true then you have an option to specify the orientations as well just implement this code snippet.

override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
    return UIInterfaceOrientationMask.all
} 

Click `UIInterfaceOrientationMask` to see the options so just return whatever you want to use. Sounds good?

public struct UIInterfaceOrientationMask : OptionSet {
    public init(rawValue: UInt)
    public static var portrait: UIInterfaceOrientationMask { get }
    public static var landscapeLeft: UIInterfaceOrientationMask { get }
    public static var landscapeRight: UIInterfaceOrientationMask { get }
    public static var portraitUpsideDown: UIInterfaceOrientationMask { get }
    public static var landscape: UIInterfaceOrientationMask { get }
    public static var all: UIInterfaceOrientationMask { get }
    public static var allButUpsideDown: UIInterfaceOrientationMask { get }
}

Thank you for reading.

Make your iOS apps more secure with SSL pinning

SSL/Certificate pinning plays a very critical role in building highly secure mobile apps which users will be able to use even in countless insecure wireless network connections.

At a glance, Idea is the SSL(Secure Socket Layer) ensures the encrypted client-server communication over HTTPS. The encryption is based on PKI (Public Key Infrastructure) and a session key. The session key was introduced because encrypting and decrypting a public/private key uses a lot of processing time/power/space for sure it will slow down the process.

MIMT, Yes SSL Communication is very secure but the man-in-the-middle attack still poses an exact threat using ARP cache poisoning and DNS spoofing.

SSL/Certificate Pinning, ensure that the app communicates only with the designated server only and the prerequisites for SSL pinning is saving the target’s server SSL certificate within the app bundle.

SSL pinning is implemented within the

    func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void

and here are the steps we need to follow.

  • First read the server trust and server certificate.

let serverTrust = challenge.protectionSpace.serverTrust
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0

  • Now set the policies for server validation, previous failure count etc.

SecTrustSetPolicies(serverTrust, SecPolicyCreateSSL(true, (challenge.protectionSpace.host as CFString)))

  • Start policies validation, convert server certificate in Data and get the local certificate from bundle.

 let remoteCertificateData = SecCertificateCopyData(certificate)
 let pathToCert = Bundle.main.path(forResource: “certificate”, ofType: “cer”

At last compare your policies result and local certificate data with your server certificate data, if everything goes well complete the challange with credentail.

completionHandler(.UseCredential, credential)

Otherwise cancel the authentication and pass nil as credentails.

completionHandler(.CancelAuthenticationChallenge, nil)

Thank you reading, you can download the source code from GIT and also learn contribute about iOS Security.