VPCSML MULTILEVEL AUTHENTICATION SYSTEM

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 accessed 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.