VPCSML MULTILEVEL AUTHENTICATION SYSTEM

 VPCSML is a significant improvement on traditional authentication because the user can't be tricked into revealing their password and the user does not have to remember long or complex passwords as our design automatically creates the underlying complexity without the user having to worry about it. Our design prevents users from being inconvenienced by hacking lockouts. If a user loses their device or it is stolen or broken or becomes obsolete they will not be locked out of their account because our authentication is device independent. Our authentication improves the customer experience because registration is simple with pleasant pictures and there is no complicated software, hardware or registration procedures that the user has to deal with. Our authentication gives you a competitive advantage because it gives the user confidence they are dealing with an authorised resource for your network.

Find out more

This diagram illustrates the key differenc​es between VPCSML* and Traditional Authentication.​

The case for multilevel authentication

  

Methodology


Armorlog VPCSML is multilevel authentication and guards against the main attacks on 1st factor in authentication (rainbow tables, brute force, keylogging [malware], phishing, denial of service, forced lockouts).


The reason current first factor authentication can be compromised is because it uses standard interpretation tables (ascii or unicode [with or without language variant]). 


These are widely known common number-sets.


In order to have a secure password system the system needs to use a number-set to which access is restricted.


Armorlog VPCSML achieves this using a matrix run on a SQL database and allows for each & every user to have their own personal keyboard with their own personal set of credentials eliminating password reuse and the need for password complexity.


This has the added benefit of making the 1st factor authentication device independent which allows the network owner full control and eliminates the risk of compromised user devices.


2 Factor authentication involves two separate sets of factors used in combination to authenticate for authorisation on networks.


1st Factor Authentication is what you know.


2nd Factor Authentication is what you have (an ip address, device, etc) or what you are (face image, finger print etc). 


These factors can be interchangeable  in the order they are presented when authenticating to access a resource (logging in or logging on or opening a door or accessing a car etc).


2nd Factor Authentication cannot be relied upon on its own to allow access to resources because the information is in the public domain and can be spoofed (impersonated).


When 2 factor authentication is used it needs to allow for when the 2nd factor fails (eg when mobile phone is spoofed, lost, stolen, hacked, broken, corrupted or obsolete).


While not yet widely understood it is commonly known within security circles that 2nd factor can also be phished and broad scale multifactor phishing attacks have been successfully implemented to perpetrate frauds.


USB tokens are being advocated as a solution however these are a 2nd factor device and still subject to fall back weakness and are subject to all of the same pitfalls as all other forms of device dependent authentication, they are expensive, they can be spoofed, they are lost, stolen broken become corrupt or obsolete. 


As a significant proportion of fraud is actually internal or by a person closely situated to the victim if an attacker gets control of the device they can exploit it. 


Consequently for validation of transactions a device reliant approach is not a sufficient solution because validation by device cannot be construed as consent as the device may not be controlled by the person from whom consent is required.


This is important with regard to legal consideration. It will be difficult to argue on the civil test ie on the balance of probabilities that the user consented given device compromises  are now so widespread. Trying to rely on device authentication to satisfy the criminal test, ie beyond a reasonable doubt, is even more problematic as most fraud is criminal in nature it is this test that is required to be satisfied to prove a case for compliance and enforcement requirements to protect the public.


Some networks do not allow the second factor to be changed eg some will not allow change of phone so once you lose access to your phone number (hijacked, credit dispute etc.) you are locked out of your account, a very bad customer experience. 


So really not allowing changes on the second factor is not a solution and most commercially based organisations allow fall back to username password in order to be able to, quite rightly, maintain customer relationships.


So essentially a networks last resort against attack remains the 1st factor (something you know).


Some networks implement security questions to try to add a layer of protection but it is commonly known within the security industry that these are trivial to circumvent. They can be keylogged, guessed, phished or vished. 


However what is a more insidious and perverse outcome of security questions and the use of personal information in authentication processes is that rather increase protection for the user it has the opposite effect and increases the risk of identity theft. 


This is because this is in fact a 2nd factor it is something you are, not something you know, even though it is confused to be something you know. 


The user may well know it but so do many others and it is trivial for attackers to simply obtain this information through a phishing or vishing attack. 


