Two Factor Authentication And Smartcloud (Part 2)

Following on from the last post we had a idea for a solution to the problem of attaching two factory authentication (2FA) to Smartcloud, now what we needed was a more detailed "story" that would define the Sign-In Process we would use.

The first factor

The first factor is "something you know" which for us like nearly every application is the combination of User ID and Password. Smartcloud requires the remote IdP to pass the validated User ID but not the password in the SAML token and this User ID must be the user's email address as it is provisioned in the Smartcloud service.

The password needs to be strong, at least following the 8x4 rule.
8 Characters long and the characters should be a mixture of 4 types

1. Lower case letters
2. Upper case letters
3. Numbers
4. Special Characters

Any system would have to enforce this minimum policy.

Having a complex password alone does not protect the user's account, Phishing, keyloggers, man-in-the-middle attacks, having someone ask "What's you password?" not to mention the unfortunate habit of saving your Sign-In details in your browser means there is more than a small chance that an account's first factor will be compromised at some time.

The second factor

This is something you have, mitigates against this risk of the first factor being compromised. There are several types of second factor. Dongles that contain PKI Signatures, Biometric Scans and apps that run on a separate device usually a mobile phone or tablet.

USB Dongles are possibly the most secure but unless you have well trained users who do not loose them, do not leave them in the PC and do not figure out a way to save an episode of The Big Bang to it. There is also a cost involved providing everyone in the organisation with the dongle and the PKI certificates.

Biometrics are now becoming popular with fingerprint scan and eye scans. However this is even more expensive than the USB Dongles as not all hardware comes with a biometric reader and older PCs may not support peripheral devices.

Mobile Apps are the easiest way to get a second factor. The app gets a "pushed" request  from the IdP, presents the user with a message they must acknowledge and this mobile app acts as the thing you have. While possible it is unlikely both the phone and the PC will be stolen and if one is stolen the other is useless without the other.

Needless to say the app must NOT contain either the User ID or the Password, incase it is stolen.

The Sign-In Process

We thought about this long and hard and the process goes something like this

1. The user Signs-In
2. The user id and password are validated and the process exits if invalid
3. Is the user id "active" if not exit the process
   This allows the admin to flag a user as ACTIVE or DELETED thus stopping access selectively
4. Get the IP address from the posted header is it black listed? If Yes Exit
   This allows us to blacklist known "bad" IP locations.
5. Get the IP address again is it whitelisted? If Yes send the SAML token with no 2FA
   This allows us to whitelist internal networks as "Safe" and therefore not requiring 2FA
6. What sort of 2FA PROFILE does the user have?
   This is another special user attribute which can be:
   ALWAYS - The user is ALWAYS 2FAed and 2FA begins now
   NEVER - The user is NEVER 2FAed and the SAML TOKEN is sent now
   NORMAL - The Process continues
   This gives the admin the flexibility to force (or not) 2FA on a user.
7.  What browser/pc is the user trying to access from?
   I will be covering this in some depth in a later post under "Fingerprinting"
   I can say it does NOT contain cookies!
8. If the user has a NORMAL 2FA profile the last time they were 2FAed is tested and if it is greater than 7 days 2FA is requested if less than then the SAML TOKEN is sent.
   
   And that is basically what we coded for.

In the next post I will look at the 2FA process in some detail. I bet you can't wait.