Providing Personal Levels of Assurance (PLoA) with Adaptive, Multi-Factor, Multi-Modal, Risk based, 2-Way Banking Authentication and Authorization System (AMMR-BAAS). This proposal is addressing the need for a more robust, reliable, and effective method for Authentication and Authorization of Customer access to Banking services.
Present use case
Current methods in common use range from nothing more than a Username/Password to what is being called 2-factor authentication, combining the uname/passwd with an SMS or out of band phone factor. However, this type of multi-factor authentication is actually only sequential single factor providing little additional security or level of assurance, making it insufficient..
This is sometimes augmented by a site recognition function for the Customer to be sure they are actually at the Bank’s site and not a simulated site. This assures the user that the website is authentic, however, it provides no protection against unauthorized access. These attempts to increase Assurance degrade the user experience by making it more onerous and offering little value for the individual user/customer. History is full of such attempts failing because “it is too complicated” and users won’t pay that price. Banks are anxious to find a better way.
Since most people use video conferencing applications (Skype, Google Hangouts, etc.), they are equipped with speakers, microphone, and camera, even on their desktop machines. Laptops and mobile devices are all so equipped. Laptops are also sometimes equipped with fingerprint reader/scanners. These present available sensors for biometric based authentication systems that can be combined to offer a risk adaptive security solution.
Proposed Use case
Therefore, the proposed AMMR-BAAS client application will be voice activated and, when launched, will capture a facial image, including discriminating between a live person and a still image (spoofing). The user will speak to the app, telling it what s/he wants to do. Together with the voice launch, this will provide sufficient voiceprint data for a matching process. The user’s device has been enrolled as well so we now have 3-factors for identification and authentication. The Bank sends the client an encrypted identifier to validate to the user that they are, indeed, connecting to the Bank. The client will then pass the authentication factors to the Service Broker for processing.
Once the user is authenticated, s/he is allowed access to the banking system and may perform some transactions. However, if s/he attempts to move a significant amount of money to an external account. The BAAS requests additional identification for approval of the transaction and calls the customer on the customer’s smartphone. When the customer answers, another image and voiceprint is captured and processed and the fact that the correct customer answered the enrolled device is added to the authentication. The transaction is approved.
The customer closes her browser without logging out and an attacker steals the session. He attempts to transfer all the money in the account to an offshore bank. The BAAS takes a new image, asks the intruder to speak the desired transaction (capturing voiceprint), runs it through the Authorization engine, captures as much information about the intruder as possible, and transfers the session to a honeypot. The BAAS alerts Bank Security and forwards all information, including the session captured in the honeypot. Here the honeypot acts as a document of all of the data that we capture during the session, which could be used to identify the attacker.