That is of course if they haven't already accessed the information from widely accessible databases of users personal information that has been harvested of many decades in a systemic erosion of user privacy that has ironically occurred in well meaning processes designed to try to protect user privacy.


Examples of widely held access to such information are birth registers, marriage registers, electoral rolls etc. Personal information can simply no longer be relied on as a secure basis for  authentication and organisations that continue to use it are at risk of being subjected to legal proceedings for exposing individuals to breaches of privacy.


Capture is also used to try to protect the 1st factor. It is claimed that capture stops brute force attacks this is not entirely correct, capture will delay brute force attacks however it will not stop them.


Further in achieving this limited protection capture unfairly penalises the user through no fault on their part and makes their login unnecessarily complex for no added benefit from their perspective and reduced benefit to the network in actuality.


The way to stop brute force attacks is by lockout. Lockout is now required by law in some jurisdictions. 


It is only a matter of time before lockouts will become more widely required as regulators struggle to try to protect the public and indeed many corporations and institutions have implemented lockouts in any case because of the increasing incursions being made into their networks.


However lockout unfairly penalises the users. Through no fault on their part users can be locked out of their account by a malicious or benign hacking attack. 


Capture will not stop a malicious or benign in person attack to lockout. Armorlog Multilevel authentication (VPCSML) will stop malicious lockout attempts or benign lockouts (eg because a user is using the wrong credentials for the wrong account).


Multilevel authentication is as it suggests two or more levels of authentication within the same programming routine. 


It will work in conjunction with 2 factor authentication but it (2fa) is not necessary to gain the benefits protection against the most common forms of attack because as discussed above 2 factor authentication can be defeated by utilising fall back procedures networks use to resolve failure or compromise of the 2nd factor (however see our proposed implementation to overcome this weakness also by applying VPCSML to email as a second factor).


Multilevel authentication has a time out on the first level to delay brute force attacks to such an extent it will take several lifetimes to determine the combination of keys used in a set of credentials on the first level to get to the second and subsequent levels. 


Multilevel authentication by passes the existing interpretation tables (ascii or Unicode or a language variant thereof) to prevent the most common forms of attacks.


VPCSML also allows for a far greater number of permutations to increase the difficult of decoding credentials. 


VPCSML allows for unique keysets and credentials at a user level so the user can recognise an authorised resource or an authorised call for credentials for validation for example this will protect against payment fraud where VPCSML is implemented on the Access Control Server used to validate payment transactions. 


At present the VPCSML solution is still the only solution that achieves this without the use of encrypted tokens, however tokens are complex for users to implement and are easily hijacked as they sit on the user device for attack conversely VPCSML is device independent.


Traditional hashed passwords can be decoded using rainbow tables because the number-set is known and the number of permutations is limited).


In VPCSML as the number-set is subject to custom interpretation by compiled code if the backend is compromised and the salted hash values stored on the backend server are accessed, all that will be revealed will be a set of numbers that cannot be used unless the attacker can decompile the code used for the interface and gain access to the private number-set.


Decompiling code is not an impossible task but one that will require significant hurdles to achieve and in which case the network has already been pwned anyway.


However under VPCSML for accounts to be accesssed the attackers will still first have to decode the salted hash values stored on the control access server behind a firewall and commercial grade endpoint protection and professional security monitoring before the values have to be converted using the reversed engineered code.


Our emphasis is to stop people being tricked into handing over their password on a spoofed site (phishing) and keylogging (malware) both of which our solution stops. Obviously it also protects Administration Accounts. Really these simple attacks need to be stopped and they can be if the subroutines we have designed are implemented.



Research Supports Implementation of Multilevel Authentication


We know that malware and phishing are the primary ways of compromising systems in excess of 75 to 80% of cases so our solution will be of great benefit for society in general.


This is supported by research by Verizon over more than 10 years that demonstrates that these are the key weakness. 


We would however suggest that this research is based on known and  or reported breaches and in fact the trade in compromised accounts on the dark web appears to indicate that the number of compromises is significantly greater than this research addresses. 


In deed there are cases of user name password databases for sale or freely available that contain millions of user records. 


Never the less the Verizon research is very valuable particular for small firms like us that could not otherwise afford the cost of such work to identify the root cause of breaches. 

