Skip to content

Security Overview

Authentication

Contour support both built-in authentication and single sign-on (SSO) with SAML2.0.

  • Built-in authentication: the default authentication method, all authentication details are stored on Contour server instance. Multi-factor authentication (MFA) is recommended to be enabled for built-in authentication to add extra layer of security.
  • Single sign-on with SAML2.0: SAML is an XML-based standard for authentication and authorization. Contour Server can act as a service provider (SP) with your internal SAML identity provider (IdP).

Contour use Cookie-Based Authentication to keep track of active sessions after a user has been successfully authenticated at the login stage.

Built-in Authentication

Username Policy

  • The user's corporate email address is the username

Password Policy

  • Minimum Length: 8 characters
  • Complexity requirements: Must contain
    • upper case letter, AND
    • lower case letter, AND
    • at least one number OR symbol
  • Initial Admin Password setting: default password set in bootstrap configuration file, and mandatory activation
  • New user password setting: new user activation token/link via email (1 week expiry period)
  • Password Reset (Forgot Password):
    • requires username validation
    • requires MFA authentication
    • password reset token/link via email (48 hour expiry)

Account Logout

  • Account Lockout Threshold: 5 consecutive invalid login attempts
  • Account Lockout Duration: N/A
  • Account Unlock: use forgot password option

Multi-factor Authentication

Contour uses soft token with Time-based One-Time Password (TOTP), as specified in RFC6238, for the MFA login authentication.

  • Using TOTP instead of SMS or email, because there were incidents that SMS 2FA had been exploited. NIST states that SMS 2FA isn’t secure due to the fact that the phone may not always be in possession of the phone number, and because SMS messages can be intercepted and not delivered to the phone

Technical Specifications

  • Algorithm: as specified in RFC6238
  • Secret Key length: Strong with 160 bits (i.e. 32 characters).
  • Time-step size: 30 seconds (i.e. OTP changes every 30 seconds)

Authenticators

All the below authenticators use the same algorithm for TOTP generation, which is specified in RFC6238. So they are inter compatible. Contour recommend Microsoft Authenticator for the security reason.

Single Sign-on (SSO)

Contour support single sign-on (SSO) with SAML2.0.

  • Contour SP metadata can be configured and downloaded by superadmin
  • Supported SAML bindings: HTTP redirect & HTTP post
  • Web browser SSO profile: SP redirect request; IdP POST response
  • Authentication: Contour redirects to IdP, fully delegated to IdP, on every login
  • Authorisation: Contour authorises based on user’s IdP_Group_Membership (i.e. AD group), by mapping Contour_User_Role (admin, viewer, maker, checker, approver) to IdP_Group_Membership => requires “group_membership” claim in SAML assertion
    • Upon successful authentication and authorisation, Contour constructs application-level session/cookie, with default timeout as 30mins (configurable) and absolute time-out 12 hour as per NIST recommendation.
  • User deactivation/termination in IdP
    • If in the middle of the user having active session on Contour, the existing active session will remain valid until session timeout as defined in Contour.
  • User attributes that will be stored in Contour user_db
    • Synchronised from IdP => required claims in SAML assertion
      • username => unique user id
      • display_name => for display on UI, and email greetings
      • email_address => for email notifications
  • Name identifier format: emailAddress
  • User record creation/update in Contour user_db: upon every successful login
  • Logout: Non-single logout, i.e. only the app-level session on Contour is terminated, not propagated (to other apps authenticated with the IdP)

Authorization

Role Based Access Control (RBAC) is adopted in Contour for authorisation, with reference to Role-based Access Control.

Session Management

  • Session Timeout: 30 minutes
  • Absolute Timeout: 12 hours
  • Session Termination
    • User logout, OR
    • Session idle timeout, OR
    • Absolute session timeout
  • Concurrent Login: Disabled (i.e. a single account cannot be concurrently logged in from multiple IPs or multiple browsers under same IP)

Data Confidentiality

Data distribution

On the Corda level, data is distributed on a need-to-know basis.

  • Data is only sent to the participants involved in the transaction, on a transaction level, i.e not share to any other parties not part of the transaction.
  • Non-validating Notary ensure it doesn't see the transaction data.
  • BNO not involved in any business transaction, thus no access to the transaction data either.

Data-in-transit

Data in-transit are encrypted. All connections are protected by TLS, so no network level sniffing should be possible if deployed properly.

Data-at-rest

Data at-rest are encrypted. Database for Corda, and web server should be configured with transparent data at rest encryption or full disk encryption

Cryptography

Incorrect use of cryptography or using outdated algorithms can lead to hard to detect vulnerabilities.

Contour application is built on the TLS standard, encryption provided by the database and signing implemented in Corda.

Hashing

Corda uses SHA256 as content-identifier of transactions and attachments so Contour does as well. The web server hashes user passwords using scrypt.

TLS/SSL

Corda enforces modern configuration of TLS on its P2P connections (version 1.2, only the modern ciphersuites). Establishing connection requires having a client certificate issued by the network's CA. Corda enables only the following two cipher suites for its P2P connections:

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS should be enabled on all communications which are:

  • (internal/external) User browser - Web server: HTTPS/TLS1.2
  • (internal) Web server - Corda: RPC/SSL
  • (external) Corda - peer Corda/Contour nodes: AMQP/TLS1.2

Signatures

Corda uses the Ed25519 signature scheme by default for all transactions as well as network metadata (information registered and distributed by the network map service is signed). Public keys are managed using standard X509 certificates, issued by the network's CA.

Together with signatures, data updates are validated against contract requirements and the network's notary service enforces ordering of transactions to ensure ledger integrity across all participants.

Every official release of the CordApp is signed. We keep the private key on a physical token (YubiKey 4) protected by PIN.

Attachment verification

In several scenarios, customers are able to upload attachments as supporting documents to transactions, for example, while creating a DC application, or submitting a presentation. Only PDF files are allowed to be uploaded.

Contour checks whether there is any active content, especially macro or javascript, inside the PDF files being uploaded. If files are encrypted or otherwise password protected, the system will be unable to conduct such checks. For security purposes, the system will prevent the user from uploading encrypted, password protected files, or files with active content.