Reliance authentication

From HandWiki
Revision as of 17:06, 6 February 2024 by Len Stevenson (talk | contribs) (fix)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Reliance authentication is a part of the trust-based identity attribution process whereby a second entity relies upon the authentication processes put in place by a first entity. The second entity creates a further element that is unique and specific to its purpose, that can only be retrieved or accessed by the authentication processes of the first entity having first being met.

Reliance authentication can be achieved by one or more tokens with random characteristics being transmitted to a secure area controlled by the first entity, where such secure area is only accessible by the person authorised to use the account. The secure area may be an online banking portal, telephone banking system, or mobile banking application.

The token is often in the form of a single or plural of debit or credits to a financial account, where the numerical values of the debit or credits form the token, whose numeric value is to be confirmed by the account holder.

The token are retrieved by the cardholder accessing a secure area from the first entity's secure area, which is protected and accessible only by satisfying the first entity's authentication means. In the case of financial services, authentication to access the secure area normally includes multi-factor and in the SEPA would likely involve strong authentication.

The transmission and requirement to retrieve the token adds a further challenge and response factor to the overall authentication process when considered from the point of view of the second party, which generates and transmits the token.

The token may be generated by the second party dynamically, and can thus act as a one-time password.

The reliance authentication method has particular application with financial instruments such as credit cards, e-mandate and direct debit transactions, whereby a person may instigate a transaction on a financial instrument, however the financial instrument is not verified as belonging to that person until that person confirms the value of the token.

The reliance method often incorporates an out-of-band response means, once the tokens have been retrieved from the secure area.

How it is used

CAPTCHA is a response question that helps determine whether or not a user is a robot or not

Reliance authentication uses multi-step inputs to ensure that the user is not a fraud. Some examples include:

  • When using a credit card, swiping a magnetic stripe or inserting a chip followed by a signature (in some cases, the last four digits of the payment card number is taken).[1]
  • Answering a CAPTCHA question to prove you are not a robot.
  • Security keys
  • Verifying an online account via SMS or email.
  • Time-based one-time password algorithm.

Legal basis

The introduction of strong customer authentication[2] for online payment transactions within the European Union now links a verified person to an account, where such person has been identified in accordance with statutory requirements prior to the account being opened. Reliance authentication makes use of pre-existing accounts, to piggyback further services upon those accounts, providing that the original source is 'reliable'.

The concept of reliability is a legal one derived from various anti money laundering (AML) / counter-terrorism funding (CTF) legislation in the USA,[3] EU28,[4] Australia,[5] Singapore and New Zealand[6] where second parties may place reliance on the customer due diligence process of the first party, where the first party is say a financial institution.

In the Australian legislation, 'reliance' is based upon section 38 of the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth).

In the European Commission's Proposal for a Directive of the European Parliament and of the Council on the prevention of the use of the financial system for the purpose of money laundering and terrorist financing, reliance is based upon Article 11(1)(a).

Reliance in the UK has a very specific meaning and relates to the process under Regulation 17 of the Money Laundering Regulations 2007. "Reliance" for the purpose of AML and "reliance authentication" are not the same, although both use similar concepts.

The Federal Financial Institutions Examination Council of the United States of America (FFIEC) issued "Authentication in an Internet Banking Environment", dated October 2005. Reliance authentication is outlined per the final paragraph of page 14.

Advantages

Advantages of reliance authentication methods are:

  • when used in conjunction with financial services, the identity of the customer has been verified in accordance with AML/CTF legal requirements upon the original account having been opened.
  • they reuse existing security that is already maintained (e.g. by financial institutions).
  • they use familiar and trusted sources. Accessing a financial account in order to retrieve the tokens (which are either credits or debits) is a familiar process to the account holder, and is often available via a variety of means including mobile, online, telephone banking and ATM access.
  • both processes use an in-band method to transmit the tokens, with an out-of-band response mechanism whereby the account holder re-keys in the token value to a new mobile, webpage or app. This mitigates man in the middle and boy in the browser attacks with regards to the token being intercepted.
  • they are a software solution, not requiring any additional hard tokens or complex integrations. Tokens are transmitted as part of the financial network, without the need for any dedicated new networks.
  • that they can be implemented without the involvement of the account issuing institution.

Disadvantages

The use of low cost chips as a reliance authentication device has led to easy targets for fraud and theft

Disadvantages of reliance authentication methods are:

  • the reliance on low-cost authentication methods like computer chips, incite hackers to steal information.[7]
  • the absence of effective tools to monitor fraud, particularly since the transition from magnetic stripes to computer chips.[8]
  • extra time for admins to upload additional software and users to input their information.[8]
  • its inability to support mobile devices.
  • poor password practices allow frauds to steal information from multiple platforms.[7]

See also

References