[ARCHIVE] Existing hardware tokens for One Time Password (OTP)

Archived 2023.01.11. Content moved to CDS Guide, One Time Pin (OTP)

Context

As a Data Holder, we provide customers one of two hardware token types for access to internet banking. This is dependent on the customer type: personal account customers have one token (type 'A') and business customers have another (type 'B').

We have a few questions about the conformance of these existing tokens in relation to the CX Standards and CX Guidelines:

Question

CX Statement 1 (re: type 'A' token.)

The provided OTP MUST be numeric digits and be between 4 and 6 digits in length

For personal customers, they enter a known 5 digit pin from memory and their device responds with an 8 digit OTP.

Would that device/process meet this requirement?

Answer

For clarity this isn't a CX statement.  It is in the InfoSec profile.  The answer is no.  8 digits is longer than 6 digits.  That said, the original intent was to prevent absurdly long OTPs that would be a barrier to adoption and the DSB received very little feedback on the length of the OTP.  If you would like to propose a change to the OTP length you can raise a change request.

Question

CX Statement 1 (re: type 'B' token.)

The provided OTP MUST be numeric digits and be between 4 and 6 digits in length

For business customers, their OTP would be a combination of their personal 4-6 digit PIN from memory plus the six digits showing on their device, forming a code of 10-12 digits.

Would that device/process meet this requirement?

Answer

The same answer as above applies.

Question

CX Statement 2

Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow.

Does this also apply to hard tokens where:

• the expiry may depend on user interaction, like entering an input code, (type A)
• they automatically cycle codes and the token may be at any point in its cycle (the token may have its own 'time remaining' indicator though) (type B) and the exact expiry time may not be known in these asynchronous cases (i.e. where an SMS is not triggered immediately before the OTP screen is displayed as per CX Guidelines.)

Answer

The intent of this is to indicate to the customer how much time they have to enter the code and still be able to validly continue the consent.  The language is based on the assumption that a single OTP is being provided so the expiry of the OTP is the limiting factor.  In your case the limiting factor is actually how long the customer has to enter the code before you consider the session expired (ie. I assume that if they left the window open for two hours and then entered a valid code you would already have timed out). I've spoken to the Data Standards Body Consumer Experience Lead to confirm this is the intent of this standard.  As above, if you would like to raise a change request on Standards Maintenance to prompt a clarification of the CX standards to reflect this we would welcome that.

Question

Statement 3.

The provided OTP MUST be used only for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions

The tokens that customers already have and use provide access to their respective internet banking systems, but the code is for 'one time' authentication. Would these existing tokens meet this requirement?

Answer

The intent here is that token provided to a customer for another purpose (for instance a payment authorisation) can not be leveraged for CDR consent.  Technically a hard token would not comply with this statement in the standards and would be invalid.  The compensating controls of the short lifespan of a token code and the physical possession of the token would mitigate the issue being addressed in this statement, however.  As above, a change request would be warranted.

Question'

Statement 4

In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authorise disclosure of CDR data, unwarranted friction for OTP delivery is considered to include: the addition of any requirements beyond normal data holder practices for verification code delivery

If the OTP details described in the statements above are non-compliant, would we be introducing "requirements beyond normal data holder practices for verification code delivery" if we adopted an new, alternative OTP method (SMS for example)?

Answer

No.  While you would be non-compliant as described above the use of an existing token would not be additional friction as long as the CX was well managed and didn't include extraneous steps.  It would simply be an alternate mechanism in the flow that is already included.