Facebook   LinkedIn   WeChat   YouTube Alert List
Cybersecurity

Two-factor authentication

Q1 :

What should a Platform Operator consider when selecting its two-factor authentication (“2FA”) solution?

A: 2FA is a principle-based requirement for authentication. A Platform Operator is free to select 2FA (including in-house developed) solutions which best align with its security infrastructure and are suitable for achieving its risk mitigation objectives.

In particular, a Platform Operator should assess and evaluate, with the assistance of solution providers or technical consultants where needed, the features, limitations and vulnerabilities of each 2FA solution being considered, and put in place compensating controls as appropriate. For example, a Platform Operator that deploys a short message service (“SMS”) for transmitting one-time passwords (“OTP”) should advise its clients against forwarding OTPs received from their mobile devices to other devices.

Given that 2FA solutions may become obsolete and ineffective over time due to technological advances, a Platform Operator should make reasonable efforts to keep abreast with the latest development and enhance its 2FA solution or implement compensating controls as needed.

(Key references: Paragraph 12.12(b) of the VATP Guidelines)

Q2 : Can email OTP be qualified as a “what a client has” authentication factor for system login? 

A:

No, an email OTP does not qualify as a “what a client has” authentication factor. An email OTP is not effective as the person logging in may not be the actual client for the following reasons:

(i) an email OTP can be delivered to multiple devices, eg, both a mobile phone and a computer, and be accessed or read by multiple applications on each of these devices;

(ii) an email OTP may not always be directed to the client as the login credentials for email accounts can be shared with multiple persons; and

(iii) security protection for email accounts is insufficient, eg, the email forwarding function may result in inadvertent sharing of the OTP with other persons.

(Key references: Paragraph 12.12(b) of the VATP Guidelines)

Q3 : Can OTPs be delivered via both SMS and email? 

A: No. SMS OTP is a valid second authentication factor, but it would be risky to deliver the OTP by email for reasons stated above. A Platform Operator should not deliver OTPs via email.

(Key references: Paragraph 12.12(b) of the VATP Guidelines)

Q4 : Can the 2FA be deactivated for system login by clients?

A: No. 2FA is mandatory, a Platform Operator should not allow their clients to deactivate this function.

(Key references: Paragraph 12.12(b) of the VATP Guidelines)

Q5 : Can “dual-password” model (eg, a password is used for system login and another password is required for order placement or two separate sets of passwords are required for system login) fulfil the 2FA requirement?

A: No, dual passwords only constitute a single factor in the authentication process, i.e., “what a client knows”. Hence, it does not fulfil the 2FA requirement.

(Key references: Paragraph 12.12(b)  of the VATP Guidelines)

Q6 : How many devices can be bound or registered to clients’ trading accounts as a factor of authentication for system login?

A:

In general, a Platform Operator should not allow clients to bind or register more than three devices. 

(i)  In cases where an individual client requests to bind or register more than three devices, a Platform Operator should understand the reasons and assess the reasonableness of the request; and

(ii) In cases where a corporate client requests to bind or register multiple devices so that they can be operated by its authorised persons, a Platform Operator should advise the corporate client of the creation of sub-accounts (each with its own 2FA) for those authorised persons; and if a sub-account arrangement is not feasible, a Platform Operator should ask its corporate clients about the number of persons authorised to operate their trading accounts and limit concurrent logins accordingly.

(Key references: Paragraph 12.12(b) of the VATP Guidelines)

Password policies and session timeout controls

Q7 : How often should a Platform Operator remind its clients to change their passwords?

A: Platform Operators would generally be expected to remind clients who have not changed their passwords for more than 90 calendar days.

(Key references: Paragraph 12.12(d)(ii) of the VATP Guidelines)

Q8 : What controls can Platform Operators implement on invalid login attempts?

A:

Platform Operators may, among other things, implement the following controls:

  • account lockout;
  • exponential back-off between successive failed login attempts; and
  • brute-force attacks detection with appropriate responses.

The above list is not exhaustive and Platform Operators can choose to implement any controls they deem appropriate.

(Key references: Paragraph 12.12(d)(v) of the VATP Guidelines)

Q9 : Are Platform Operators or clients allowed to disable the session timeout control? 

A:

No. Session timeout should not be disabled.

(Key references: Paragraph 12.12(d)(vi) of the VATP Guidelines)

Q10 :

What is the expected idle timeout period for session timeout control? 

A:

 A Platform Operator should limit the idle timeout period to no more than 30 minutes subject to prior assessment and ongoing monitoring.

(Key references: Paragraph 12.12(d)(vi) of the VATP Guidelines)

Notification to clients

Q11 : Are Platform Operators required to notify clients of each system login if clients already receive notifications of irregular logins (i.e., through a device which is not customarily used by the client)?

A:

Our requirement is for Platform Operators to notify clients promptly of each system login. But we accept that a Platform Operator could allow clients to opt-out from notifications of each system login provided that:

  • the Platform Operator has the capability to identify irregular logins and promptly notify clients of irregular logins;
  • the Platform Operator has provided adequate risk disclosures to clients who have acknowledged that they understand the risks involved in opting-out from notifications of each system login; and
  • the clients have not opted out from trade execution notifications.

(Key references: Paragraph 12.12(e) of the VATP Guidelines)

