Application security is more than a collection of strong locks and fancy gadgets. We take a comprehensive and holistic view on the nature of data, in the context of their user landscape. Innovations in areas such as transmission, authentication, storage, user management and application development life cycle are orchestrated to deliver an organic, cohesive security experience.

Transmission

End-to-end Encryption

From the moment a request is sent from your browser to the point a response is received, the transmission between every component that’s involved in this communication is encrypted with up to 256-bit TLS encryption. In addition, we actively reject connections that are using known unsafe SSL protocol variants. The encryption at the transport layer works with the application level detection – any network interception that compromises the TLS integrity is detected, and the user session is subsequently ended.

Layered gateways

We utilise a series of firewalls and reverse proxies to not only block the malicious requests, but to absorb the traffic. For the out-most layer, we use Cloudflare, a well-known protection service against many forms of distributed denial of service (DDOS) attacks such as direct botnet traffic or spoofed amplification attack. Our network is meticulously configured so that Cloudflare is the only point of entry for web requests.

Authentication

N-factor authentication

Passwords can only be so strong before they become unmanageable. Two-factor authentication (2FA) is a proven method to strengthen the signon process. With Mortgage Automator, a user can specify a cell phone number and use SMS validation along with the password to log in. But why stop at 2? Our login screen can extend to any number of additional validation methods. For the moment, we have enabled the Key File method. In addition to the password, and/or a validating SMS passphrase, a unique file that only the user has must be included to successfully log in.

Truly random entropy and never-shared key pair

Continuing from the previous point, the key file is not just any file that contains some random content. We make sure that the key file is unique in the entire world, and solely possessed by you, the account owner. The key ingredient to such uniqueness is true randomness. We developed a fun interface to capture the user’s mouse (or touch) movements in a way that cannot be replicated. The captured data is fused with other fingerprinting vectors to form a truly random entropy, which then becomes of the “seed” of the key file. When the key file is generated, a counterpart of the key is also generated for the server to validate the key without knowing the key itself. This key pair is created and streamed. The user key is transmitted to the user’s browser; the counter-key is securely stored in the database. The key itself is never shared with anyone else – not even our database.

Rolling window authentication tokens

Once a user is authenticated, a set of cookies are stored in the browser. The cookies are sent to the server in every following request. To ensure the ultimate cookie security, we look at this extremely compromised scenario: two identical computers with identical software on the same network. The legit user willingly gives away all their cookies. Can a second user log in by just replicating the cookies, but at a different time? We came up with a solution that allows both frequent issuing of new cookies and user continuity. The “salt” of the authenticating cookie is replaced every hour. During hour-switching boundaries, the actively signed user seamlessly adapts the new set of credentials without getting kicked out.

Storage

Credit card storage

All credit cards and other payment information are transmitted to, and stored in processing gateways that are PCI Level 1 compliant. Our servers only see symbolic references to the credit cards or one-time payment authorizations in the form of “tokens”. In other words, the sensitive payment data is simply not found on our servers.

At-rest encryption

A good practice in designing security policies is to assume that everything can be compromised and nobody is to be trusted. Our database files are encrypted in a way that they are only accessible when the machine is powered on. Any reboot or power down would require a passphrase, which is part of a key. The passphrase only authorizes the user to retrieve the other part of the key that’s stored in a different location, known as a Key Vault. If the physical server is transported out of the secure data centre (we don’t see how), and at the same time the server administrator is willing to provide the partial key, the entirety of keys can be revoked at the Vault. In other words, the key to the database is a distributed secret.

User Management

Virtual user containers

Each Mortgage Automator user is insulated in a virtualized container. Even the user with the highest privilege in one realm cannot cross the boundary to another.

Role-based access

Instead of the traditional security level or user groups, Mortgage Automator describes each user by their capabilities, or “access vectors”. This non-linear design allows fine-grained control over specific components of the system.

Real-time eviction and access-level adjustment

User sessions in Mortgage Automator are regulated by a real-time, event driven system.

Server Locations

Canada

Our main server is located in Toronto. Another server is located in Quebec for secure real-time data replication.

USA

In the US, we have two servers on the East coast and two servers on the West coast. Similar to the pairing in Canada, one of the servers in each location acts as the main server, and the other is used for data replication.

Data Backup

Mortgage Automator data backups are implemented under the following schedule:

• every hour up to 4 hours,
• every 4 hours up to 1 day,
• every day up to 1 week,
• every week up to 1 month,
• every month up to 1 year,
• every year up to 7 years.