The 2FA process, first we need to pair the app on the device with the User Id. So let's look at the process that does this.
The aim here is to make the mobile device as anonymous as possible and by that I mean there is nothing on it that will expose the first factor credentials.
- When the app installs it is preconfigured with the server's address
- The app requests a new DEVID from the server
- The server creates a Unique ID and stores it in a session variable
- The server then returns the DEVID to the device which stores it in it's own config
- The app on receipt prompts the user to go to a URL on their PC and get a passcode
- The user goes to the URL on a separate device usually a PC and Logs on using their UserID and Password.
- The server generates a 9 digit pass code saves it in the User Record table
- The User enters the 9 digit passcode in the prompt on the phone
- The app sends the 9 digit code to the server
- The server looks for the 9 digit code in the User table
- The server then sends a request for more information from the device.
- The device responds with DEVID, phone number and IMEI number
- The server then stores this information against the user in the back end DB
- All that is on the app is the DEVID
When the user's phone is online the app will register it's presence by sending a request to the server saying "I am here and I am online".
So when a user Signs-In and the server decides that 2FA is required (See last post for the logic used to decided this) the following happens:
- The server looks up the DEVID associated with the user (who has passed the first factor validation) If there is no DEVID the Sign-In Attempt fails
- The server creates a Transaction ID and stores this with the DEVID in a DB table with a status of WAITING
- The server sends the Transaction ID back to the browser and the browser starts a timer bases AJAX call to poll the server using the Transaction ID to see if the status changes
- Lastly the server pushes an message to the DEVID and the app generates a prompt for the user where they must click OK or CANCEL to continue.
- If the app returns the user's response to the server and the response is stored in the Transaction DB as OK or CANCEL. If the request times out with not response then the status on the DB is set to FAILED.
- The user's browser has been polling the server looking at the Transaction Table and notes the transaction change. If it changes to OK then the SAML token is constructed and is sent to the Smartcloud server. Any other change results in an error being displayed on the users browser.
You will note that no information about the phone is sent or stored in the browser and no information about the browser or user is sent to the phone. The connection is conducted through the server.
YIPPEEEEE! I hear you say you have 2FA up and running.
I know for most of us Geeks we are never far from our mobile devices, we keep them close and do the "WKP" check at least every 5 minutes (WPK== Wallet,Keys,Phone). Users don't they forget their phones, they drop them into toilets, sinks, swimming pools, jacuzzi (with or without buxom ladies) ,bend them, break them, put them in the mircowave (Honestly this happened, to and i quote "Dry it out after I dropped it in a pint of beer" ) , get them stolen ("She seemed like such a nice lady in the bar")... and you can be rest assured that this calamity will occur just when they are expecting an email that they really really really need to read and reply to or "ALL HELL WILL BREAK LOOSE!". I am sure you know what I mean.
Given that we all know what eejits users are we need to give them an alternate method of achieving Sign-In on those occasions when they for whatever reason find themselves without their paired devices and these alternatives I will expand on in the next post.
No comments:
Post a Comment