Security control over infrastructure of the platform

Q12 :

How does a Platform Operator implement proper network segmentation? 

A:

A proper network segmentation should be implemented with multi-tiered firewalls. A Platform Operator should:

(i) place trading applications and other critical systems, such as custody system, within an internal network behind a Demilitarized Zone (“DMZ”); and

(ii) host servers with less sensitive data, eg, the web server, within a DMZ.

(Key references: Paragraph 12.12(f)(i) of the VATP Guidelines)

Q13 : Can a Platform Operator grant permanent remote access to vendors?

A:

No. A Platform Operator should avoid granting permanent remote access to external parties. Remote access should be granted on a need-to-have basis and disabled after the remote access activities are completed.

(Key references: Paragraph 12.12(f)(ii) of the VATP Guidelines)

Q14 :

Can a Platform Operator deploy security patches and hotfixes by batch? 

A:

Security patches and hotfixes ranked as critical or of high severity should be deployed within one month following the completion of testing.

Non-critical security patches and hotfixes are allowed to be deployed using a batch-implementation approach. They should be deployed at least on a quarterly basis unless, after evaluation, a Platform Operator determines that they may be incompatible with system applications and cannot be implemented.

(Key references: Paragraph 12.12(f)(iii) of the VATP Guidelines)

Q15 : Can a Platform Operator use end-of-life (EOL) or close to EOL software? 

A:

No, EOL software is not allowed. For close to EOL software, a Platform Operator should monitor the validity of the software and formulate a plan to replace or upgrade it before EOL.

(Key references: Paragraph 12.12(f)(iii) of the VATP Guidelines)

Data encryption

Q16 : What data encryption algorithms should be used?

A:

A Platform Operator should review international security standards (eg, the cryptographic standards provided by National Institute of Standards and Technology (NIST)) on an ongoing basis, check the status of their data encryption algorithms and upgrade them as appropriate.

 

Examples of weak encryption algorithms include:

 

(i) For data transmission: SSL 3.0, TLS 1.0, TLS 1.1, TLS_RSA_WITH_RC4_128_MD5

(ii) For data storage: DES, 3DES, RC4, RC5, RSA 1024-bit, Blowfish, Twofish, MD5, SHA-1

(Key references: Paragraph 12.12(g) of the VATP Guidelines)

Q17 : Is DMZ considered as part of an internal network for the purpose of the data encryption requirement?

A:

Yes, DMZ is considered as part of an internal network for the said purpose.

 

(Key references: Paragraph 12.12(g) of the VATP Guidelines)

Monitoring and surveillance

Q18 : For the purpose of monitoring and identification of suspicious unauthorised access to clients’ trading accounts, is manual review approach acceptable? 

A:

No, given the automated and round-the-clock nature of the VATP business, manual review is not an effective means of identifying suspicious unauthorised virtual asset trading activities. A Platform Operator should implement effective automated solution to monitor and identify suspicious unauthorised access to clients’ trading accounts, such as automated IP address monitoring tool and behaviour analysis.

(Key references: Paragraph 12.12(h) of the VATP Guidelines)

Q19 : How often should a Platform Operator perform monitoring and identification of suspicious unauthorised access to clients’ trading accounts? 

A:

A Platform Operator should perform monitoring and identification of suspicious unauthorised access to clients’ trading accounts on a real time basis.

(Key references: Paragraph 12.12(h) of the VATP Guidelines)

Q20 : Can you cite some examples of how a Platform Operator can detect unauthorised access to clients’ trading accounts?

A:

A Platform Operator may monitor (i) logging into multiple client accounts from the same IP address; and (ii) change of IP address for accessing the same client account from one country to another country in a short period of time.

(Key references: Paragraph 12.12(h) of the VATP Guidelines)

Mobile trading platform

Q21 : Please provide examples of security controls to protect the mobile trading platform.

A:

A Platform Operator should implement at minimum the below security controls to protect the mobile trading platform: 

(i) detecting and blocking jailbroken or rooted mobile devices from logging into the mobile trading platform; 

(ii) obfuscating the source codes to better protect them from potential manipulation; 

(iii) purging unused code libraries or modules from its source codes; 

(iv) purging clients’ sensitive information from its mobile trading platform installed on clients’ mobile devices once the clients exit the application or log off their trading account, eg, disabling the “remember password”, “auto fill” and “auto completion” features; and

(v) tightening security controls for biometric authentication, eg, requiring clients to deactivate and re-register their biometric authentication, subject to validation, if clients wish to add or amend the biometric data stored in the records for their mobile device and limiting the number of failed authentication attempts, eg, five consecutive failed attempts.

(Key references: Paragraph 12.12 of the VATP Guidelines)

Backup

Q22 :

Can “remote backup server” qualify as an “off-line medium” used for the system and data backup?

A:

Yes, the term “off-line medium”1 refers to tape or any other kind of medium, such as remote backup server, which is securely segregated from the production system.

(Key references: Paragraph 12.16 of the VATP Guidelines)

1 As referred to in paragraph 12.16 of the VATP Guidelines

Last update: 1 Mar 2024

We use cookies to improve the website performance and user experience. If you continue to use this website, you are agreeing to their uses. Learn more about our privacy policy.