The Verizon research is available on their site http://www.verizonenterprise.com/verizon-insights-lab/dbir/tool/ 


Microsoft research has identified that phishing attacks are significantly increasing presumably on the basis that they are an effective means of attack. Details of their research are available at their site https://www.microsoft.com/en-us/security/operations/security-intelligence-report


Following is a CSO summary of current phishing attacks which clearly shows it is a significant threat for online products. 

https://www.csoonline.com/article/2117843/phishing/what-is-phishing-how-this-cyber-attack-works-and-how-to-prevent-it.html


Multilevel Authentication Solution


The Armorlog VPCSML design incorporates the features (multilevel authentication, private number-set, time out & lockout configuration, compromise warning keys) to prevent phishing and malware attacks and Armorlog now hold patents in major jurisdictions for this innovation. The process of patenting has required significant scrutiny of this technology by many PHD level qualified computer scientist who have agreed that our invention is a unique innovation.


It is clear that passwords are not going away any time soon as they are the first factor and at present in the majority of cases networks continue to rely on that and as explained the first factor is the fall back in the majority of systems. 


Our approach has been to simplify password use, which the majority appear to agree is necessary and is really what the emphasis of reform is about even though it is sometimes lost in translation.


We still advocate for two factor authentication however the second factor needs to be protected. Our solution for this is to have email protected by multilevel authentication as the device indepent second factor. This avoids the pitfalls of device authentication for both factors, ie when devices are spoofed, lost, stolen, hacked, broken, corrupted or obsolete.


The way password simplification is currently progressing in the market place is single sign on.


Single sign on is a good user experience but poor security because currently the legacy authentication that is being used is vulnerable to attack so once an attacker gets access they get access to a lot more assets under single sign on.


The burden on users login experience can be reduced by single sign on but it needs multi level authentication to prevent hacking as single sign on increases the risks to the user if the account is breached. 


At present for example the current Australian Federal Government approach to single sign on is with exposed old style legacy authentication giving access to virtually all of a users’ personal information held by the Government it is very irresponsible and exposing users to heightened risk of identity theft.


The way to mitigate this risk is to restrict what can be included in single sign on and to have multiple libraries eg one for everyday social media and apps and another for transaction verification for finance, sales, military applications, health, tax, social security etc. 


All this can be controlled through the api by determining and authorising subdomains access to the service to allow the customers to log in to the authorised resources.


Legacy Authentication Replacement


In referring to single sign on we are not distinguishing between a master logon versus a password safe either solution at present is subject to the weaknesses of legacy authentication. 


Armorlog could create a password safe however as the login interfaces are legacy they are never the less subject to the same weaknesses and a password safe has to reside on an operating system and at present all operating systems suffer from this same legacy authentication weakness. 


So even if we create our own stand-alone service via api or application we are undermined by the legacy authentication weakness of the operating systems that support the cloud infrastructure environment.


It is for this reason we have resolved that we need to assist the major platform providers by implementing our system as part of the kernel for their operating systems to eliminate this weakness. 


In order to do this we require significant resources and it is the purpose of this paper to outline the case for those resources. 


We believe early adopters will have a significant competitive advantage particularly in the cloud environment where there is significant trade in hacked accounts for all major platforms on the dark web.


Also as the solution is graphics based as things move toward IoT and VR the technology we have developed will accommodate these changes very well. It works well with all touch devices such as smart TVs, home automation, vehicle access, etc.


Passwords will continue to be required because it is necessary from a legal standpoint as discussed above to show that a user has consented and not just a device.


The only problem is that the routines that everyone uses were designed in the 60’s for local area networks and were never intended for security on wide area networks.


The deck is currently stacked against network owners, to be successful they have to protect against attacks in the hundreds, thousands or even millions, the attacker on the other hand only has to be successful once.


This is what we have addressed in our design.


It is important to have the something you know that is secret and known only to you and not even the network you are connecting and interacting with in order to properly validate the transactions. 


Armorlog multilevel authentication achieves this most important requirement and its cost of implementation will be more than offset by the savings in time, money, energy and anxiety that will otherwise continue to be incurred until legacy authentication subroutines are replaced.